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

[panzyuza 41]

Artos, благодарю.Вот еще вопрос.Используя данную функцию, как правильно военным выставить нейтралитет ГГ без всупления его в группировку?

[Artos 99]

panzyuza, если вопрос ко мне - мой ответ: "Смотри сам в куче готовых примеров и пробуй" ...

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

Изменено 2 Мая 2012 пользователем Artos

[Malandrinus 615]

Artos,

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

В этой ситуации всё ещё хуже и дополнительный код проверки не поможет. Проблема в том, что если запомнить ссылку на объект, скажем клиентский объект вертолёта, а потом удалить вертолёт или просто отправить его в оффлайн, то произойдёт следующее: движковый объект преспокойно удалится/уйдёт в оффлайн, а вот объект Lua вместе с ним не удалится, поскольку этого не даст сделать сборщик мусора из-за того, что на объект имеется ссылка. В итоге имеем объект, за которым уже нет реального движкового объекта. При попытке вызвать любой метод этого объекта будет вылет. Не помню точно, как именно этот вылет выглядит. Вроде как на нодвд это обычно вылет без лога.

Здесь два решения:

1. Не хранить ссылки на объект, а только его id + естественно делать проверку существования при каждом обращении

2. Аккуратно подчищать ссылки при удалении объектов. По идее, это надо делать в том-же биндере скорее всего в net_destroy. Здесь имеется дополнительная проблема, что отследить все ссылки на самом деле сложно чисто организационно. Вот недавно выловили баг, оставшийся ещё с оригинала. Оказывается, в таблице-хранилище каждого объекта в db.storage есть поле для текущего врага и это поле хранит именно ссылку на врага и его никто не чистит. Ошибки посыпались тогда, когда повысили "злопамятность" неписям и повысился шанс того, что они уйдут в оффлайн раньше, чем боевая схема поведения начнёт игнорировать врага. Пришлось дополнительно подчищать ещё и это поле у каждого непися, а не только глобальную таблицу. Надо понимать, что если таких мест становится слишком много, то контролировать их все становится просто невозможно, поэтому подход с хранением id является универсальным.

[abramcumner 1 159]

Надо понимать, что если таких мест становится слишком много, то контролировать их все становится просто невозможно, поэтому подход с хранением id является универсальным.

С таким же ид может быть уже совсем другой объект. Лучше чистить

Можно подумать над апгрейдом db.storage. Везде использовать ссылку на объект из него, а в нем ссылку на клиентский объект обнулять по нет_дестрой. А дальше и над заменой lua_help`ных функций, чтобы они возвращали не клиентский объект, а спец объект. Потом использовать Null object, чтобы убрать проверки на существование объекта Но это уже будет в сталкер2

Изменено 2 Мая 2012 пользователем abramcumner

[Artos 99]

malandrinus

Прошу уточнить, как именно решили проблему с полем хранящим ссыку на об'ект - чисткой поля или заменой ссыдки на об'ект его ID'ом?

Просто у себя как раз заменил в xr_combat_ignore.script заполнение поля не об'етом а его id'ом и вот ... жду, появятся ли баги. ;-)

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

 

abramcumner

Ну, во-первых, если 'такой же' ID'овый обект стал воагом, попав в поле - то какая разница? Ну и ничего не мешает контролировать то, что вместо исходного ID занят уже иным об'ектом. Грубая зачистка конечно упрощает проблемы, но и ... порою саму игру. ;-)

Изменено 2 Мая 2012 пользователем Artos

[Malandrinus 615]

abramcumner,

С таким же ид может быть уже совсем другой объект. Лучше чистить

Да, с id выходит тоже надо чистить, но уже реже, только при удалении объектов. Получается, что подход с id имеет свои ограничения, поскольку контролировать момент удаления можно далеко не для всех объектов. Однако для монстров/неписей/физических объектов вполне годится. Неудобно будет со всякой инвентарной мелочёвкой: патроны, аптечки/еда и т.п., поскольку они удаляются движком, но такого рода объекты обычно и не надо учитывать, а если надо, то это уже специальные случаи и имеют свои решения.

 

Так что насчёт "универсального подхода" я был неправ, нет здесь такого.

 

Но это уже будет в сталкер2

Т.е. никогда, в свете последних новостей =)

Кроме шуток, это всё возможно, но IMHO не всегда нужно. Насчёт прокси можно и подумать, а вот Null Object pattern - вещь более чем сомнительная, поскольку может (и с гарантией будет) скрывать ошибки и вместо повышения надёжности в итоге приведёт к появлению неуловимых и неотлаживаемых багов.

 

Artos,

как именно решили проблему с полем хранящим ссыку на об'ект

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

 

Ну, во-первых, если 'такой же' ID'овый обект стал воагом, попав в поле - то какая разница? Ну и ничего не мешает контролировать то, что вместо исходного ID занят уже иным об'ектом. Грубая зачистка конечно упрощает проблемы, но и ... порою саму игру. ;-)

Если так разобраться, то проблем id вызывают не меньше. Помогают два факта:

1. Удаление - вообще говоря не такое уж частое действие и как правило достаточно контролируемое, если не считать всякую инвентарную мелочёвку, как я говорил выше.

2. Движок назначает новые id "на удалении" от последнего и рандомно, что несколько сглаживает возможность коллизий, хотя и не исключает их совсем.

 

[Artos 99]

malandrinus, у меня в респавнерах есть контроль чистки убитых иль исчезнувших уже заспавненных об'ектов респавнерами и ... хорошо видно сколь нередко возникает подмена об'екта с таким же ID'ом. Причем подмена как схожим по тиму, так и абсолютно иными классами. ;-) Уже описывал эту проблему, которая скорее всего и привела к тому, что разрабами и не используется респавн по запоминаемому времени периода респавнов, т.к. списки забиваются именно неубираемыми ID'ами вроде как уже заспавненных ...

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

Изменено 2 Мая 2012 пользователем Artos

[_Призрак_ 11]

Artos

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

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

 

Таблицы db.storage (и иже) хотя и зависят от онлайновых появлений в игре об'ектов, но как раз никак не отражают - в онлайне или в офлайне об'ект.

Смотря где. Если смотреть по чистым скриптам то отображают, т.к. обьект записывается в табличку при вызове net_spawn() и удаляется при net_destroy(). Следовательно обьект в таблице, пока он в онлайне. Не так ли? Ну а если кто-то неаккуратно работает с обьектом, то тут уж ничего не поделаешь.

 

Как, в прочем, и не оговорено вообще что за вертушки и при каких условиях собрался удалять panzyuza.

Если включить логику и понять что локации сталкера в большенстве своем гораздо больше 150 метров по длине, поэтому тут нужно всегда помнить о том что обьект может быть в оффлайне. И тогда при попытке получить обьект при помощи функций пространства level ничего не даст.

 

*Shoker*

Спасибо не знал. Точнее не замечал этого момента

[Malandrinus 615]

Artos,

хорошо видно сколь нередко возникает подмена об'екта с таким же ID'ом.

Ну значит чистить и ещё раз чистить. Вот здесь бы пригодился сборник этаких "шаблонов", т.е. типичных подходов для серверных, клиентских объектов разного типа и где и как это делать.

[Artos 99]

_Призрак_, прекращай демагогию. И никто не называет обезьяну человеком и тогда уж покажи, плз, где же ты в исходных вопросах/ответах увидел упоминания про онлайн?

Ну и далее твои словесные упражнения читать бессмысленно:

_Призрак_: Следовательно обьект в таблице, пока он в онлайне

Почитай ка матчасть, а то у вас каша в голове, что даже после того, как сказано, что таблицы никак(!) не завязаны на 'онлайн' ты продолжаешь попугайничать. Изменено 2 Мая 2012 пользователем Artos

[abramcumner 1 159]

а вот Null Object pattern - вещь более чем сомнительная, поскольку может (и с гарантией будет) скрывать ошибки и вместо повышения надёжности в итоге приведёт к появлению неуловимых и неотлаживаемых багов.

Добавить в дебаге логирование и вывод стека при обращении к такому объекту, можно и аборт добавить.

 

Вот здесь бы пригодился сборник этаких "шаблонов", т.е. типичных подходов для серверных, клиентских объектов разного типа и где и как это делать.

Если скрипты пишет один человек - достаточно небольшой дисциплины. Несколько - нужен аборт, чтобы сразу по рукам бил. Это как с mark_item_dropped; хорошая задумка оказалась совершенно не нужной, потому что использовалась/ется не всеми.

[Malandrinus 615]

Artos,

таблицы никак(!) не завязаны на 'онлайн'

Я полагаю, что _Призрак_ имел в виду, что при налаженной регистрации/очистке таблиц из биндера они отражают факт нахождения объекта в онлайне. Т.е. объект появляется в онлайне - он появится и в таблице, так что причинно-следственная связь здесь вполне имеется =)

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

 

[Artos 99]

malandrinus, однако речь в исходных вопросах не шла о причинно-следственной связи ...

1. Большинство ошибок у модмейкеров, как уже говорил, идет как раз на зашоренность "постулата" - раз в таблице - значит в онлайне и наоборот. Однако, таблицу чистит/пополняет биндер клиентского об'екта, а состоянием онлайна - серверные методы отслеживают и устанавлявают, и между этими причинами и следствиями имеется временной зазор, на который и натыкается немало модмейкеров ... Да и гулаги с их статусами работ привносят чехарды ...

2. Логика же _Призрак_'а изначально ошибочна, т.к. даже не зная о том, что есть иль нет в таблицах db обекты вертушек, довольно странно не помнить, что схемы логики (а они только с онлайновыми об'ектами работают) управляют вертушками на всех точках локации. Ну как еще к вагончику прилетит вертушка и облетев - улетит обратно? Какие тут 150 метров от свич-дистанции?! ;-) У вертушек то и дистанция ракетного огня почти и есть - 150м (max_mgun_attack_dist = 150 , max_rocket_attack_dist = 250).

A, если еще вспомнить, что куча иных классов об'ектов во всех уголках локации и не собираются удаляться из таблиц (аномалии, костры, лампочки, ...) по удалению от них актора, то совсем его непонятки с функцией удаления неясны.

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

Изменено 2 Мая 2012 пользователем Artos

[Zander_driver 10 334]

Проблема в том, что если запомнить ссылку на объект, скажем клиентский объект вертолёта, а потом удалить вертолёт или просто отправить его в оффлайн, то произойдёт следующее: движковый объект преспокойно удалится/уйдёт в оффлайн, а вот объект Lua вместе с ним не удалится, поскольку этого не даст сделать сборщик мусора из-за того, что на объект имеется ссылка. В итоге имеем объект, за которым уже нет реального движкового объекта. При попытке вызвать любой метод этого объекта будет вылет. Не помню точно, как именно этот вылет выглядит. Вроде как на нодвд это обычно вылет без лога.

А есть ли хоть какой то способ проверить клиентский объект на соответствие движковому? Я так понимаю стандартная проверка

if object then

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

[_Призрак_ 11]

Как вариант:

local id = obj:id()

if alife():object(id) then --Существует серверный обьект

end

Пример взят из оригинальных скриптов

 

Перепрочти вопрос и процитированное в нем, обратив внимание на: "При попытке вызвать любой метод этого объекта будет вылет. ", и в последующем не спеши с ответами из серии "В огороде бузина, а в киеве дядька". --/Artos

[x]

Изменено 6 Мая 2012 пользователем Artos

[Artos 99]

Zander_driver: А есть ли хоть какой то способ проверить клиентский объект на соответствие движковому?

Если движек уже удалил исходный об'ект, то как можно проверить (и тем более сравнить на соответствие) несуществующее со ссылкою (линком) на это когда-то существовавшее? ;-)

Судя по фразе:

malandrinus: При попытке вызвать любой метод этого объекта будет вылет.

- то вероятно он имеет ввиду, что даже проверка типа:if type(object) == 'userdata' and type(object.id) ~= 'nil' then ... - может привести к фатальной ошибке, хотя именно так в тестовых кодах порою я пытался отловить ошибки ...

Zander_driver, ... а мододелы туда навешивают своих кодов и тащат эти данные уже бог знает куда... нервозная ситуация

Чтобы не нервничать нужно не брать не свои коды без перепроверки, а все же тщательно перепроверять и вносить необходимые изменения, т.е. хранить не об'екты, а их индексы, получая об'екты по индексам заново (и гарантированно!).

[kratos888 0]

Всем доброго времени суток.

 

Я пытаюсь сейчас сделать свою модель поведения к "Теням Чернобыля". Хочу реализовать схему обыска трупа, как в ЗП (очень впечатлила работа этого скрипта в ЗП). В этой модели поведения есть два действия, которые непись должен проделать:

1) Непись идёт к назначенной точке

2) Непись проигрывает анимацию, стоя на этой точке

 

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

 

Эвалуатор, где отмечаются условия и соответствующая точка назначения, у меня сделан. И второй эвалуатор, где отмечается условие, что непись находится у точки, тоже готов.

 

Вот теперь не могу разобраться с самими action'ами...

Для первого действия в action:initialize() я вписываю self.a.vertex_id = nil и self.a.vertex_position = nil - т.е. задаю пока нулевые значения (точка, куда направляю непися, и точка, куда непись будет смотреть во время проигрывания анимации), а также задаю параметры движения через state_mgr.set_state().

В action:execute() я "говорю" неписю, что нужно идти к назначенной точке (точка задаётся через id объекта, к которому непись должен подойти).

В action:finalize() просто говорю неписю, что нужно переходить ко второму действию, проигрыванию анимации на точке - ничего не пишу, просто action_base.finalize()

 

А вот ко второму действию у меня вопросы. Я не знаю, куда нужно вписать проигрывание анимации на точке всего один раз - пробую писать в initialize() - но это по-моему не то; пробую писать в execute() - эта функция отвечает за регулярное обновление действие, и непись стоит на точке и постоянно проигрывает одну и ту же анимацию, или просто стоит возле точки; а вот в finalize() - тоже желаемого эффекта не даёт, тем более хочу сюда вписать условия отмены действия (обнуление точки, высвобождение объекта от непися и т.д.)..

 

 

Кто поможет, как мне реализовать подобное в два действия:

1) Непись подходит к точке, выбранной в эвалуаторе;

2) Непись проигрывает анимацию на точке и бросает все дела с этим скриптом, возвращается к прежнему состоянию.

 

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

 

 

[Artos 99]

kratos888

Неясно, в чем же нужна помощь? Если ты делаешь аля xr_corpse_detection.script из ЗП, то в чем загвозка "спопугайничать"? Ведь все достаточно внятно и портируемо на ТЧ.

Также неясно, чем не угодили уже имеющиеся схемы обыска трупов из модов именно на ТЧ? Чем таким не угодил, например, watcher_act.script из AI-пака xStream или его многочисленные клоны под любой патч? В нем также все имеется и можно посмотреть как и где сделано.

 

Примечание: ИМХО, как раз скрипт из оригинальной ЗП достаточно кастрирован и его "работа" далека от "впечатляющей" ...

[kratos888 0]

Artos, ставлю этот скрипт из ЗП на ТЧ - движок выдаёт неизлечимые ошибки типа "state_mgr.script C stack overflow" - переполняется какой-то стек, движок всё время норовит выдать что-то подобное.

 

А по поводу watcher_act - этот скрипт эффективен, но пока не удаётся сделать его эффектным - хотелось бы сделать все переходы анимаций не при помощи отдельных параметров, а через state_mgr.

Изменено 6 Мая 2012 пользователем kratos888

[Artos 99]

kratos888, чтобы построить здание необходимо и кирпичи/блоки уметь делать и подготовить их ...

Ну как можно пихать скрипт из одной версии игры в другую и сетовать мол что выдает ошибки?! Вам знакомо такое понятие как адаптация?

Ну а для "эффектной" тавтологии следует подобрать иное место (во флудильне). Чем же неэффектен watcher_act? Озвучки не хватает? Ну а руки с головою на что?

kratos888: ...хотелось бы сделать все переходы анимаций не при помощи отдельных параметров, а через state_mgr

- любая похотелка должна быть целесообразной, а не ради 'так прикольнее' ...

- что мешает сделать соответствующие 'кирпичики', слепив их из 'параметров' и добавить их в state_mgr? (хотя собственно весь 'кирпичик' и состоит то из одного параметра-анимации)

 

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

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

Изменено 6 Мая 2012 пользователем Artos