hal.dll

Просто в том случае при релоге аддона и взятой цели в таргет начиналась полная каша.

Еще раз повторю, что уже говорил.

(Только не сочти за резкий тон, я по-доброму )

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

Даже если я выпилю эту часть полностью из либы, тот же LibreGS при перезапуске всех аддонов может загрузиться раньше и запустить инспект цели раньше твоего аддона. Далее твой аддон запускает инспект аватара и инспект цели по очереди. Ведущая LibGS получает запрос на инспект таргета от LibreGS, запрос на инспект аватара от NewTarget3DPvP, запрос на инспект таргета от NewTarget3DPvP. 1-ый и 3-ий запросы объединяются, выполняются и результат отсылается одним сообщением LIBGS_GEARSCORE_AVAILABLE всем аддонам. Результат на 2-ой запрос (на аватара) отправляется вдогонку.

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

Я с удовольствием тебе помогу.

Вот это лишнее

if Enable and avatar.IsExist() then OnTargetChanged() end

Кому мне кажется это надо сам перезапросит в своём аддоне через GS.RequestInfo ( avatar.GetTarget() ) В моём аддоне при старте должен сначала Аватар опрашиваться. Думаю что этот код при инициализации просто лишний.

Вообще идея автоматического инспектирования была такова, что аддонам, инспектирующим текущую цель (LibreGS, TPI), вообще не надо было вызывать GS.RequestInfo. С этой точки зрения этого куска как раз не хватало, чтобы цель инспектировалась при перезагрузке аддона.

В моём аддоне при старте должен сначала Аватар опрашиваться.

Я бы не писал такой код, который требует определенной очередности.

Если я правильно понял, тебе это нужно для сравнения экипировки аватара и цели.

Чтобы не иметь жесткой привязки к очередности инспектирования, я бы сделал так:

local AvatarStats
local TargetStats

function ShowGearScore( params )
  if params.unitId == avatar.GetId() then
    AvatarStats = params
  elseif params.unitId == avatar.GetTarget() then
    TargetStats = params
  end
  if TargetStats then
    -- Show target info
  end
  if TargetStats and AvatarStats then
    -- Calculate difference
    -- Show difference coefficients
  end
end

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

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

В любом случае, добавил параметр SkipInitialTargetInspection, можешь попробовать его.

В итоге получаем Info: addon Test: 0 0 0 0 0 0

Вот это уже мой косяк.

Поправил в LibGS-2014-11-24

params.runes[DRESS_SLOT_OFFENSIVERUNE1].runeQuality

Не точную информацию дает. буду ждать ответа hal.dll

Сформулируй, пожалуйста, проблему поконкретнее

что ожидается в конкретном случае, что получаешь в аддон?

Поправил пару вещей под 6.0.

Работает только после начальной загрузки, почему-то не работает после перезагрузки аддона из меню дополнений.

Качайте: RealAgroM_r23.pak

В итоге начал переписывать аддон полностью.

Нужна актуальная информация по текущим агро-умениям всех классов. (умения, таланты, бафы, повышающие или понижающие агро).

Кто заинтересован в актуализации Агрометра, прошу принять участие

Чем больше будет заинтересованных, тем быстрее я его доделаю.

RealAgroM_r23.pak

Залил новую версию:

2014-11-21

Работает всё достаточно быстро и надежно, и на 6.0, и на 5.0.2 евро, и на 4.0.

Вроде всё протестировал, что надо было.

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

При тестировании либы на 4.0 обнаружилась неприятная фигня: очередь сообщений с приоритетом для системных аддонов.

4 аддона на инспект таргета не успевают согласоваться между собой, и каждый вызывает инспектирование по 1-му разу.

В итоге взятие в цель происходит со значительной задержкой.

Но есть и хорошие новости: сегодня буду тестировать новую систему согласования между LibGS в разных аддонах. Частично уже было протестировано, оставалось доделать пару мелочей.

Очень надеюсь, что многие проблемы после этого уйдут.

Потерпите немножко с переходом

Считать каждую единицу разницы в уровне разницей в ступень качества шмотки. Синь 65 = Зелень 66, Фиол 65 = Синь 66 и т.п.

Там нелинейная зависимость.

Посчитав ГС отдельных шмоток (по формуле 5.0) выходит, что синь/фиол лвла Х эквиваленты зелени/сини лвла Х+2.

С рыжиком же ближе к 1-к-1, но не точно (рыжик чуть хуже фиола на лвл больше).

Пока сделал коэффициент 0.5 (скорость понижения качества на 1 пункт - 2лвла).

В итоге на моём твинке 20-го лвла с зеленым шмотом 17го: ГС - белый (Goods). Тень (ги кв) не убивает.

Вроде всё достаточно адекватно теперь.

на 4.0 работает?

Должен.

обновите, пожалуйста аддон под версию 6.0, очень прошу

Аддон работает на 6.0, но есть одна загвоздка.

Разработчики АО, видимо, поддались на нытьё идиотов игроков, не способных настроить аддон под свою руку, и переделали принцип работы команды атаки пета.

В итоге теперь вместо того, чтобы переключиться на новую цель без прерывания подготовки умения (как было в 5.0), питомец продолжает атаку текущего моба и только после того, как выпустит в него заготовленное, переключается на новую цель.

В целом не вижу необходимости обновления на самом деле.

В идеале одна конечно лучше но много гемора при адаптации.

Мне, честно говоря, проще сразу сделать одну.

Всё равно прогонять её через скрипт проверки совместимости.

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

Почти.

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

Глянул на формулу в принципе норм. Может со временем чего-нибудь прикрутим к ней но пока пойдет.

Просто вместо этого:

Qs = Qs + equipmentQuality[quality.quality]

нужно сделать следующее:

Qs = Qs + equipmentQuality[quality.quality] - K*(unit.GetLevel(unitId)-info.level)

Ну или в конце сделать так:

result.gearscoreStyle = QualityStyle[ math.floor(result.gearscoreQuality - K*(unit.GetLevel(unitId)-result.gearscoreLevel) + 0.33) ]

(только надо будет проверочку индекса замутить)

Чем выше уровень персонажа по отношении к шмотке, тем сильнее будет обесцениваться её качество.

Осталось только найти корректирующий коэффициент K, посмотрев, как быстро растут статы на шмотках по мере увеличения их лвла.

Плюс была задержка на осмотр чтоб не перегружало клиент в момент взятия цели для слабых тачек.

Через Play*Effect?

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

с раскрасской гс беда

Согласен. Как-то я тоже не в курил по какому принципу происходит раскраска ГС. В этой части особо не разбирался, не до этого было.

Раскрашивает по среднему качеству шмота.

Задумывалось, что, как пример, 9 шмоток рыж + 9 шмоток синь эквивалентно по качеству фиольной экипировке.

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

Единственное - не учитывается соответствие уровню персонажа, поэтому салат 55-го на игроке 65-го отображается салатом.

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

Я свой NewTarget3DPvP_4.0 уже подготовил под адаптацию под LibGS_4.0.2

В целом я планировал одну либу под все клиенты, планировалось выгружать ненужные функции из памяти.

Или лучше сделать несколько разных версий? Или как вариант: одну - общую для всех версий, плюс отдельные под определенные клиенты.

Но в принципе и раньше NewTarget3DPvP не конфликтовал с Targeter.

Меня больше всего беспокоил вопрос конфликтов LibGS с твоим аддоном

Было ощущение, что он почему-то возобновлял инспектирование по одному ему ведомым причинам. Результат: само-открывающееся окно осмотра экипировки.

Сейчас занимаюсь адаптацией аддона под API 4.0.2 там посмотрим как будет работать.

Я в общем-то тоже адаптирую библиотеку сейчас под 4.0.2. Могу сделать промежуточный релиз, как протестирую ее работу на пиратке.

В обще идея очень хороша написать библиотечку LibGS что по сути упростит жизнь всем авторам аддонов использующих ГС и добавит стабильности в работе аддонов и их совместимость друг с другом.

Спасибо, с этой целью и создавалась

а когда простые смертные смогут проверить работу NewTarget3DPvP с данной бибилиотекой?))

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

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

Я наверно совсем слепым стал, но когда вылазило то окошко я нигде не смог найти ни "закрыть", ни "х", только "перейти к новости".

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

Что там с исходниками кстати? Автор сам доделает аддон или как?

Кстати, библиотека будет работать эффективно только когда все аддоны используют её.

Если будут аддоны, которые запускают инспект цели в дополнение к тем, что используют LibGS, то, естественно, на это будет уходить дополнительное время.

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

Удалось придумать достаточно устойчивую концепцию назначения ведущей LibGS, устойчивую в том числе к внезапной выгрузке/загрузке аддонов с интегрированной LibGS.

API меняться не будет, за исключением GS.Init: добавлю параметр, который будет передаваться в GS.EnableTargetInspection. nil - действие по умолчанию, которое и сейчас, и далее включает автоматическое инспектирование.

Впилил в таргетер, задержка получается примерно в секунду, с другими аддонами на инспект

Что-то многовато. Какие аддоны стоят?

В режиме одного аддона какая задержка?

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

Уточнение по описанию GS.Callback = ShowGearScore ставить после функции ShowGearScore, а то словил тут Attempt to read from undeclared global variable: ShowGearScore

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

Ну, тогда багом является и второй вызов OnInspectStarted

В целом, да, но это результат того, что LIBGS_GEARSCORE_AVAILABLE посылается позже вызова EndInspect.

Hal, а ты точно тестировал то, что выкладываешь?

Последнюю версию тестировал только в режиме одного аддона, увы.

А так у меня 18 тестовых аддонов с различными стратегиями.

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

пардон, пропустил

Если ты надеялся, что описание Global( "GS", {} ) сделает переменную GS единой для всех аддонов

я правда похож на такого человека?

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

ничего не напутал, так задумано.

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

Совет, как сделать так, чтобы менять поменьше - убери avatar.EndInspect() из OnInspectStarted(), вместо этого введи какое-нибудь событие INSPECT_TO_CLOSE, и в OnInspectStarted() делай userMods.SendEvent, а avatar.EndInspect() делай только в обработчике.

Потестирую, но скорей всего это приведет к тому, что будет моргать стандартным окошком инспектирования.

Но лучше всего - заставь свои библиотеки как-то договориться друг с другом

уже в планах стоит. но займусь этим уже ближе к декабрю скорей всего.

PS. Обновил либу. Просьба всем, кто использует - обновиться.

Потестил на 9 аддонах, ошибок не обнаружил.

При этом иногда ошибка возникает, а иногда нет.

Она возникает бессистемно или только на определенных виджетах?

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

Надо проверить соответствующий *.xdb на предмет наличия тега:

  <BackLayer href="TransparentLayer.(WidgetLayerSimpleTexture).xdb#xpointer(/WidgetLayerSimpleTexture)" />

Если пустой, значит надо задать его. Пример файла прозрачного слоя TransparentLayer.(WidgetLayerSimpleTexture).xdb:

<?xml version="1.0" encoding="UTF-8" ?>
<WidgetLayerSimpleTexture>
    <Color>0x00000000</Color>
    <Grayed>false</Grayed>
    <BlendEffect>BLEND_EFFECT_ALPHABLND</BlendEffect>
    <flatPlacement>false</flatPlacement>
    <lazyLoad>false</lazyLoad>
    <textureItem href="" />
    <Scaling>true</Scaling>
</WidgetLayerSimpleTexture>

SetBackgroundColor залёт его нужным цветов и он станет непрозрачным.

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

Вероятность этого крайне низка.

Например асинхронного задания цвета?!

Аналогично.

К тому же аддоны не реентерабельны, т.е. не может такого быть, чтобы две функции одного аддона выполнялись параллельно. Вытеснение (preemption) тоже отсутствует

Посему всякие блокировки, семафоры, мутексы, критические секции и прочую синхронизацию - (в данном случае) в помойку.

Быстрофикс бага с GS.Init, спасибо Slashuur за репорт.

Версия 2014-11-13 в шапке.

Заодно сделал все внутренние функции local. Теперь API либы минимален (только указанные в шапке функции).

Потестил с LibreGS, работает вроде нормально.

Text/Gold.(WidgetTextView).xdb должен содержать:

<Name>Gold</Name>

Слушай, поделись секретом, как ты названия недокументированных функций находишь? А то этой функции я в документации не нашёл (хоть и тоже потестировал уже, спасибо ramirez за калькулятор)

Никак не нахожу

Нам об этой функции сообщили сами разработчики, за что им большое спасибо.

Но доки они обновляют весьма неохотно

Посему доки не всегда соответствуют версии клиента.

Фикс вышел. Обещаю сегодня вечером обновить аддон, после работы.

Если есть желание, можешь присоединиться к проекту LibGS: https://alloder.pro/topic/1718-libgslua-biblioteka-inspektirovaniya-igrokov/

Насколько я помню, в 4.0 считалась просто сумма всех статов на всех шмотках, кроме мудрости. А на оружии, жезле и оффхэнде атакующие статы умножались на 4 (Сила, Точность, Ловкость, Разум, Интуиция, Дух и Удача).

Кривой кусочек кода, который вроде работал как надо раньше)

Спасибо за код, чуть попозже интегрирую и потестирую.

Посмотрел из любопытства. Скажу кое-что:

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

Тем не менее, скорей всего прикрою эти функции в local.

Баг с определением runeStyle

Спасибо. Добавил пропущенную циферку...

Заодно потестил работу с функцией unit.GetGearScore.

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

Увы, это вынужденная мера, иначе библиотека работала бы на полную катушку при неработающем аддоне.

Аддонам, инспектирующим цель, необходимо вызвать либо GS.Init(), либо GS.EnableTargetInspection( true ).

Вызывать надо следующим образом:

if GS.Init then GS.Init() end

Файл и информацию в шапке так же обновил.

LibGS-2014-11-11.zip