Перейти к контенту
Азраэль

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

Рекомендуемые сообщения

Пример странного был в древнемодах. Водка и энергетик.

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

 

О, еще "телепорты"...

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

 

 

Водка и энергетик.

Это объекты с разными секциями. Собственно все :)

И все перечисленное тоже легко разносится по какому-либо признаку.

  • Согласен 1

Все, кто стоит на моем пути: идите нахрен и там погибните! ©

Ссылка на комментарий

Как я себе вижу использование этих самых ивентов:

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

 

Но, рассмотрим другую ситуацию: если я делаю проект, где количество этих самых фич конечно, то есть я знаю, что мне надо будет сделать вот это, это и ещё вот это, то мне будет куда проще сделать простое подключение через обыкновенный вызов, чем писать динамическую систему. Мой проект создается для пользователей (игроков) и собственно для игры, зачем мне делать какую-то универсальность и модульность?

 

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

Изменено пользователем Shadows
Ссылка на комментарий

, нифига. Это просто удобно. Для себя тем более, выше даже примеры приводились.

Изоляция и локализация важных мест - это круто, удобно и эффективно.

Изменено пользователем xStream
  • Согласен 1

Все, кто стоит на моем пути: идите нахрен и там погибните! ©

Ссылка на комментарий

2 Shadows, вообще-то тут меня били ногами за предложенные "промежуточные" решения. ;)

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

 

Типа, "разнести по секциям" и т.д. Да и не только меня. А также пинали кто попало кого попало и за "переусложнения". Но это так, лирика.

 

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

Вот все то же банальное for i = 1, #t do t().

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

 

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

 

 

"Правда, что ли?" - правда-правда. Ну или иначе это придется зачесть вообще как цепляние совершенно помимо предмета.

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

 

По тому как ну в общем-то очевидно, что именно это и было написано "от переборов не уйти". И так же совершенно очевидно, что отнюдь не имеется в виду набивание руками некоей таблицы t, а что-то типа t = {}; function subscribe_on_something( ptr ) table.insert( t, ptr ) end

От которого тоже ни куда не уйти - максимум - что-то добавить, ну или эквивалент на более других командах.

 

 

"мегасистем" - это любые комплекты любых оберток поверх того перебора, от которого не уйти, с любым дополнительным функционалом, общим объемом более страницы.

 

"Главный цимес, что можно это делать динамически" - О !!! Неужто договорились ?

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

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

Правда, что ли? :-) Рефакторить микросекундные вызовы? Заниматься копипастой? Нененедевидблейн

Вот все то же банальное for i = 1, #t do t().

Да тащемто нет. Подписываются только те, кому надо. И от подобных переборов ты никуда не уйдешь.

Главный цимес, что можно это делать динамически (и вот такие реальные случаи были у меня)

мегасистем

это, кстати, что такое? Изменено пользователем xStream

Все, кто стоит на моем пути: идите нахрен и там погибните! ©

Ссылка на комментарий

Надо бросать курить...

Ой, а я и не курю же.

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 5.7ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

О !!! Неужто договорились ?

Ну как бэ система ивентов подразумевает и подписку и отписку от события, кто то говорил, что она сугубо статическая? Типа запалил гдето свой номер мобильника и получаешь ежедневно СеМеСески с рекламой :) Да собстно подписка это тоже динамика.

 

У мине вопрос, об чем спор уже сейчас? Если на странице ранее еще было понимание сабжа, то сейчас не очень.

 

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

 

- Эй, вы о каких ништяках ваще?

Ништяки? Изменено пользователем Desertir

ТЧ 1.0004. SAP и Trans mod

github

Ссылка на комментарий

 

 

У мине вопрос, об чем спор уже сейчас?

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

Ссылка на комментарий

@Murarius, да не. Тут уже разговор иссяк.

Краткий пересказ:

- тут зырьте крутая штука

- ты че за ересь принес?

- нормально, не то, что раньше фуфло делали!

- эй, мне стыдно, но как умели. Но есть ништяки!

- Ну и нафига нужны эти ништяки? Мои круче.

- не, ну ты не прав, это полезняк!

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

- не, нифига! Макароны не надо, надо ништяки!

- хм... и правда, ниче так ништяки.

- не, ну смотрите, ништяки ваши легко сломать!

- ну вот вам способ залатать.

- хм, и правда. Ну ок, норм ништяки.

- Эй, вы о каких ништяках ваще?

Изменено пользователем xStream

Все, кто стоит на моем пути: идите нахрен и там погибните! ©

Ссылка на комментарий

У нас толпа модулей подписалась на то чтоб быть в курсе этого события. С какой стати, если кто-то из модулей взял и удалил сам объект, то остальным модулям нет смысла знать об этом событии?

 

Рассмотри это с другой стороны. Толпа модулей подписалась каждый на своё событие: дроп аптечки, дроп спальника, дроп артефакта и т.д. Дроп спальника (не просто дроп) - это событие, адресованное вполне конкретному обработчику. Остальным оно не интересно. Если же событие "дроп такого-то объекта" вдруг интересно не одному, а нескольким обработчикам, то у них должно быть соглашение о взаимодействии, которое включает неудаление объекта.

 

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

 

Поделюсь сразу идеей оптимизации системы событий, прямо противоречащей явному заданию очередности. Допустим, у нас есть некое событие и цепочка обработчиков. Допустим также, что какие-то из них иногда на себе завершают цепочку срабатываний. Допустим также, что это всё происходит довольно часто. Ну скажем что-то там создаётся/удаляется в инвентаре или мы нажимаем часто какие-то сочетания клавиш и т.д. Что имеем. Есть некий список обработчиков и они при вызове все срабатывают в некой очерёдности. Было бы оптимально, чтобы как можно чаще тот обработчик, что заканчивает на себе цепочку, стоял бы ближе к началу очереди (в идеале самым первым). Как это сделать? Можно было бы ввести у каждого обработчика счётчик, считать количество вызовов в случае завершения цепочки на этом обработчике. Ну и сортировать пузырьком по количеству таких прерываний, т.е. просто переставлять местами соседние, сдвигая наиболее часто прерывающий в начало очереди. Тогда можно сэкономить на времени вызова и соответствующих проверок в остальных обработчиках, тех, что стоят позже по очереди.

 

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

 

 

Попробуйте отследить, кто слушает конкретный ивент

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

 

Конечно делали также отладочную систему и для прямых вызовов. Расставляли маркеры-счётчики между такими вызовами, потом ловили момент, когда он не нулевой и по номеру определяли какой из вызовов подвис. Но с сигналами и этого не надо делать, поскольку это автоматически делается для каждого вызова.

 

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

 

 

Предмета нет - это не повод прекращать информационные действия связанные с ним.

Мне одному это утверждение представляется из области некромантии?

 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

 

 

Мне одному это утверждение представляется из области некромантии?

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

Ссылка на комментарий

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

Хорошо, что в ваших системах это так, я работаю с уже готовой, которая входит в состав достаточно большого яваскриптового фреймворка (если интересно - ExtJS), и кто там подписался на какие действия можно отследить только поиском :) Даже дебаг не спасает, а событий и слушателей там весьма не мало.

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


@xStream, я не сомневаюсь. Изменено пользователем Desertir

ТЧ 1.0004. SAP и Trans mod

github

Ссылка на комментарий

@Desertir, ExtJS - просто надстройка над jQuery, а там довольно просто это сделать. Там тот же стек. 

Все, кто стоит на моем пути: идите нахрен и там погибните! ©

Ссылка на комментарий
Тут есть весьма интересные задачи. RSA я кстати писал с год назад на байтах. В комментах есть ссылка на простые задачи. Мне особо понравились задачи из раздела Некоторые алгоритмы. Давно хотел свой компилятор написать :)

ТЧ 1.0004. SAP и Trans mod

github

Ссылка на комментарий
Толпа модулей подписалась каждый на своё событие: дроп аптечки, дроп спальника, дроп артефакта и т.д. Дроп спальника (не просто дроп) - это событие, адресованное вполне конкретному обработчику. Остальным оно не интересно.

т.е. "толпа модулей" в вашем понимании это ВОТ ЭТО?

Господи, неужели только мне кажется, что делать так в 2015 году это дичайший маразм.

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

И если отбросить всякую мишуру, то у вас получается структура типа такой:

if obj:section() == "matras" then
    ...
end
if obj:section() == "medkit" then
    ...
end
if obj:section() == "bandage" then
    ...
end

Очнитесь. Это вообще не то для чего надо применять ивенты. Я вообще все то время, пока мы тут обсуждали события и то, что надо делать с теми кто на них подписывается, как то (в реальности) совсем другие события себе представлял. Где есть смысл вешать нескольких подписчиков хотя бы.

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

 

Ну неужели так сложно сделать хотя бы так

_g.script

item_reactions = {
    matras = function(obj)
    
    end,
    medkit = function(obj)
    
    end,
    bandage = function(obj)
    
    end
    ...
}

колбек на дроп или где там у вас производят это дело ивенты

if obj and obj:section() and item_reactions[obj:section()] then
item_reactions[obj:section()](obj)
end

И все. Ну хватит уже if-then-else-маразмом заниматься в самом деле.

Изменено пользователем Zander_driver
  • Не нравится 1

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 5.7ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

@Zander_driver, ну собственно их мало кто городит. Да и опять же лично я не вижу таких страшностей в if-then...end. Ну хотя в последнее время все эти самые if-then...end упраздняю, и заменяю допустим блок строк в 15-20 на одну строку (люблю компактность). Ну и до твоего примера можно докопаться, но все же да, тут я с тобой согласен что так проще (да и лучше) делать. Но вот то что ты привел, писать в _g - кощунство по моему.

 

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

 

 

 

олбек на дроп или где там у вас производят это дело ивенты

Пффф, а не судьба сразу в коллбеке это проверить? Обязательно везде городить?

 

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

Ссылка на комментарий

@Zander_driver,

Я не вижу трагедии в том, что используется так, как используется. Даже в таком виде система ивентов приносит немалую пользу. Но раз уж ты заговорил об этом, то конечно можно и оптимизировать. Вот есть событие дропа, а мы значит хотим сделать более детальное событие "дроп предмета конкретного типа". Это несложно сделать. Когда идёт вызов события, то в качестве идентификатора события указывается строка, "on_drop" к примеру. В качестве модификации напрашивается такой подход:

 

self.am:call("on_drop_"..obj:section(), obj, sobj)

--Тогда для в модуле для подписки на событие дропа аптечки сделаем так:
function attach(sm)
    sm:subscribe({signal = "on_drop_medkit", fun = this.on_medkit_drop})
end
function on_medkit_drop(obj, sobj)
end
Аналогично в системе Анны:

 

event("actor_item_drop_"..obj:section()):trigger({what = obj})

-- в модуле
function init()
    event("actor_item_drop_medkit"):register(on_medkit_drop)
end

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

 

self.am:call("on_drop_"..obj:section(), obj, sobj) -- дроп предмета с секцией
self.am:call("on_drop_"..obj:clsid(), obj, sobj) -- дроп предмета какого-то класса
self.am:call("on_drop_"..(obj:mass() > 10 and "heavy" or "lightweight"), obj, sobj) -- дроп предмета массой больше/меньше 10-и кг
и т.д. Пока не могу сходу сформулировать точный критерий, где надо остановится, но мне видится, что где-то надо.
 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

Не понимаю... Вроде, все расписывал, примеры давал...

local t = on_drop_t[item:section()]

if t then

for i = 1, #t do t( item ) end

end

- вот и вся "черная магия". Можно вложить внуть каждого t() такое же по любому другому условию. По вкусу вместо t() - if t() ... end (да хоть бы и return).

 

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

 

Upd: Опередили...

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

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

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

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

AMK-Team.ru

×
×
  • Создать...