Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Andrey07071977 18]

Также как вариант, можно послать сигнал что предмет удален, и дать всем подписчикам возможность удалить из списков. В этом и есть гибкость event систем

[xStream 86]

А не получится так, что за ним шел коллбек, который у себя вел учет предметов в инвентаре(на on_take добавлял в словарик, на on_drop удалял из словарика).

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

Однако, не могу не согласиться с Сашей - лучше дисциплины ничего нет, легкие ограничения помогают выдерживать строгость проектирования и не позволять появляться ситуациям типа undefined behaviour.

 

это вообще отдельный файл,

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

 

Я же не могу никак заставить следовать этому требованию всех пользователей системы событий.

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

ЗЫ Сделала я это правда существенно позже, чем отдала ее в огсе, а потом было влом :-)

Изменено 4 Февраля 2015 пользователем xStream

[Allender 11]

Здравствуйте!

Уважаемые, @Malandrinus, @xStream,

прочел ваши обсуждения – сложилась впечатление, что все же, несмотря на 2015г, что-то еще делается для сталкера? Не очередная "солянка", а новое-новое по возможностям движка/скриптов?

Видел проект XRayEx до моменты открытия исходников. Сейчас ведутся какие-то работы по расширению возможностей движка (используя исходники, с полной/частичной компиляцией)? Где можно посмотреть/почитать?
Если запрещено правилами, просьба к модераторам вырезать абзац.

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

[xStream 86]

 

 

новое-новое

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

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

[RayTwitty 492]

а новое-новое по возможностям движка/скриптов?

Конечно, только многие пока шкерятся по приватным свн Изменено 4 Февраля 2015 пользователем Shadows

[Andrey07071977 18]

, многие, но не все

 

@Allender, вот например:

 

ЧН

https://github.com/OpenXRay/xray-15

 

ЗП

https://github.com/avoitishin/xray-16/wiki

 

ТЧ

https://github.com/OpenXRay/xray

Изменено 8 Мая 2019 пользователем W.A.S.P.

[Dennis_Chikin 3 658]

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

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

 

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

Опять же, выбрасыванием вносится путаница - кто выбросил, зачем выбросил ?

не надо исправлять макаронный код

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

который у себя вел учет предметов в инвентаре

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

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

 

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

В общем, "должен остаться только один" - в смысле, нечто, что отлавливает и сортирует движковые события (нажали кнопку "выбросить", нажали кнопку "переложить", продали, нечто в аномалию попало). Этот кто-то один и все критичные манипуляции осуществляет. С учетом ранее отловленного движкового.

 

Мда, опять же та же "песочница" получается (или "ивинты" и т.д.) - только названия разные, и разная степень применения технических средств принуждения. Вкус фломастеров...

Изменено 4 Февраля 2015 пользователем Dennis_Chikin

[warwer 900]

@Andrey07071977,

да, на ТЧ двиг правки хороши. Вот только, как по мне (скорее всего ошибаюсь), наиболее толковый двиг - ЧН. А на него, как раз, правок почти и нет. Печаль...

[abramcumner 1 157]

@abramcumner, в таких случаях перед удалением можно дропать, как вариант.

 

ну или банально дропать, как предлагают ребята.

Его в on_drop и удалили. А половина модулей об этом не оповещена.

 

Также как вариант, можно послать сигнал что предмет удален, и дать всем подписчикам возможность удалить из списков. В этом и есть гибкость event систем

 

2) Там где надо я могу выстрелить еще один ивент, скажем on_post_take (после взятия) или on_pre_drop (перед удалением),

Есть в этом нечто забавное - остановить ивент, а потом вместо него посылать новые. Хотя вполне возможно - оставшейся части посылать уже не on_drop, а on_release. Но тогда модулям придется обрабатывать 2 ивента вместо одного.

 

Вообще "концепция ивентов" на мой взгляд включает следующие 2 пункта:

- локальность подключения к системе ивентов - иначе можно и через bind_stalker подключаться,

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

 

Пример с инвентарем привел из-за явной симметрии on_take/on_drop и такого же явного ее нарушения. А так это может быть маленький квестовый модуль, который следит за каким-то предметом и обновляет статус побочного квеста. Явно же это не тот модуль, который надо регистрировать первым и в специальном реестре. Просто маленький иногда подглючивающий квест

Изменено 4 Февраля 2015 пользователем abramcumner

[Malandrinus 615]

 

 

локальность подключения к системе ивентов

Это так и есть. В наличии имеется глобальный менеджер событий, через который и происходит подписывание/отписывание. Ну ещё разумеется надо расставить вызовы событий.

 

 

 

гарантированность доставки события

С какой стати? Если предмет удалён, то потерян смысл доставлять сообщение дальше. Ещё раз хочу подчеркнуть. Огрызок объекта в виде его онлайновой части - это не повод думать, что объект ещё существует. Его уже нет, а значит нечего дальше передавать. Рассмотри это с такой точки зрения. Событие с объектом - это нечто вроде доставки почты. Мы идём по комнатам и спрашиваем "это для тебя?" Как нашли адресата, то отдали ему предмет. На этом всё, дальше доставлять нечего и некому.

[Dennis_Chikin 3 658]

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

[xStream 86]

 

 

Его в on_drop и удалили. А половина модулей об этом не оповещена.

, ммм. Что-то я потеряла нить размышлений.

Я говорила не конкретно об item_drop, а каких-то других вещах - например скриптом сделали удаление (не внутри какого-либо колбека), имитируем дроп, стартанув ивент вручную.

Видимо, мой полет мысли слишком стремительно увел ее, мысль, далеко от конкретного примера

[Карлан 1 049]

@Dennis_Chikin, так мы про удаление говорим .

 

У себя такие косяки истребляю простановкой нескольких вызовов в один коллбек в разных местах, как раз таки всякие "on_pre_drop-on_drop-on_post_drop" и присутствуют, ну и по ситуации еще специальные, если нужно (с дополнительным кодом). На самом деле все можно очень гибко настроить, и делать хоть на каждый случай свой сигнал (ну это утрированно, разумеется). А далее уже да, приоритеты, какой-нибудь "объем рюкзака" в начало, а вот квест на проверку итема - в конец (т.к. может уже и не придется проверять). 

 

А половина модулей об этом не оповещена.

Я может чего не понимаю, но что, собственно, мешает оповестить?

 

 

Мы выбросили из инвентаря предмет, надо его обработать, а если нечего обрабатывать?

Эмм, это был риторический вопрос? Если нет, то, вот там где удалили и ставим что-то вроде стопа, т.е. для этого предмета дальше не нужно отрабатывать всю вереницу. А на следующий предмет уже все будет отработано. В этом и есть весомый плюс, который описал маландринус .

Изменено 4 Февраля 2015 пользователем Карлан

[xStream 86]

 

 

Есть в этом нечто забавное - остановить ивент, а потом вместо него посылать новые. Хотя вполне возможно - оставшейся части посылать уже не on_drop, а on_release. Но тогда модулям придется обрабатывать 2 ивента вместо одного.

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

Главное, что такой ивент можно кинуть до непосредственно удаления, как только все "дочерние" колбеки отработают - сносим объект и стопаем текущий. Никаких проблем.

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

[Desertir 202]

Смысл большинства ивентов заключается не только в обычном срабатывании в определенный момент, но и в передаче зависимых объектов/сущностей. Мы выбросили из инвентаря предмет, надо его обработать, а если нечего обрабатывать?

С другой стороны, клиентский объект у нас еще есть, часть... В общем эта клиент-серверная система для сингла всегда меня поражала своей гениальностью (в клиентском событии выпиливаем серверный объект, или как там).

 

На самом деле систему ивентов надо делать на уровне движка, я считаю. Пусть он кидает сообщения, что объект затёрли, и вешать на него все удаления из таблиц\счётчиков и т.п.

Изменено 4 Февраля 2015 пользователем Desertir

[xStream 86]

Хорошо, вот вам еще решение  в лоб: создавать два сообщения on_item_drop_safe и on_item_drop.

safe кидается перед обычным. Подписчики на safe гарантируют сохранность "объекта доставки".

Это своеобразный аналог const функций в том же C++, например. Просто в ЛУА такого нет.

[Dennis_Chikin 3 658]

Э... Да, что-то полет мысли... случился, да.

 

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

 

На примерах, что-ли...

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

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

 

По идее, все хорошо, если скрипт с лебедями ничего не хочет от выбрасываемого предмета. А он может, например, хотеть, чтобы предмет был одноразовым, и ТОЖЕ пытается его удалить.

Но, первый скрипт тоже хочет удалить этот же предмет.

 

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

 

Вот как-то так, вроде.

 

Да, с получением предмета, если его тут же пытаются удалить - еще хуже.

 

 

Пока очевидных решений 3, со своими достоинствами и недостатками:

1. Удаляем только из специального места в специальный момент.

2. Кто первый успел, тот и сработал, до остальных сей факт не долетает вообще ни в каком виде.

3. Вариация п1. - "блокировка" собственно удаления тем, кто заявил свои права на эту опереацию раньше.

Ну и то, которое было: проверять - а есть ли еще объект, с которым хотели работать. В общем-то вариация п2.

 

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

 

 

2 Allender: ну так я здесь же решения и перечислил, из уже использующихся. С разными вариациями. Для частного случая, когда за всем этим кто-то следит, и удаление происходит по инициативе скриптера. Возможно, что-то и забыл.

Более общий случай требует мер несколько более радикальных.

Изменено 4 Февраля 2015 пользователем Dennis_Chikin

[Allender 11]

@Dennis_Chikin, ура, теперь стала понятна мысль, которую обсуждаете.

А что мешает сесть и написать прослойку между существующими вызовами и движковыми функциями, в которой будет стек вызов на удаление, перемещение, потерю предметов и тд?

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

Например, поймали  on_drop, это же колбек на потерю предмета, ловится через bind.stalker? Если да, то как в примере выше, предмет пытаются удалить две функции. Обе добавили вызов на удаление в стек "прослойки". Далее, все просто... система взяла вызов из стека обработала (удалила) предмет, и выкинули из стека все вызовы на удаленный объект. 

[Desertir 202]

Подписчики на safe гарантируют сохранность "объекта доставки"

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

Моя думает это сложно - универализировать под все-все хотелки. В винформах есть такой класс KeyEventArgs. Там всякие данные по событию храниться, и там же есть свойство Handled, типа событие обработано и все, дальше не идем. Это аналог e:stop()/return true. И таких классов под каждое событие.

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

[xStream 86]

 

Э... Да, что-то полет мысли... случился, да.

Иногда полезно. В общем случае это так и работает, как там написано.

 

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

Во-первых, проверять не надо - второй не будет вызван.

Во-вторых, можно использовать подход разделения "безопасных" и "небезопасных" колбеков (в случае, если лебедятам не надо удалять объект, можно на on_item_drop_safe подписать).

В-третьих, do_swan_dance и on_drop - разные события: внутри on_drop сказать - станцуйте (без удаления), а потом удалить.

В-четвертых, можно кидать всякие item_will_be_removed или on_release - и подписать любителя лебедей на оба события - on_drop и on_release.

В-пятых - можно таки указать приоритет, если песочница позволяет (но я бы не рекомендовала, не хорошо это)

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

Но вот послединй пункт отдает поганым извратом и костылями.

По хорошему в игровой ситуации практически не бывает пересечения интересов.

 

 

Это должен гарантировать скриптер

Естественно, просто принять соглашение, что в таком ивенте трогать "посылку" нельзя.