Реклама
  • Объявления

    • Fye D. Flowright

      Проблема с отображением баффов, хп, маны и урона в аддонах   20.04.2017

      После хотфикса 8.0.1.21 от 19 апреля в аддонах перестала отображаться информация о баффах, дебаффах, уроне, здоровье, входящем отхиле и изменении маны. Связано это с изменениями, внесенными разработчиками в API аддонов в данном хотфиксе. Восстановление работоспособности тех аддонов, которых затронуло это изменение, требует некоторого времени, поскольку не является легко поправимым. Авторам платных аддонов необходимо как можно быстрее, в срок до конца апреля, исправить проблемы. В случае невозможности исправить проблему и фактической бесполезности и неработоспособности аддона в отсутствие этих исправлений такой аддон будет снят с продажи. В случае снятия аддона с продажи покупателям будут проведены возвраты. По аддонам, работоспособность которых будет возобновлена, будут продлены сроки подписки. В случае, если окажется, что ситуация сложнее, чем представляется, в приведенные выше условия могут быть внесены изменения, о чем я обязательно сообщу. Подробности об изменении авторам аддонов: common.RegisterEventHandler(eventFunction, sysEventName, params) Для следующих событий params является обязательным параметром, в котором должен быть указан идентификатор интересующего объекта ObjectId: EVENT_HEALING_RECEIVED EVENT_UNIT_HEALTH_CHANGED EVENT_UNIT_MANA_PERCENTAGE_CHANGED EVENT_UNIT_DAMAGE_RECEIVED EVENT_DEVICE_DAMAGE_RECEIVED EVENT_OBJECT_BUFFS_CHANGED EVENT_OBJECT_BUFF_ADDED EVENT_OBJECT_BUFF_REMOVED Пример: local onEventObjectBuffsChanged = function(p)     -- событие придет для аватара end local params = {objectId = avatar.GetId()} -- Подписываем обработчик: common.RegisterEventHandler(onEventObjectBuffsChanged, 'EVENT_OBJECT_BUFFS_CHANGED', params) -- Отписываем обработчик: common.UnRegisterEventHandler(onEventObjectBuffsChanged, 'EVENT_OBJECT_BUFFS_CHANGED', params) Обращаем внимание на одну маленькую деталь в этом примере: -- Подписываем обработчик: common.RegisterEventHandler(onEventObjectBuffsChanged, 'EVENT_OBJECT_BUFFS_CHANGED', {objectId = avatar.GetId()}) -- Отписываем обработчик: common.UnRegisterEventHandler(onEventObjectBuffsChanged, 'EVENT_OBJECT_BUFFS_CHANGED', {objectId = avatar.GetId()}) -- здесь будет ошибка, поскольку params не равен тому, который использовали при регистрации. Оставить комментарий

Dim

Разработчик аддонов
  • Публикации

    39
  • Зарегистрирован

  • Посещение

О Dim

  • День рождения

Профиль

  • Пол
    Неизвестен

Посетители профиля

1 658 просмотров профиля
  1. Закончена работа над реализацией аналога компонента MSFLXGRD.OCX. Объем большой, изменения коснулись примерно 40% кода калькулятора. Ускорилась работа модуля расчета стратегии. Исправлена ошибка при подсчете стоимости в рецепте (писали выше). Исправлены найденные мелкие недочеты. Процесс тестирования завершен, но что-то я мог пропустить - смело пишите сюда об ошибках! Надеюсь этот инструмент полезен вам, вносить предложения или просто хвалить можно в этой теме.
  2. Доработал страницу "Приход-Расход", можно подвести баланс средств вложенных в лабиринт.
  3. Обновил файл, пул выставил 60%. Начал дорабатывать страничку расходов на лабиринт.
  4. Только попытка ограбления моего лабиринта, мне сказали сумму и я опять же получил 60%.
  5. Связался с предоставившим информацию, действительно пример "не чистый", там присутствовал сдвиг запуска и даже запуск на другой сложности. Хорошо что разобрались, иначе бы вся картина кривилась. Пересмотрел примеры, все подтверждённые дают 60%, спасибо вам за них. Получается я зря накручивал логику, все проще.
  6. Возьму паузу на посчитать ещё раз, спасибо за примеры. По поводу прерыва производства я вашу мысль понял, учту в расчёте примеров, спасибо.
  7. У меня прерывает производство на три дня, никогда не сталкивался с меньшим количеством перерыва. Вы уверены про два дня? Чтоб сомнения убрать скажите сколько на роге производства сейчас?
  8. Ваш пример как раз и пересчитывал, он и укладывается и в 70%. Наверное выложу обновлённый файл для наглядности расчётов позже. Ускорение должно быть равнозначно увеличению выработки на день, это было бы логично (пока опровержений такому не получим). Полученные примеры были "чистыми", не повторными. Повторных примеров пока не получал. При подсчёте учитываю только на золото рога, конечно. Не все так просто, не забывайте, что по расчётам, если учитывать непрерывную выработку в течении дня, мы имеем диапазон. Этот диапазон стартует от максимального количества золота на вчерашний день и заканчивается максимальным количеством на текущий. В моем файле показано окончание диапазона на каждый день, т.е. максимум (доработаю и покажу "от" и "до" на каждый день). Так же надо учитывать, что рог в первый день выработки имеет сразу пул за весь день. По вашему примеру ограбили на 10 день (в этот день производство "зависло"), об этом говорит показанный день на роге (я правильно понял, это 6?). После продолжения производства станет 5 день и так далее. По расчёту на 6 день производства пул накопил 41357.33, из которого при 70% получается диапазон от 26055.12 до 28950.13 Ваше ограбление в этот диапазон попало.
  9. Это предположение. Поднимаю старые примеры, пересчитываю новые. Пока получаю следующее, что позволяет уложиться в диапазон: 70%, хх%, yy%, 60%, 50%. К сожалению примеров мало, по три на каждую сложность бы... *добавлено* Если принять за точку отсчёта 70% и каждые 10% увеличения производства лабиринта принимать равным 2% снижения пула, то получим последовательность, которая вписывается в примеры: 70%, 68%, 64%, 58%, 50%. Хотелось бы верить что это ответ, пример красивый.
  10. Получил ещё один пример: "9 рогов на 200%. Письму ещё 25дней жить. Рогам работать ещё 2 дня. Унесли 104223." При пересчете выхожу на 50% пула (или даже 45%), что навевает мысль о 10% шаге за каждую сложность: 90, 80, 70, 60, 50. Очень жду очередных примеров, изменений в файл пока не вношу.
  11. Время запуска в первый день вероятно не учитывается, т.к. ранее читал на форуме, что пул ограбления рога в первый день имеет не менее суммы одного дня производства. Следовательно все рога стартуют и останавливаются одинаково, Запуск автоматически означает пул на один день набранным. Это, кстати, тоже надо будет учесть... Возможно что тут есть ещё один неучтённый фактор, а именно то, что процент пула ограбления может зависит от сложности производства. Судя по примеру на форуме АО так оно и есть, примерные значения: 75, 70, 65, 60, 55. Продолжаю исследования, жду новых примеров.
  12. Добавил в расчёт минуты. Оказалось, что при 10 часах 39 минутах расчетное значение для ограбления равно 68856, 08 при значении пула 60%. Считаем ответ найденным?
  13. *Исправлены расчеты* Пересчитал ещё раз по вашим данным. 1) Получается ограбление было в день, когда на рогах оставалось 1-9 дней производства (пул 110 630,87). 2) Расчёт на 70% даёт результат 77 441,609, на 62,24% - 68 856,65 3) Исходя из расчёта на 60% и суммы ограбления в 68 857 золотых, а так же поделив сумму накопления рогов в день на 24 (сумма для 9 ваших равна 387,725) получаем, что на одиннадцатом часу производства накапливается похожая сумма в 68 937,5. 4) Подбирая точный процент получим 59,93% Учитывая, что могут быть неизвестные нам округления в расчётах в самой игре, можно предположить верным, что при почасовом накоплении рога для ограбления пул для ограбления может составлять 60%.
  14. Похоже что предположение верное и идёт разбивка по часам. Вы не могли бы выложить цифру пула по моему файлу на тот день, в который вас ограбили? Я бы рассчитал в какой час это произошло.
  15. Новый посчитанный пример дал цифру в 56,2852%. Так же близко, но так же дробно. Сегодня проверю идею о почасовом начислении пула, позже поделюсь результатом.