Gaikotsu

Триггеры - это когда какая нибудь пассивка или бафф/дебафф у персонажа реагируют на определенные действия и вызывают при этом дополнительный скилл. Ну вот для примера в баффе "Поэма Барабана" есть триггер, который с шансом 80% вызвает бафф "Увеличение Крит. Урона", если игрок получил урон от 300 единиц и выше. Или например в пассивке "Удар Гравитации" у артеек имеется триггер, который с шансом в 20% вызывает скилл наносящий х5 урона, когда игрок кого-то атакует. Еще как пример могу напомнить старые СА в оружии, которые накладывают например бафф на владельца или дебафф на цель если игрок кастует определенный вид скиллов- это тоже делается посредством триггеров. Так же вот скажем старые шансовые аугментации - это опять же триггеры. Или к примеру "Мираж" и его аналоги - это тоже работа триггера, который реагирует на полученный урон и вызывает на атакующего скилл отмены таргета. Вобщем если в скилле упоминается про то что они вызвают при каких-то условиях дополнительные действия - это почти 100% про триггеры в них. Ну и у большинства скиллов вызываемых триггером есть свой реюз, не позволяющий их вызвать слишком часто, так что тут никаких изменений и не будет. Речь в изменении идет вот как раз про редкие триггеры, которые вызывают скиллы не имеющие своего реюза и вызвов которых вполне мог производиться буквально нонстоп если это позволяли условия. Буквально мог быть спам в десятки вызовов за секунду если сам триггер успевал так часто срабатывать. Ну и по оффу так быть как раз и не должно - там все сработавшие триггеры отправляются в очередь на выполнение, которая обрабатывается раз в "тик" действий в сервере. Ну а "тик" этот в сервере равен 2/3 секунды или по другому 666мс. Из-за такого поведения кстати может кто играл на оффе даже замечали что бывает какой-то триггер срабатывает не сразу как произошло действие вызвавшее его, а с небольшой задержкой - это как раз из-за такой вот обработки.

То, о чем многие игроки давно уже спрашивали и чего желали, свершилось - после долгих размышлений я все же решил заняться переводом сервера на более новые хроники. Целевыми хрониками для перехода в итоге решил взять Homunculus, Chapter 2. Да, как мне, так думаю и многим игрокам более предпочтительным выбором бы был Salvation или Fafurion, как более близкий к текущим хроникам в плане количества изменений, но для перехода именно на Homunculus есть одна важная и решающая причина - у меня есть в наличии многие скрипты офф-сервера именно от этих хроник, что в итоге упрощает реализацию нового и правки старого контента. Скрипты конечно не точно от той версии что была на руоффе, но все же достаточно близкие. Сроки реализации, пока даже приблизительные, пока говорить не буду, так как работы мне предстоит просто немерено - переделок и добавлений всего и вся в сервере потребуется очень много - намного больше чем в то время когда я производил перевод сервера с хроник Ertheia на текущие. И как и раньше мне все это придется делать в одиночку... Конечно переход будет сделан сразу же как будет произведена хотя бы большая часть необходимых для игры ключевых изменений, а все остальное как и при предыдущих переходах будет доделываться уже в процессе. Но, в общем, даже по самым оптимистическим прогнозам в этом году перехода можете еще не ждать. Работа над текущей версией сервера само собой по сути замораживается. Если какие правки еще и будут, то разве что в случае выявления каких нибудь критичных ошибок/неточностей.

все, вынес элики/зелья на мп в отдельную группу реюза в бз ща данные обновлю, а на сервере применится как обычно при рестарте

увы, в один предмет можно задать только одну группу реюза больше клиент физически не воспринимает

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

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

поправил, почему-то там у меня стояло "влиять на физ. скиллы", а не "влиять на сонги/танцы". Я вроде уже не раз писал - некстом давно уже полностью управляет сам клиент, а сервер даже не знает о том что оно юзается. ну и само собой радиус действия тоже в самом клиенте заложен. где-то в дллках, вроде как в nwindow.dll

Фрея и Кельбим вобще самые простые в реализации и прохождении. С тем же квестом с Таути там вобще основательно накручено, про Кайна вобще молчу... Насчет петры так с лету не сказать - надо искать чейнджлоги или копаться в офф скриптах тех хроник что есть. Второй вариант понятное дело неточный, ибо просто покажет что вот в этих хрониках было, а в этих уже нет и это произошло где-то в промежутке между первыми и вторыми. Ну и под "петрой" ты случаем не Знак Партизан и Знак Аку требующиеся ща для входа к Таути имешь в виду? Если да, то глянул я вот сейчас в офф скрипты артеи - они еще есть в требованиях входа, а в скриптах хомункулуса - уже нет. Но вопрос когда именно убрали требование остается открытым, ибо между артеей и хомункулусом была куча других хроник, от которых офф скриптов у меня нема. Ну и маловероятно что именно в крусейде, т.к. в описаниях предметов этих как бы вобще-то пишется еще что они нужны для входа к Таути.

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

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

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

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

эм... каких именно сундуков?

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