Gaikotsu
-
Постов
3 038 -
Зарегистрирован
-
Посещение
-
Победитель дней
142
Сообщения, опубликованные Gaikotsu
-
-
1 час назад, aerton сказал:
Я уже писал ему об этом, говорит так и должно быть. Есть чем пруфануть?
И я уже объяснял что в офф скриптах вобще никаких признаков общего реюза у них не наблюдается.
Притом этого даже у старых лс нет, но там если все равно и показывает в клиенте общий у некоторых, то это уже сам клиент делает, без вмешательства сервера - хз чем вобще руководствуясь, т.к. и в клиентских датниках нет ничего что указывало бы на общий реюз всех уровней этих скиллов.
Единственное что приходит на ум - это то что там где-то глубоко в клиенте тупо захардкодены условия вида "если это скиллы из таких-то диапазонов ид и один уровень такого скилла в реюзе, то для всех остальных уровней тоже показываем что они в реюзе".
И то что для диапазонов ид скиллов в новых лс этого не делается это или так и задумано корейцами или же это их косяк. И какой все же из этих вариантов правилен - неведомо.
Ну и вобще проблема честно говоря достаточно надуманная - ведь каков вобще шанс что у одного и того же игрока будет несколько предметов с аугами, имеющими один и тот же скилл разных уровней, чтобы была возможность использовать подряд без реюза эти самые скиллы?
---
Вобще, я и со стороны сервера могу отправлять все уровни одного скилла, используемых в аугах, в одновременный реюз, если хотя бы один уровень был заюзан - благо функционал и настройку включающую такое поведение я написал уже давно на всякий случай, но мне бы не хотелось ее активировать без реально весомой необходимости. Ибо это сильно увеличивает количество действий при отправке скиллов в реюзы - ведь надо каждый раз раздельно это все это делать для всех уровней таких скиллов, а не только для одного уровня.
Сейчас вот так выставлен параметр:
Спойлер# Выставлять или нет общий реюз всем уровням умений в умениях аугментаций/опций заточки
# По сути сам клиент для таких умений визуально отображает все уровни в реюзе, если ему от сервера пришла информация о том,
# что хотя бы один из уровней умения в данный момент находится в реюзе
# При включении настройки, при каждом выставлении реюза таких многоуровневых умений, будет производится значительно больше# действий, так что не стоит включать без реальной необходимости
CommonReuseForAllSkillLevelsInOptions = falseИ для понимающих, в чем разница и почему при включении это более ресурсоемко (при включенном параметре выполняется так же и код после комментария)
Спойлер
-
а что по ним должно заваляться?
если есть какие мелки расхождения в чем, в скиллах там и т.д. то пока на глаза не попадались - если что и вылезет, то будет поправлено по обнаружении.
со скиллами то проще - обычно той информации что есть в клиенте вполне достаточно для реализации их нормальной работы. если только корейцы не впихали в них каких нибудь"скрытых бонусов", о которых не захотели упоминать в описаниях скиллов и о которых можно узнать лишь косвенно, ну или наткнуться в офф скриптах, если они есть.
-
Когда появились актуальные данные по всему этому - тогда и поправил.
Просто это все можно узнать только из офф скриптов, т.к. в клиентских данных подобной информации нет, а до недавнего времени у меня были только скрипты глори в наличии, что позволяло только у части предметов это все правильно выставить, что кстати и было давно уже сделано.
Теперь же у меня под рукой еще есть офф скрипты от артеи + частично от хомункулуса, что позволяет проверять и поправлять разные данные при помощи более полных и актуальных источников.
Так что правки правильные и именно так вместе это все и должно реюзаться по офф данным.
Вобще, то одни возмущаются и требуют что-то сделать по оффу, то наоборот другие начинают "нам не нравится что по оффу - верните как было"...
-
ну сейчас по идее должно быть нормально на любых боссах - я вчера массово для всех боссов правки сделал учитывающие подобные ситуации.
-
Ну вроде бы поправил - по крайней мере тестовая пробежка по инстансу октависа глюков с неснятой с босса неуязвимостью не выявила.
Исправления применятся при следующем рестарте, а пока советую всем воздержаться от заходов к октавису, а то можете тоже на этот глюк нарваться.
---
Причина вылезшего косяка в том что я на днях исправлял работу с состоянием неуязвимости для того чтобы правильно учитывалась неуязвимость в ситуациях когда она действует в одно и то же время из нескольких источников. Раньше просто статус снимался сразу же как только заканчивалась неуязвимость из одного источника, т.е. мог возникнуть косяк в виде - вроде и есть неуязвимость, но при этом она не работает. Теперь же статус неуязвимости хранится в виде счетчика, и каждый источник неуязвимости делает +1 к этому счетчику, ну и соответственно -1, когда завершается. Таким образом неуязвимость закончится только тогда, когда счетчик дойдет до 0, т.е. все источники что сделали +1 к нему, так же сделают -1.
Ну а с октависом получалась в некоторых условиях ситуация, когда этих самых +1 было больше чем -1, что и привело к глюку.
-
Хм... походу первый скажм так косяк из-за недавних правок по работе с неуязвимостью. Буду разбираться...
-
Без баффа "мелодия защиты" исы и с ним.
что не так?
-
1 минуту назад, Junior сказал:
Кароче ничего не понятно, и где куда это все суммируется но баф исы, лсв диадему и баф свитком ни разу нигде ничего не прибавили в защите.
Также не совсем понимаю при чем здесь Атака если речь про защиту..
"Атака / защита при PvP"
-
смотри там в разделе "Атака / защита при PvP" варианты "Обычная физ. атака", "Атака физ. умением", "Атака маг. умением" второе значение
и если что значения статы защиты/атаки там не суммируются, а перемножаются между собой.
суммируется только именно что срез урона, т.е. то что в "Снижение получаемого урона"
Ну и я очень надеюсь что ты хоть там кнопку обновления в окне со статами от .whoami жмешь после того как одеваешь/снимаешь что-то что дает бонусы, чтобы увидеть изменения, а не ждешь что там магическим образом все само сразу обновится в этом окне?
-
я ж там ясно написал что если нет в приведенном списке, то значит это не в срез урона идет а в обычную пвп защиту. так что ты в .whoami просто походу не туда смотришь.
а по диадеме - может потому что есть два варианта бонусов по уменьшению урона в пвп от лс для диадемы?
и один идет именно как срез урона при обездвиженном состоянии, а другой - это обычная защита в пвп. и у тебя видимо как раз второй вариант.
-
Может потому-что щиты дают отдельную защиту, которая задействуется только при его срабатывании.
И само собой в общей защите, в окне стат, она не отображается, добавлясь к ней только в момент расчета урона в случае когда сработал блок щитом.
Какую защиту дает щит с текущими бонусами от скиллов для него можно посмотреть в .whoami, а на первой же странице.
Ну а ИНТ в пассивке на сигилы дается всегда - там нет зависимости для этого бонуса от того одет или снят сигил. потому и не меняется ИНТ в статах при одевании/снятии сигила.
-
Советую внимательно почитать вот это чтобы понимать в чем разница между разными видами пвп защиты и что именно дают разные скиллы и т.д.
-
ну судя по тому как этот обмен в офф скриптах описан был - заточка при обмене не сохраняется.
я в итоге так же и сделал.
невозможность обменять заточенный убор поправил - изменение подействует после следующего рестарта.
-
Купить за бонусные монеты (монеты за голосование)
Ну а на оффе фиг знает где добывалась - этот обмен по сути уже устаревший, еще времен первых частей ГоДа вроде, до Линдвиора и т.д.
-
В 04.02.2023 в 17:27, Yogik сказал:
Китайское перо попалось
скорее всего по какой-то причине в клиенте таймер это считающий переклинило и он не остановился на 0, разлочив кнопку, а просто попер дальше в минус считать. Причин может быть много для этого - например невовремя время на компе скорректировалось, в итоге 0 просто перепрыгнуло (а там может как раз проверка на "равно 0" для окончания стоит), клиент был в фоне и опять же вовремя не отреагировало на нужное значние таймера (в фоновом процессе многие таймеры, и не только, в клиенте вобще могут фризиться или результат их работы игнорироваться). ну и может еще какая причина.
хотел сделать принудительную отправку пакета со списком вариантов в момент завершения эффекта блока, чтобы гарантировано разлочить кнопку реса на месте, но...
в целом да это работать будет, но фигня в том что при этом пакет еще и воспроизводит снова анимацию смерти, что будет выглядеть сильно странно...
хотя... есть пара идей...
-
Вроде как поправил - применится при рестарте следующем.
Надеюсь никаких побочных косяков не вылезет - вроде все возможные комбинации отправки/получения/отмены я проверил и проблем не вылезло никаких.
З.Ы. выходить получателю для воспроизведения проблемы необязательно - просто достаточно открыть письмо и все. пакостник видимо выходил просто чтоб не получать потом в пм "ласковых" слов.
-
1. дополнил список мобов с которых падают итемы
2. квест дополнил в плане продолжения набора итемов на втором этапе + добавил пропущенных мобов
3. диалоги поправил - забыл видимо когда-то исправить текст, после того как хтмлки копипастнул с аналогичного квеста про лагерь варка, который реализовывал до этого.
4. исправил - теперь реакции на попытку призвать через диалог еще мобов не будет если кокон уже уничтожен обычными атаками.
по п.1 и п.2 - возможно еще где в каких квестах мобы пропущены, т.к. во многих квестах времен артеи (и ранее) я поправлял только сразу бросающиеся в глаза расхождения по сравнению с их описаниями в крусейде, надеясь что если что игроки будут отписываться о том что что-то где-то в квестах еще не так как надо. но просто походу мало кто вобще в квесты вчитывается и не обращает внимания на возможные несоответствия...
--
исправления применятся после следующего рестарта.
-
1
-
-
ну вот я в офф скриптах от артеи и хроник повыше позырил и чет в упор не наблюдаю никаких особенностей у дота в этом скилле по сравнению с другими дотами.
т.е. ничего не указывает на то чтобы именно только на этот дот должны реагировать триггеры на полученный урон.
так что...
-
Ну так я и не собираюсь по "видосикам", по которым нихрена не понятно что и как, править - вот если именно с оффа будут 100% доказательства то тогда еще может быть.
Но вроде именно что 100% ДоТы не вызывают срабатывание триггеров на полученный урон - иначе бы уж я думаю давно на это несоответствие у нас многие бы обратили внимание и давно бы уже вопили на тему "сделайте чтобы на ДоТы реагировало".
-
Какая нафиг "горелка"? У вас пальцы отвалятся писать нормальные имена скиллов и т.п.? Когда уже вы поймете что я могу быть совершенно не в курсе ваших жаргонных именований чего либо в игре. А гадать постоянно что вы подразумеваете...
Если "горелка" это "Замораживающее Пламя", то оно вобще-то чистый ДоТ и обычного, прямого урона в этом скилле нет. Ну а на урон с дотов триггеры реагирующие на полученный урон не срабатывают.
Если же считать что должны срабатывать - нужны более вменяемые доказательства, ведь правка повлияет вобще на любые ДоТы, а не только на "Замораживающее Пламя" - ведь в его описании нет никаких особенностей делающих его исключением из правил (я про описание из офф скриптов).
Вобще советую ознакомится с темой про все виды урона в игре.
-
Предложения прочел, принял во внимание - в ассортименте правки будут.
Но особо все же губу не раскатывайте на то что много халявы будет
19 часов назад, Yogik сказал:Можно добавить итем на смену основного класса в любой другой
такого предмета не существует. и даже если добавлять, то еще и функционал для него писать потребуется по быстрому, а это не то же самое что функционал смены класса на дуале/сабе - ньюансов своих при смене профы основы дофига и больше.
Да и востребованность этого не сильно большая - если прям кому приспичило, то всегда могут обратиться к Джустине за этой услугой. Само собой не бесплатной.
-
поправил (и плащ света и тьмы), как обычно применится после следующего рестарта
а да, еще в плаще невита тоже должно было быть +10 к атрибутам - тоже добавил
-
1
-
-
Вобще непонятно что такое у тебя произошло...
В логах никаких ошибок и т.д. нет на тему тебя или выдачи/невыдачи награды.
вобщем непонятно где и и что вобще искать...
Какой-то походу единичный случай по неизвестной причине - т.к. в лгах есть отметки выдачи наград игрокам, т.е. все работает как бы. Да и чего ему не работать то - в этом эвенте, в его коде, с прошлого года никаких изменений не делалось.
-
исправлено
применится после рестарта
банки хп и мп
в Баги и глюки
Опубликовано
были бы у меня 5 лет назад более актуальные данные - тогда бы и сделал
или по твоей логике, если обнаруживаются по прошествии времени некоректная работа чего либо, то это не надо исправлять ибо "надо было делать сразу же, а не сейчас"?