Monnoroch

Вот, еще немного дополненная версия: дефолтные настройки вынесены из логики. malandrinus, теперь если в mon_utils.default_slot поставить unique = true, то получится ровно твоя система, но которую можно использовать более гибко http://ifolder.ru/28160609

Вот, добавил собственно то, что хотел: возможность множественных подключений слотов, возможность это запретить, некоторые настройки с этим связанные и вообще привел в порядок код. http://ifolder.ru/28140737

xStream, Да, я уже это понял Просто в D есть такая штука, что выражения типа void туда пихать можно, в результате всё expression преобразуется в statement и получаются такие вот красивые ветвления.

Вот, для любителей выкладываю слот-сигнальную систему v 2.0 собственного приготовления. Она чуть более ООП, чуть менее суровая и чуть более настраиваемая. http://ifolder.ru/28140737 Ах да, делалась она на основе системы malandrinus, из оригинального кода взято обеспечение корректной работы очередей и каменты, так что не надо удивляться И да, спасибо ему за идею. И таки "a or return" не работает, по крайней мере codepad не понимает, потому там такие штуки везде накомментированы, тоже не надо удивляться... Добавлено через 18 мин.: Если обобщить твой вариант для произвольной функции получится: function dublicat(f, ...) return f(...) end Но это странный вариант. Он не создает новую функцию. А моя функция принимает функцию и возвращает ее копию. А уже копию я могу приписать к тому же сигналу. Хотя тут явная проблема в том, что отписать этот слот будет затруднительно - только если закэшировать...

malandrinus, Ну да, зато у меня можно создавать сколько угодно дубликатов Добавлено через 29 мин.: Кто-нибудь может подсказать, можно ли в lua выражение: if not a then f() end заменить на a or f() И соответственно: if a then f() end заменить на a and f() Чуть более сложнее, может ли там быть statement: a and c = 1 или a or return ?

malandrinus, кстати об этом, а анонимная функция пойдет для решения проблемы? навроде: slt = {fun = function() return f() end} В смысле так же можно? В общем случае сработает ли такое решение: function duplicate(f) return function(...) return f(...) end end ASSERT(f ~= duplicate(f),"?")

malandrinus, Предположим общий включается на первый выброс и после выключается, а частный должен работать всю игру. В добавок, в данном случае три строки не помогут: надо отписать общий случай но сохранить частный. То есть соблюдать вложенность. Я, может, пытаюсь придумать искусственный случай, но в самом деле, кто знает, как будут использовать возможность подписки? Я любитель общих решений И не любитель лезть руками в чужой код, неблагодарное это занятие, может там на четном количестве ошибок в знаке все держится?

malandrinus, Ситуация простая: некий мододел захотел на непися повесить поведение при неком скриптовом событии - например при выбросе. А выброс, так как наша система работает вокруг слот-сигнальной модели, генерирует сигнал. Ну что делает мододел - подписывает слот на сигнал. А теперь другой мододел расщедрился и хочет подписать всех сталкеров на это поведение но не знает что один уже подписан. Вот пожалуйста, двойное подписываени. Слот при этом бутет выглядеть как-то, например, так: slt = {signal = "blowout", self = obj, fun = obj.hit} и так для всех сталкеров. Ну и что, вот человек отлаживает эти моды вместе и видит: в цикле по всем сталкерам оказывается один уже подписан! Ну хорошо, и что ему делать-то? Искать где подписан и отписывать? Это копошение во внутренней реализации мода - не есть хорошо при любом раскладе. Код должен иметь как можно меньшую связность. А если разрешить двойное подписание, то все разруливается: второе подписывание элементарно игнорируется, вернее увеличивается счетчик подписываний до двух. А когда кто-то отписывает его, счетчик уменьшается до одного. А потом до нуля - и тут физически происходит отписывание. А сигнал, сколько бы раз на него слот не подписался, вызывает его, естественно только один раз, зачем ему больше? Хотя тут можно даже параметр сделать, это дело настраивающий: один или несколько.

Andrey07071977, Так ведь нет же, я как раз и пытаюсь протолкнуть идею, что двойные подписки - совершенно нормальное явление. Потому и отлавливать их сомнительный профит, разве только если в конкретных случаях.

malandrinus, Хранить счетчик подписываний, а не подписывать каждый раз. А пример я приводил: вот у меня класс хелпер какой-то. Мне присылают обьект и список эвентов на которые подписать. Задача - подписать на все. Ну понятно же, что не хочется каждый раз проверять - подписан ли уже, и если нет, то подписывать, хочется же сделать код прозрачней. Ну вот метод: function subscribe_all(mgr, slots) for _,v in pairs(slots) mgr:subscribe(v) end end Допустим код одной схемы вызывает: helper.subscribe_all(mgr, {s1,s2,s3}) А второй: helper.subscribe_all(mgr, {s2,s3,s4}) Вон как все красиво. Да, можно всунуть if, но как-то уже не то. Хотя вот я тут подумал - если просто в сам класс подписывателя инкапсулировать этот subscribe_all с if-ом, то будет все хорошо в плане использования. По поводу этого: Я думал обо всей системе, как о библиотеке, у которой есть интерфейс а реализация меня волновать не должна. И конечно пользователь сам может определить subscribe_silent с помощью того же if-а и снаружи библиотеки, но это потенциальное дублирование кода - каждый будет свою версию определять. И потом, тут проблема именно в том, что два разных человека подписывают один и тот же обьект на один и тот же эвент. Ну вот выпал мне этот ассерт - что мне делать? Ставить ту самую явную проверку, вариантов особо других нет. Я же не знаю, всегда ли так получается, что он уже подписан. Это же не мой код. И не ошибка в логике. Ты не пойми неправильно, я не пытаюсь учить ученого, просто мне показался странным подобный дизайн модуля, который потенциально может использоваться кучей народу в куче модификаций Во, кстати, я еще досмотрел и такой вопрос: почему сигнал встраивается в слот? Можно же было бы сделать как-то так: obj:subscribe(signal,slot), тогда один слот мог бы быть подпинан на множество сигналов в разное время разным кодом.

Andrey07071977, Не надо никаких сообщений в лог. Это сажает производительность. Просто далеко не всегда подпись на эвент дважды является ошибкой в логике программы. Особенно учитывая, что мододелов куча и один может в своем моде подписать на A,B,C, а второй на B,C,D и что теперь, совмещающему всматриваться, размышлять? К тому же раскройка модов при совмещении радикально ломает всяческую инкапсуляцию. С другой стороны получается, что теперь всегда вместо одной строки подписания придется писать три строки проверки-подписания, а всегда потому, что откуда кто знает на какие эвенты обьект уже подписан? Ну и зачем увеличивать клиентский код в три раза? Поэтому просто надо тихо return false, кому надо, тот проверит, но чаще всего это излишняя информация.

malandrinus, посмотрел твои эвенты - красота! Но только почему ASSERT, зачем такая жестокость? Обычно в такой ситуации бросают исключение, потому на мой взгляд логичнее было бы просто ничего не сделать и как-то сообщить пользователю, что он не совсем прав. А то сразу assert делать слишком сурово. В добавок мне видится ситуация, когда я хочу подписаться на эвент, если еще не подписан, и ничего не делать если подписан. Замена ассерта на более мягкую обработку ошибки позволит тут избавиться от ветвлений типа if not obj:is_already_subscribed(slot) then obj:subscribe(slot) end К тому же с ветвлением obj:is_already_subscribed вызывается дважды. Либо добавить signals_mgr:subscribe_silently()

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

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

kuzia, Да, но это надо много перелопатить. Динамические аномалии создаются скриптами, в то время как оригинальные, насколько я понимаю, были прописаны в all.spawn. Соответственно нужно прописать их заного и выключить скрипт динамических анамалий вашего мода. А это не совсем тривиально обычно, так как он довольно глубоко встроен в остальные механизмы мода.

KD87, Ну в c++ что прототипы, что имена... Вернее, прототипы восстанавливаются по именам. (за исключением возвращаемого типа). SkyLoader, да хватит уже, давай еще найдешь все функции движка с похожим на то, что тебе нужно названием и будешь спрашивать всех, а не оно ли это. В сталкере очень неплохой скриптовый API к движку, вон сколько всего на нем сделали, зачем лезть куда не надо... В конце концов, если не можешь реализовать задумку на LUA, до уж реализовать ее в движке, притом без его исходников - это ввобще нонсенс.

panzyuza, Так тебе итак в лог выводится, че ты еще хочешь? Загрузка ресурсов в движке, ничего сверх этого не получишь, как ни старайся. А вообще, ты бы поиском попользовался сдесь и по багам НС, я точно видал такого типа проблемы раз с десяток. Правда, давно это было. Этак с год назад.

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

panzyuza, Да кто его знает, может acdc кривой?

Чёрный Воин, Уже отвечали, измени гулаг так, чтобы твоя группировка могла в него входить. Добавлено через 1 мин.: panzyuza, Врятле русскими. Скорее, просто криво собралось\упаковалось\распаковалось\поставилось. Видно же, что название битое. Да и кто в своем уме будет там на русском писать?

ХЕМУЛЬ36RUS, надо изучить LUA, luabind, lua-API движка сталкера, написать схемы поведения и подключить их к игре. Подключаются они просто: modules.script, все остальное чуть сложнее и единообразному описанию или запихиванию в мануал не поддается. Попробуй скопировать и изменить руками одну из уже написанных схем. Добавлено через 2 мин.: Ulman, AI могут на это влиять. Есть схема Bak-а, насколько я помню, которая динамически меняет меткость НПС.

логично. у тебя зеро флаг был 1, выполняется cmp - становится 0.jnz не выполняется. убираешь cmp - остается 1 - jnz выполняется всегда. а тебе походу надо отключить jnz. так ты замени его на nop.

SkyLoader, Ага, нашел-то нашел, только обьяснить никому не смог

malandrinus, я примерно о том же и говорю, что понять мало что с такого кода можно. просто из приведенного кода явно видно, что вызывается метод luabind::detail::class_base::add_method(char const *,luabind::detail::overload_rep const &) с первым аргументом "motivation_action_manager" push offset amоtivation_act; "motivation_action_manager" call ds:?add_method@class_base@detail@luabind@@QAEXPBDABUoverload_rep@23@@Z; luabind::detail::class_base::add_method(char const *,luabind::detail::overload_rep const &) вот, собственно и все, что на первый взгляд видно. возникает ощущение, что в класс "motivation_action_manager" добавляется некоторый метод. Тут важно, что имеется ввиду класс LUA. То есть конечно в с++ класс что-то добавить это нонсенс. какой - а черт его знает. я даже не знаю что такое luabind::detail::overload_rep. далее, чуть выше есть код: lea edx, [esp+58h+var_38] push edx что наводит на мысль о связи var_38 и той самой добавляемой функцией типа luabind::detail::overload_rep (это вообще функция ли?), которая походу в коде представляла собой указатель, поскольку по-видимому выделена на стеке, ибо [esp+58h+var_38]. И собственно постоение которой, походу и есть в коде выше. собственно, вот и все, что можно сказать (= Ну, вернее, я больше ничего там разобрать не могу.

SkyLoader, а мне откуда знать по какому она адресу? О_о с чего, опять же ты взял, что существует некое действие "bind_object"? и в чем, по твоему оно выражается?