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

[Dennis_Chikin 3 658]

Когда-то давно в НС появился "ПДА" для хранения переменных, не лезущих в pstor актору (netpacket_pda_binder.script)

в числе прочего там есть такое:

function init(obj)
   local new_binder = my_binder(obj)
   obj:bind_object(new_binder)
end

class "my_binder" (object_binder)
function my_binder:__init(obj) super(obj)
end

 

При переходе в онлайн этого самого netpacket_pda дергаются последовательно *:__init(), init(), *:reload, ну и далее по тексту.

Но КАК ? В смысле, netpacket_pda_binder.init() кем вызывается вот в таком-то вот порядке ?

[Dennis_Chikin 3 658]

Dennis_Chikin, функция netpacket_pda_binder.init() вызывается в том случае, если в конфиге секции объекта (например для device_pda) будет прописан параметр:

script_binding = netpacket_pda_binder.init

...

Ну а далее, последовательность вызова движком методов самого биндера можно подсмотреть в xr_motivator.script, где сами разрабы оставили нам комменты:Примечание: Метод 'load' будет вызываться только для объекта(ов) уже сохранявшегося в игре (если был save), т.е. при первом спавне объекта в игру этот метод не вызывается.

 

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

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

Изменено 15 Декабря 2012 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Очень разумная мысль, но не удержусь от подковырки: "А что же такого именно КПК'шного ты собрался хранить в pstor'е объекта КПК-актора?", что ради этого специальный биндер задействовать решаешься?

 

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

 

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

В общем, все, что при отбирании у актора оного ПДА актор теряет. Или, наоборот, приобретает при получении ПДА/флэшек.

 

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

[Dennis_Chikin 3 658]

В amk есть функция amk_mod.spawn_unspawned_respawners()

Она крейтит эти самые респавнеры, и пишет им параметры в customdata. Затем они подхватываются, и записанное волшебным образом можно считать из obj:spawn_ini(). Но как сделан этот фокус ?

 

И, кстати, в чем смысл функции se_respawn.reinit_spawner_params(), если на момент ее вызова фокус еще не произошел ?

[Dennis_Chikin 3 658]

А где фокус?

Разобрался. Фокус был в том, что :init() дергается сразу же, как объект создан. Или непосредственно прямо в alife():create(), или при возвращении из нее.

Соответственно, obj:spawn_ini() возвращало первый раз пустую строку, и только потом уже можно записать customdata.

[Dennis_Chikin 3 658]

Вот интересно, в bind_physic_object.script в generic_physics_binder:update() все нормально с установкой коллбэков ? В оригинале имеется в виду.

 

Действительно есть такие events, после которых их надо заново выставлять в каждом апдейте ?

А сбрасывать их при дестрое не надо ?

[Dennis_Chikin 3 658]

level.prefetch_sound() в SOC вообще работает ?

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

Но результатов от того, что он там делал - не вижу.

[Dennis_Chikin 3 658]

звуки грузились через npc:add_sound() ?

 

Вообще, если взять какую-то тушку, и скормить ей ВСЕ - будет вполне себе кэширование.

Но я не разобрался, что должно быть в параметрах. Там в скриптике была попытка сделать тупо (вместо prefetch в preload() было тупо add_sound по всем подкаталогам, но оно грузит только первый, от остальных отказывается.

[Dennis_Chikin 3 658]

Подозреваю, что для второго варианта должны быть какие-то "идеологически правильные" id.

[Dennis_Chikin 3 658]

А проверьте меня кто-нибудь, правильно ли я понимаю:

 

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

2. Гулаг меняет state, и в нем появляются доступные работы.

3. В гулаг засасывается новый непись.

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

Что при этом происходит с неписем ?

 

Аналогично с выгнанным из гулага неписем.

[Dennis_Chikin 3 658]

Что-то как-то не понял по object_binder (и про скрипт для серверного объекта тоже):

 

В части имеющихся изначально или в модах скриптов прописаны методы типа:

function generic_object_binder:reinit()
object_binder.reinit( self )
end

или, соответственно,

function se_artefact:can_switch_offline()
return cse_alife_item_artefact.can_switch_offline( self )
end

 

То есть, они ничего нового заведомо не делают, но тем не менее явно прописаны.

В других скриптах эти методы отсутствуют (то есть, очевидно, просто тупо наследуются, если есть от чего, и там все, что надо, очевидно, есть.

 

Вопрос: эта разница она зачем-то, или это остался мусор от чего-то,  или я чего-то не понимаю ?

 

То есть, если вот такое вот отовсюду поубирать - какие эффекты следует ожидать ?

 

 

[Dennis_Chikin 3 658]

Бр-р... Стало еще непонятнее.

Вот конкретные примеры были: из bind_monster и из se_artefacts.

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

[Dennis_Chikin 3 658]

Гм, еще уточняю:

А сама строка function generic_object_binder:reinit() end - вот именно в таком виде, вообще нужна, или это, все-таки, мусор ?

Ну и прочие save(), load(), update() ?

 

И, кстати, чудесное, аж из самого оригинала:

function generic_object_binder:reload(section) object_binder.reload(self, section) end
function generic_object_binder:reload(section) object_binder.reload(self, section) end

- ага, два раза в одном классе.

Это у нас переопределение, или 2 вызова ?

[Dennis_Chikin 3 658]

Капрал Хикс, а он регистрируется ? Лог вывести ? Возможно, это таки другой класс, и другой скрипт, а не se_item.

Ну и task_manager.ltx еще раз проверить, тоже выводом в лог же.

 

 

P.S. А вообще мне этот механизм не нравится принципиально. Ибо - жрет.

 

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

После закрытия окна остаток денег просто плюсуется к общим деньгам.

 

Смысл - убрать поршни и регулярные проверки на "есть квест/выполнен/провален", и дурацкие диалоги с вопросами ("я буду, я не буду, я отказываюсь, да нет. не отказываюсь...").

Изменено 27 Июля 2013 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

В bind_smart_terrain.script есть код:

function smart_terrain_binder:net_spawn( server_object )

if not object_binder.net_spawn( self, server_object ) then return false end

-- получить ссылку на настоящий серверный объект

self.se_smart_terrain = alife():object( server_object.id )

Вопрос: до этого самого server_object как-то можно добраться, чтобы хотя-бы просто тупо его прибить ?

[Dennis_Chikin 3 658]

alife():release(server_object.id) - это оригинально, да.

И в любом случае желательно бы сделать это еще до netspawn()

 

По тому как по имени находится то же, что и alife():object( server_object.id ), благополучно удаляется, а потом здесь получаем nil со всеми вытекающими...

Изменено 12 Августа 2013 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Удалить я хочу smart_terrain. В данном случае. По имении что-то находится, и удаляется.

Потом обнаруживается некий server_object, у которого id удаленного smart_terrain'а.

Вот хочется, чтобы и он тоже удалился, вместе с binder'ом. Желательно, сразу.

[Dennis_Chikin 3 658]

Смарт не нужен. Совсем. Имя известно. Получаем, удаляем. Через 15 секунд - вылет. db.add_smart_terrain() получил из binder'а nil, и попытался извлечь из него id.

Странный какой-то жизненный цикл...

[Dennis_Chikin 3 658]

Интересно, на сколько я неправильно понимаю, что здесь что-то не так (amk-мод, amk.script):

function fill_item_packet(ret,stpk,updpk)

stpk:w_float(ret.condition)

updpk:w_u8(ret.updnum_items)

updpk:w_float(ret.updpos.x)

updpk:w_float(ret.updpos.y)

updpk:w_float(ret.updpos.z)

readvu8uN(updpk,ret.updcse_alife_item__unk1_q8v4)

readvu8uN(updpk,ret.updcse_alife_item__unk2_q8v3)

readvu8uN(updpk,ret.updcse_alife_item__unk3_q8v3)

return ret

end

Но ведь ни у кого ж ни разу не вылетало ?

Изменено 2 Сентября 2013 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Удобная, но неторопливая. Кстати, на яндексе отдача файлов в очередной раз сдохла.