Скриптование

[Black Hunter 3]

А можно примерное время через скоко будут появлятся эти плоти которых я зареспаунил скажем так будут появлятся. Они будут появлятся после начала новой игры или сколько-то нужно ждать.

Просто, что-то они не появились. Скажу сразу спауню на новой локации Болото для ТЧ.

[Artos 99]

Black Hunter

Все параметры и в том числе параметр 'idle_spawn' считывается сразу при старте новой игры.

Попытка спавна произойдет сразу же и будет заспавнено столько, на сколько имеется ограничение или позволила вероятность.

Далее 'idle_spawn' пропишется в параметры респавнера и запомнится (при сэйвах в его нет-пакете).

Преиодичность спавна для чистой ТЧ: medium = 60*60 секунд (т.е. 1 час игрового времени).

Можно указать в 'idle_spawn' свои времена, типа 'idle_spawn = 360,720' - тогда период будет рандомно выбираться из диапазона 1...2 часа.

 

Ну а то, что не появились - и сам проверяй свои вертексы и коорлдинаты, у меня твооей карты нет. И в тот же лог в респавнере можешь вывести факт спавна и даже простановку меток на заспавненные объекты. Вот и проверяй - ищи ...

 

P.S. Про 'respawn_check' - вынужден признать, что опять дал промашку. Это для модифицированного скрипта респавнера прокатит, а для оригинального нет. Требуется этот параметр вносить в кастом-дату секции спавнящихся объектов. Если у тебя там нет отвязки от гулагов и нет гулагов или в них свободной работы для плотей - все спавнящиеся будут уничтожаться сразу же.

Создай секции для своих плотей типа:

[flesh_my_respawn]:flesh_weak

custom_data = scripts\flesh_my_respawn.ltx

 

а в этом конфиге:

[smart_terrains]

respawn_check = false

 

тогда и спавниться будут и будут свободно гулять, пока не освободится работа в каком нибудь для них гулаге, тогда примкнут к нему.

Если добавишь 'none = true' - будут свободно гулять постоянно.

Изменено 3 Октября 2011 пользователем Artos

[Black Hunter 3]

[10327]

; cse_abstract properties

section_name = respawn

name = mar_flesh_respawn_01

position = 448.96615600586,0.78080213069916,-174.79156494141

direction = 0,0,0

 

; cse_alife_object properties

game_vertex_id = 3554

distance = 4.90000009536743

level_vertex_id = 436721

object_flags = 0xffffff3e

custom_data = scripts\mar_flesh_001_respawn.ltx

[respawn]

respawn_section = flesh_weak,19, flesh_normal,14

max_count = 8

min_count = 3

max_spawn = 3

respawn_check = false

idle_spawn = medium

END

 

; cse_shape properties

shapes = shape0

shape0:type = sphere

shape0:offset = 0,0,0

shape0:radius = 1

 

; cse_alife_space_restrictor properties

restrictor_type = 0

 

; se_respawn properties

 

Тоесть по идее должно получится так, а в config/scripts надо добавить mar_flesh_001_respawn.ltx? это верно?

 

 

Добавлено через 5 мин.:

А может лучше будет добавить прямо в секцию_респауна в all.spawn [smart_terrains] none = true?

 

 

[Artos 99]

Black Hunter

перепрочти пару раз то, что выше.

Респавнер, который уже в all.spawn'е - ни в какой config/scripts добавлять не нужно.

А вот секции плотей тебе придется и добавить (например в config\creatures\spawn_sections.ltx), т.к. дефолтные не отвязаны от гулагов и прописать новым секциям конфиги в 'config\scripts\*.ltx', дабы отвязать от гулагов и/или разрешить спавниться без привязки к гулагам.

 

Добавлено через 3 мин.:

Black Hunter: А может лучше будет добавить прямо в секцию_респауна в all.spawn [smart_terrains] none = true?

Ты собираешься респавнер от гулага отвязать? Ну-ну ...

Отвязывают объекты спавна (в их секциях/логике), а не то, что спавнит.

Изменено 3 Октября 2011 пользователем Artos

[Капрал Хикс 519]

Спасибо всем, кто откликнулся на мой вопрос! Отследить глючный арт и правда не было возможности, ибо комп зависал наглухо. Однако проблема решилась удалением тех аномалий, у которых в координатах xyz маячили всякие нехорошие -e2-557 и прочие инородные вкрапления. От греха подальше убрал и подчистил все аномалии с подобными координатами. После этого проблема вроде как решилась.

[amik 253]

Привет. Копаюсь в логике, возникли такие вопросы

Мне нужно чтобы радио приемник выключился от выстрела в него. Я сделал ему такую логику (пробовал разные варианты, последним был этот):

[logic]
active = ph_sound
on_hit = hit

[hit]
on_info = %+mil_priemnik_off%

[ph_sound]
snd = radio_music
looped = true
on_info = {+mil_priemnik_off}| ph_sound@end

[ph_sound@end]
snd = $no_sound
looped = false
on_signal = sound_end| nil

Не выключается, вроде где-то видел рабочий вариант, только не помню где.

 

Хочу сделать охранника, который после атаки (любой вид "шухера") вернется на свое место (охраняемую точку). Он игнорирует почему-то логику walker(а)

[logic]
active = remark1
danger = danger_ignore
;meet = meet

[danger_ignore]
ignore_distance = 0

[remark1]
path_walk = walk_soldier_bodyguard1
path_look = look_soldier_bodyguard
;anim = guard
target = nil
meet = meet

[meet]
meet_state    = 5|guard
meet_state_wpn    = 5|threat_fire
victim = 5|actor
victim_wpn = 5|actor
use = true
use_wpn = true

[logic]

active = walker1

danger = danger_ignore

;meet = meet

 

[danger_ignore]

ignore_distance = 0

 

[walker1]

path_walk = walk_soldier_bodyguard1

path_look = look_soldier_bodyguard

combat_ignore_cond = always

on_game_timer = 50 | remark1

 

[remark1]

;path_walk = walk_soldier_bodyguard1

;path_look = look_soldier_bodyguard

;anim = guard

target = nil

meet = meet

 

[meet]

meet_state = 5|guard

meet_state_wpn = 5|threat_fire

victim = 5|actor

victim_wpn = 5|actor

use = true

use_wpn = true

 

 

ColR_iT За радио спасибо, попробую сегодня.

За охранника:

Если я ставлю такой вариант логики

[logic]
active = remark1
danger = danger_ignore


[danger_ignore]
ignore_distance = 0

[remark1]
path_walk = walk_soldier_bodyguard1
path_look = look_soldier_bodyguard
;anim = guard
target = nil
meet = meet

[meet]
meet_state    = 5|guard
meet_state_wpn    = 5|threat_fire
victim = 5|actor
victim_wpn = 5|actor
use = true
use_wpn = true

То мой нпс переходит в meet сразу, не куда не идет.

С тем вариантом логики что ты мне дал у меня идет вылет с аргументом: _g.skript:20 как-то так.

Если я оставлю вариант:

[logic]
active = walker1

[walker1]
path_walk = walk_soldier_bodyguard1
path_look = look_soldier_bodyguard

То он бежит в ту точку и где-то за 1-1,5м до пункта назначения получаю вылет.

Может точки в wp я не так сделал?

 

[look_soldier_bodyguard]
points = p0
p0:name = wp00
p0:position = -138.841918945313,-25.439302444458,-355.694732666016
p0:game_vertex_id = 19
p0:level_vertex_id = 116593


[walk_soldier_bodyguard1]
points = p0,p1
p0:name = wp00
p0:flags = 0x1
p0:position = -135.914733886719,-25.439302444458,-359.351440429688
p0:game_vertex_id = 19
p0:level_vertex_id = 116591

p1:name = wp01
p1:position = -136.714736938477,-25.439302444458,-359.351440429688
p1:game_vertex_id = 319
p1:level_vertex_id = 102988
p1:links = p0(1)

Точка walk_soldier_bodyguard1, если у нее нету связи с другой точкой то вроде был вылет...не помню уже ,но пришлось сделать именно этот вариант.

 

Еще, если я добавлю вот это:

[logic]

--

on_combat = combat

---

[combat]

on_timer = 30 | walker1

 

По идее вернутся должен, не правда ли?

 

п.с. Только учусь

Изменено 5 Октября 2011 пользователем amik

[ColR_iT 171]

amik.

1. Радио.

Я сталкивался с подобным вопросом и решение его существует...

Дело в том, что для подобной логики, объект должен быть physic_destroyable_object, почему так - я не знаю, но это так.

Еще один нюанс: вот это:

snd = $no_sound

вероятнее всего выдаст тебе ошибку, поскольку сюда необходимо писать не сами файлы, а звуковую схему из файла sound_theme.script, тебя должно интересовать ph_snd_themes. Если ты заглянешь туда, тебе сразу станет все предельно ясно, как и что в таком случае писать...

Хорошим вариантом будет добавить свою звуковую тему, которая бы включала в себя звук какого-нибудь "шипения", мол после выстрела радио поломалось и зашипело

Готовая схема будет выглядеть так:

[logic]
active = ph_sound
on_hit = hit

[hit]
on_info = %+mil_priemnik_off%

[ph_sound]
snd = radio_music
looped = true
on_info = {+mil_priemnik_off}| ph_sound@end

[ph_sound@end]
snd = silence
on_signal = sound_end| nil

где silence - твоя звуковая сехма.

 

2. Охранник.

Здесь не до конца ясно, что значит "не слушает команду path_walk"?

Чего ты ждешь от этой схемы?

Подозреваю, что она работает так, как нужно, смотри:[logic]

;ты ставишь активную схему walker1

active = walker1

;задаешь реакцию на опасность

danger = danger_ignore

;meet = meet

 

[danger_ignore]

ignore_distance = 0

 

;активная схема

[walker1]

;задаешь точки в которых будет стоять и куда смотреть

path_walk = walk_soldier_bodyguard1

path_look = look_soldier_bodyguard

;игнорируем бой, причем всегда.

combat_ignore_cond = always

;по истечении 50 секунд переходим на схему remark1

on_game_timer = 50 | remark1

 

;перешли на схему

[remark1]

;path_walk = walk_soldier_bodyguard1

;path_look = look_soldier_bodyguard

;anim = guard

;куда смотрим - не понятно, вычисляется автоматически

target = nil

;как встречаем ГГ

meet = meet

 

;секция реакции на гг

[meet]

;анимация в зависимости от расстояния до актора (если ближе 5 метров отыгрываем guard) (актор без оружия)

meet_state = 5|guard

;тоже самое, только если актор с оружием в руках

meet_state_wpn = 5|threat_fire

;на кого смотрим (ближе 5 метров - на актора)(актор без оружия)

victim = 5|actor

;тоже самое, только ГГ с оружием в руках

victim_wpn = 5|actor

;возможно ли заюзать персонажа

use = true

use_wpn = true

Получается, что НПС стоит на точке walk_soldier_bodyguard1, после 50 секунд, он переходит на схему remark1, после срабатывает какой-нибудь денжер, а дальше все... перехода на схему walker1 ведь нету, после универсального комбата, НПС вернется к последней активной схеме, а это будет remark1.

Так что все так, как ты сделал...

Самым простейшим вариантом возврата НПС на свое место, является следующая схема:

[logic]
active = walker1

[walker1]
path_walk = walk_soldier_bodyguard1
path_look = look_soldier_bodyguard

По идее этого должно быть достаточно.

 

 

Спустя некоторое время...

У тебя точки path_look и path_walk не синхронизированы. Т.е. для того чтобы НПС понимал куда ему нужно смотреть в какой-то конкретной точке, нужна их синхронизация, которая осуществляется при помощи flags.

У тебя выходит, что точка look_soldier_bodyguard не привязана не к какой точке пути. А еще у тебя сами точки пути не связаны. Поэтому сделай так:

[look_soldier_bodyguard]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -138.841918945313,-25.439302444458,-355.694732666016
p0:game_vertex_id = 19
p0:level_vertex_id = 116593


[walk_soldier_bodyguard1]
points = p0,p1
p0:name = wp00
p0:flags = 0x1
p0:position = -135.914733886719,-25.439302444458,-359.351440429688
p0:game_vertex_id = 19
p0:level_vertex_id = 116591
p1:links = p1(1)

p1:name = wp01
p1:position = -136.714736938477,-25.439302444458,-359.351440429688
p1:game_vertex_id = 319
p1:level_vertex_id = 102988
p1:links = p0(1)

таким образом, когда НПС будет в первой точке wp00 пути walk_soldier_bodyguard1 он с вероятностью 100%, в течении 5 секунд бедет смотреть в эту точку, дальше перейдет на на точку wp01, после развернется и пойдет назад в точку wp00 и так далее по кругу.

 

По поводу combat.

Нет, этого не произойдет...

Секция [combat] задает параметры боя, например можно выдать инфопоршень или запустить какую-либо функцию (но только из файла xr_effects.script). Также можно задать режим боя, таковых три:

- движковый бой (стоит по умолчанию);

- combat_type = {возможны условия перехода на данный режим боя} camper - по камперски;

- - по монолитовски.

Ах, да! Забыл про четвертый:

- combat_type = {также возможны условия} zombied - как зомби (анимации здесь не при чем).

Как ведет себя та или иная схема, я не проверял.

Изменено 5 Октября 2011 пользователем ColR_iT
дополнил...

[amik 253]

ColR_iT Я проверял, на монолите ведет себя очень хорошо, вариант с зомби, тоже оказался прикольным, нпс идет на тебя бесстрашно и стреляет как терминатор.

Кампер глючит, по крайней мере на новичке. Я имел в виду так сделать:

[logic]

active = walker1

danger = danger_ignore

on_combat = combat

 

[danger_ignore]

ignore_distance = 0

 

;активная схема

[walker1]

;задаешь точки в которых будет стоять и куда смотреть

path_walk = walk_soldier_bodyguard1

path_look = look_soldier_bodyguard

;игнорируем бой, причем всегда.

combat_ignore_cond = always

;по истечении 50 секунд переходим на схему remark1

on_game_timer = 50 | remark1

 

;перешли на схему

[remark1]

;куда смотрим - не понятно, вычисляется автоматически

target = nil

;как встречаем ГГ

meet = meet

 

;секция реакции на гг

[meet]

;анимация в зависимости от расстояния до актора (если ближе 5 метров отыгрываем guard) (актор без оружия)

meet_state = 5|guard

;тоже самое, только если актор с оружием в руках

meet_state_wpn = 5|threat_fire

;на кого смотрим (ближе 5 метров - на актора)(актор без оружия)

victim = 5|actor

;тоже самое, только ГГ с оружием в руках

victim_wpn = 5|actor

;возможно ли заюзать персонажа

use = true

use_wpn = true

 

[combat]

combat_type = monolith

on_timer = 30 | walker1

 

По экспериментирую.

 

 

Главная задача вернуть его обратно в ту точку.

Изменено 5 Октября 2011 пользователем amik

[7.9 174]

Нужна готовая функция изменения параметров объекта через нет-пакет.

 

Переписывать нужно параметры "position", "level_vertex_id", "game_vertex_id" и "parent_id" объектов находящихся в инвентарном боксе.

 

[ColR_iT 171]

amik, да, я понял, что ты имеешь ввиду.

К сожалению мне не встречались случаи, чтобы в секции [combat] было переключение на другую схему. Повторюсь, что данная схема лишь задает тип боя (см. выше), также можно сделать выдачу инфопорции или вызов функции когда НПС срывается в бой, например так:

[logic]
on_combat = combat
[combat]
on_info = %+infoportion%

.

[Zander_driver 10 333]

7.9

А вариант удалить в инвентаре прежнего владельца и заспавнить в инвентаре нового, не подойдет?

Реализация попроще, и результат тот же.

[7.9 174]

Zander_driver, "владельцы" находятся на разных локациях. Часть предметов - просто пересоздаётся, а функция нужна для (очень) "уникальных" предметов. Функция вызывается из actor_binder:save(packet). Изменено 6 Октября 2011 пользователем 7.9

[Artos 99]

7.9, нет и не может быть готовых функций для изменения параметров (из секции 'cse_abstract') объекта через нет-пакет.

Объяснять долго и муторно, тем более имеет смысл для того, кто готов копаться в нет-пакетах.

Если ты говоришь именно про 'изменение' - то это подразумевает чтение всего(!) нет-пакета объекта. Т.к. объекты бывают самого разного класса - то и для чтения применяются эксклюзивные для каждого класса наборы методов.

 

1. Изменить параметры 'position', 'level_vertex_id', 'game_vertex_id' можно при сохранении объекта в сэйв, но для этого придется ловить объект в его биндере (xxx_binder:save(packet)) и в этот момент изменять. Пример для сталкеров можно глянуть в Симбионе.

2. А вот для 'parent_id' вариант изменения при создании сэйва не прокатит, т.к. для этого параметра нет штатного метода, как для 'position'.

Чтение секции 'cse_abstract' нет-пакета, в котором и имеется 'parent_id', для каждого объекта не производится по-байтово, а получается автоматически в методе 'STATE_Read' в составе уже прочитанной части пакета.

По сути, возможно изменение (перепаковка) только в момент первичного спавна (появления) объекта при старте игры. Если интересует - смотрим перепаковку аномалий в AMK/Zenobian/...

 

В общем, если твои предметы не биндятся - то и вообще заморачиваться бессмысленно, ну а в противном случае - морока не маленькая с каждысм классом предметов.

 

Если очень нужно, то ... можно попробовать заморочиться с подменой нет-пакетов, т.е. запоминать доступные параметра (нет-пакет) прежнего предмета -> удалять его (предмет) -> спавнить новый аналогичный предмет -> разбирать нет-пакет и переписывать ему нужные параметры из запомненного.

Изменено 6 Октября 2011 пользователем Artos

[Real Wolf 34]

Возникла проблема. Есть некий скрипт, в нём функция, которая возвращает строку. Файл компилируется нормально, ошибок нету, игрой читается.

При вызове функции из нужного мне места, игра вылетает с логом, что не найдена данная функция. Хотя при вызове этой же функции из другого места всё нормально.

FATAL ERROR

 

[error]Expression : fatal error

[error]Function : CScriptEngine::lua_error

[error]File : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp

[error]Line : 73

[error]Description : <no expression>

[error]Arguments : LUA error: ...yl\gamedata\scripts\lwc_upgrade_weapon_select.script:35: attempt to call field 'GetRealSect' (a nil value)

 

 

malandrinus,

В том и дело, что глобальная. И вообще, любое обращение из того места к файлу 'lwc_upgrade_weapon_select' вызывает вылет. К примеру, обращение к скриптовой диалогу.

Изменено 7 Октября 2011 пользователем Real Wolf

[Malandrinus 615]

Real Wolf,

При вызове функции из нужного мне места, игра вылетает с логом, что не найдена данная функция. Хотя при вызове этой же функции из другого места всё нормально.

Если вызываемая функция - локальная, то убедись, что она стоит перед местом, откуда вызывается.

[7.9 174]

Artos

 

Чтение секции 'cse_abstract' нет-пакета, в котором и имеется 'parent_id', для каждого объекта не производится по-байтово, а получается автоматически в методе 'STATE_Read' в составе уже прочитанной части пакета.

По сути, возможно изменение (перепаковка) только в момент первичного спавна (появления) объекта при старте игры.

Значит-ли это, что после создания объекта доступны параметры не всех (его) серверных классов?

То-есть, например, прочитав где-нибудь в процессе игры, пакет объекта с серверным классом, например, cse_alife_item_pda, и начав его разбирать с начала, я уже не прочитаю данные класса cse_abstract ? Например, параметры section_name, position и прочие... Или спрошу так: "Какие параметры останутся доступными для чтения\записи в нет-пакете объекта с серверным классом cse_alife_item_pda после его создания?

 

Добавлено через 124 мин.:

Ладно, попробую переписать только вертексы, если position будет зафиксированным - его переписывать не надо будет.

[Artos 99]

7.9

Не перемешивай все в кучу.

1. Если класс создаваемого объекта не имеет своего 'server_object_class', зарегистрированного в файле 'class_registrator.script' - то доступ к его параметрам из секции 'cse_abstract' невозможен (нет ни читалки ни писалки).

Для таких объектов возможно чтение (и изменение) нет-пакетов только начиная с секции 'cse_alife_object'.

 

Например, для фонариков можно получить полный нет-пакет, а вот для КПК - мне не удалось, даже зарегистрировав этот класс (CPda). Т.о. для КПК вообще недоступна секция 'cse_abstract'.

 

2. Если даже для объекта имеется доступный 'server_object_class', то далеко не все объекты имеют апдейты после их создания (появления в игре). Изменив параметр(ы) для серверного объекта как минимум требуется синхонизировать с клиентским объектом ... что тоже и не всегда просто и не имеет 'готового универсального' решения.

Изменено 7 Октября 2011 пользователем Artos

[speczadanie 0]

Такой вопрос. В результате некоторых моих изменений, в инвентаре всех скриптовых трупов стал автоматически спавниться Болт. Корни этой проблемы уходят далеко в глубь скриптов, найти источник вопроса не получается, поэтому вопрос к вам, уважаемые скриптеры.

Что и куда нужно прописать, чтобы созданный Болт удалялся?

Изменено 8 Октября 2011 пользователем ColR_iT

[*Shoker* 322]

Во первых - откуда тут знают что ты изменял в коде?

Во вторых - удалять надо не болт а то что приводит к его появлению. Помимо болта там гитар и прочего нету случаем?

[speczadanie 0]

Нет, гитар нет. Там слишком проблемно копаться, вот я и хочу пойти в обход - тупо удалить его.