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

[Norman Eisenherz 225]

Лог действий в биндере обычной собаки и псевдособаки: в первом случае выполняется __init, load и дальше только апдейт, а во втором постоянное пересоздание

! Unknown command:  INIT=false		-- создание
! Unknown command:  READ=true		-- правильное чтение
! Unknown command:  INIT=false
! Unknown command:  READ=false		-- сброс
! Unknown command:  INIT=false
! Unknown command:  READ=false
…

[imcrazyhoudini 177]

12 часов назад, h0N0r сказал:

Раньше было так:

void CScriptBinder::Load			(LPCSTR section)
{
	inherited::Load			(section);
}

Не значит ли это то, что если вернуть такой вид то многоэтапная логика не будет сбрасываться в самое начало при переходе НПС в оффлайн/смены уровня?

[Norman Eisenherz 225]

Чем дальше в лес, тем веселее: псевдособака более не имеет вызова _binder:load – даже на чистой геймдате с единственным скриптом, который только сигналит в лог о действиях биндера, у собак и кабанов на Кордоне есть __init и load, у псевдособаки в живом или мертвом виде один __init. Хелп…

[Kirgudu 958]

@Norman Eisenherz не подтверждаю.

https://disk.yandex.ru/d/TfcsZSLsZNf9zQ
Здесь скрипт (дополнил логом в функциях init, update, load и save), лог и сейвы - до использования уже мёртвой псевдособаки, после, и после загрузки.

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

Сидоровича использовал во время первого диалога, собаку при обыске, плоть - нет. И до и после загрузки видно 2 положительных флага и один отрицательный, как ожидалось.

Возможно, разница в движках; пользуюсь купленной 15 лет назад в Стиме версией игры.

 

@imcrazyhoudini не значит, поскольку для того, чтобы отработало inherited::Load(section), необходимо, чтобы класс CScriptBinder наследовал другой, родительский класс, который в актуальной версии не указан.

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

[imcrazyhoudini 177]

Тогда такой вопрос, на счёт того, что НПС переходят в секцию логики указанной в active при переходе в оффлайн.

ЧН.

Пытался метод dsh адаптировать, но упёрся в правки движка:
 

Скрытый текст

FATAL ERROR
 
[error]Expression    : assertion failed
[error]Function      : CInifile::w_string
[error]File          : D:\S.T.A.L.K.E.R. Clear Sky\Hike\xray\xrCore\Xr_ini.cpp
[error]Line          : 632
[error]Description   : !m_flags.test(eReadOnly)
 

stack trace:
 
xrEngine.exe caused an EXCEPTION_BREAKPOINT in module xrCore.dll at 00000000A904F65A, xrDebug::backend()+0346 byte(s), D:\S.T.A.L.K.E.R. Clear Sky\Hike\xray\xrCore\xrDebugNew.cpp, line 0230

Подумал о варианте попроще - поддержки кондлиста.

Помню переносил давным давно на ТЧ поддержку кондлиста для гулагов, примера нет уже.

В принципе, работало, правда, требовалась обязательный сейв-лоад.

Думаю игроку хоть раз за игру да придётся перезагрузиться и НПС уже подхватит новую логику.

Есть у кого пример как реализовать поддержку кондлиста для одиночной логики?

Если ещё релоад не нужен будет - вообще отлично.

Изменено 2 Апреля 2023 пользователем imcrazyhoudini

[Norman Eisenherz 225]

@Kirgudu И снова дьявол кроется в деталях: если сравнить имена объектов, то в твоем сейве имя pseudodog_weak#, а у меня проблема с мутантом, который живет в пещере за АТП и имеет уникальное имя esc_pseudodog_strong. У слабой псевдособаки вызов binder:load действительно ловится, у этой – нет.

В [all.spawn] для этого зверя указано section_name = pseudodog_weak, то есть вроде бы точно такая же псевдособака.

[Zander_driver 10 166]

10 часов назад, Norman Eisenherz сказал:

У слабой псевдособаки вызов binder:load действительно ловится, у этой – нет.

А что у них прописано в script_binding в их секциях? Неужели нечто разное... (Тогда надо прописать штатный биндер, и будет ловить нормально)

[Norman Eisenherz 225]

Нашлась еще одна неведома зверушка: кабан esc_bd__m_boar_e_0007, который спавнится в виде трупа среди аномалий западнее а/м моста (или севернее вагончика, где лежит раненый Толик).

 

@Zander_driver Оба мутанта описаны только в [all.spawn]. Единственная запись со словом script: script_version = 6. В исходных конфигах одна ссылка для всех вариантов: script_binding = bind_monster.bind.

Изменено 3 Апреля 2023 пользователем Norman Eisenherz

[h0N0r 278]

@Norman Eisenherz 

Затестил скрипт с переменной, она тру после первого юза / сейвлоада, но сбрасывается в false при смене уровня. Если добавить в se_monster.script:

function se_monster:keep_saved_data_anyway()
	return true
end

то будет сохранение.

 

К примеру, если подобный блок удалить в se_zones.script для se_restrictor, то их логика будет сбрасываться на начало после смены уровня.

; test sr
[logic]
active = sr_idle@1

[sr_idle@1]
on_info = {+ai4_sr_to_2} sr_idle@2 %=send_tip(SR_to_section_2)%

[sr_idle@2]
on_info = {+ai4_sr_to_3} sr_idle@3 %=send_tip(SR_to_section_3)%
on_game_timer = 50 | {-ai4_sr_to_3} %+ai4_sr_to_3%

[sr_idle@3]

[Norman Eisenherz 225]

Да, оно: потестил на начальных зверях (+ еще два уника в подземке НИИ), состояние запоминается правильно.

 

 

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

[h0N0r 278]

@Norman Eisenherz 

Насчёт ограничений, есть исходники ориг. ТЧ: https://github.com/mortany/xray

xrServer_Object_Base.cpp,

//client object custom data serialization SAVE

u16 client_data_size = (u16)client_data.size();

 

 

[Norman Eisenherz 225]

Не знаю, насколько это подходит…

Нашел в OGSR [se_stalker.script] вот такой комментарий:

Spoiler

-- Dsh (c):
-- Это включать не нужно, будут проблемы. Ни движок, ни скрипты на это
-- не расчитаны. Проблема в том, что оно работает и клиентские данные
-- сохраняются. При том, все данные, не только то, что скрипты
-- запишут, но и то, что движок сохраняет. В этом-то и
-- проблема. Например, движок сохраняется информацию о best_danger и
-- вот что получается. На Янтаре у долговца был best_danger, ну пусть
-- другой долговец. Теперь мы уходим с локации и best_danger остается
-- в клиентских данных. Через некоторое время этот долговец тоже
-- уходит с Янтаре и мы с ним пересекаемся в Баре. И что мы видим?
-- Долговец в истерике, т.к. у него есть best_danger, который был
-- загружен из клиентских данных, т.к. они не были очищены из-за
-- keep_saved_data_anyway(). Тоже самое с хитовой памятью. На другой
-- локации у непися всплывает хит, m_object которого нет, т.к. он
-- остался на той локации, где хит был нанесен.
--
-- Со скриптами тоже проблема всплывает. Например, в
-- xr_logic. Представим, что непись был в смарте, получил там работу и
-- у него была активная логика. Мы ушли с локации и активная логика
-- была сохранена в клиентских данных. Потом непися выгнали из смарта
-- и его приняли в другой. Все это было в оффлайне и клиентские данные
-- все еще содержат активную логику первоначального смарта. Теперь мы
-- пересекаемся с ним на какой-нибудь локации и тут xr_logic
-- восстанавливает его активную логику и оказывается, что никакой
-- вертекс пути это логики, на этой локации не существует. Движок
-- обижается и падает.
--
-- Переделывать все это я не вижу смысла. Сохранение активной логики
-- скриптовыми методами требует меньших усилий, чем приведение всего
-- этого в порядок.
--
-- function se_stalker:keep_saved_data_anyway()
--   return true
-- end

 

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

[h0N0r 278]

14 часов назад, Norman Eisenherz сказал:

Не знаю, насколько это подходит…

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

[Norman Eisenherz 225]

Можно ли методом obj:set_nonscript_usable(false) "окирпичить" предмет вроде аптечки или оружия? Какой биндер править? Прямое изменение при сбросе предмета не мешает потом его поднять и использовать.

[Zander_driver 10 166]

7 часов назад, Norman Eisenherz сказал:

не мешает потом его поднять и использовать.

И не помешает, т.к. аптечки и подобное юзаются движком напрямую, без участия скриптов.

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

[madrazor 10]

Есть ли в сталкере возможность спавнить вейпоинты через скрипт?

[mole venomous 2 997]

На движке ОГСР можно вынести пути во внешний файл. А скриптом можно заспавнить НПС, которому в кастом дате указать пути, пописанные в этом файле. 

Скрытый текст

Указать путь к путям () в файле external.ltx

Дальше ручками добавлять новые секции с прописанными к ним кастом-датами.

А в кастом дате уже указываем пути и остальное:

Или при спауне скриптом сразу записывать дату, но, насколько помню, таким образом не всё туда запишется.

Скрытый текст

Пример с функциями АМК-мода:

 

local obj=amk.spawn_item("ros_killer_respawn_1",vector():set(-70.358726501465,-13.440641403198,-160.03511047363),107,201811)
    if (IsStalker(obj)) then 
        local t=amk.read_stalker_params(obj) 
        t.custom="[logic]\nactive=walker\n[walker]\npath_walk=add_merc_esc_walk\npath_look=add_merc_esc_look"
        amk.write_stalker_params(t,obj)        
    end

 

 

Изменено 13 Апреля 2023 пользователем mole venomous

[imcrazyhoudini 177]

@mole venomous по-моему он спросил не о кастом дате, а о возможности спавнить вэй-поинт скриптом.

[mole venomous 2 997]

Может, я чего-то не знаю. Но точки путей, это объекты, которые можно заспавнить?

Я лишь подумал, что некорректно поставлен вопрос 

[dsh 3 820]

В OGSR точки пути можно и скриптом создавать, если нужно именно через скрипт.