Перейти к содержанию

Дайджесты за январь-февраль

Обновления гайдов и аддонов

Январь Февраль

Мониторинг серверов и редактор аддонов

Представляем вам две легенды. То, о чем можно было только мечтать, стало реальностью.

Мониторинг серверов Редактор аддонов

Подсказки из игры на вашем сайте

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

Подробнее

Апдейтер аддонов

Представляем вам программу для автообновления аддонов и делимся подробностями.

Подробнее Скачать


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

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

Сейчас это выглядит так:

post-181-0-03064800-1416091914_thumb.jpg

Ссылка на комментарий
Поделиться на другие сайты

Раскрашивает по среднему качеству шмота. Задумывалось, что, как пример, 9 шмоток рыж + 9 шмоток синь эквивалентно по качеству фиольной экипировке. При данном подходе преобладающий цвет экипировки будет тянуть среднее значение на себя, но совсем плохая шмотка или очень крутая шмотка призваны ухудшать или улучшать общую картину. Единственное - не учитывается соответствие уровню персонажа, поэтому салат 55-го на игроке 65-го отображается салатом. Я очень хочу поправить это (в перспективе), выведя формулу с учетом лвла персонажа, но алгоритм пока не придумал. Готов выслушать предложения.

Глянул на формулу в принципе норм.

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

 

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

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

Можно пока как временное решение раздельные.

Но на перспективу лучше одна меньше будет путаницы.

Кому мешает лишний код пусть сам чистит Либу если  он ему мешает. :)

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

 

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

Почти.

На 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, посмотрев, как быстро растут статы на шмотках по мере увеличения их лвла.

Ссылка на комментарий
Поделиться на другие сайты

Считать каждую единицу разницы в уровне разницей в ступень качества шмотки.

 

Синь 65 = Зелень 66, Фиол 65 = Синь 66 и т.п.

 

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

Ссылка на комментарий
Поделиться на другие сайты

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

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

2014-11-21

  • Добавлен подсчет гирскора для версии клиента 4.0
  • Переделана формула раскраски гирскора (только 5.0 и 6.0): Раскраска гирскора отображает актуальность экипировки в зависимости от текущего уровня персонажа.
  • В функцию GS.Init добавлен параметр Enable, аналогичный параметру функции GS.EnableTargetInspection.
  • Добавлены поля equipmentLevel, equipmentQuality, equipmentStyle - содержат значения по старой формуле (средний цвет экипировки)
  • Теперь инспектированием занимается только одна библиотека из всех присутствующих и загруженных
  • Исправлены многочисленные сообщения LIBGS_GEARSCORE_AVAILABLE при инспектировании собственного аватара
  • Убраны лишние циклы инспектирования одного и того же персонажа
  • Меньше фризов при большой нагрузке (4 и более аддона на инспект цели)

 

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

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

 

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

Ссылка на комментарий
Поделиться на другие сайты

Объясните пожалуйста как из библиотеки получить цифровое значение рун?

 

Все перепробывал но числа самой руны не дает. Или так и задуманно?

Изменено пользователем HugoOlivera
Ссылка на комментарий
Поделиться на другие сайты

Объясните пожалуйста как из библиотеки получить цифровое значение рун?

 

Все перепробывал но числа самой руны не дает. Или так и задуманно?

		for v, t in pairs( p.runes ) do
			if 1-DRESS_SLOT_OFFENSIVERUNE1+v then
				run[1-DRESS_SLOT_OFFENSIVERUNE1+v] = t.runeQuality
			end
		end
Ссылка на комментарий
Поделиться на другие сайты

я так понял runes[DRESS_SLOT_OFFENSIVERUNE1].runeQuality на примере первой руны

params.runes[DRESS_SLOT_OFFENSIVERUNE1].runeQuality

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

 

 

		for v, t in pairs( p.runes ) do
			if 1-DRESS_SLOT_OFFENSIVERUNE1+v then
				run[1-DRESS_SLOT_OFFENSIVERUNE1+v] = t.runeQuality
			end
		end

 

Меня интересовало можно ли библиотекой получить данные.

Ссылка на комментарий
Поделиться на другие сайты

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

 

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

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

Кому мне кажется это надо сам перезапросит  в своём аддоне через GS.RequestInfo ( avatar.GetTarget() )

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

Думаю что этот код при инициализации просто лишний.

 

Ну или так

function GS.EnableTargetInspection( Enable, unitId )
	if GS.Init then GS.Init() end
	Enable = Enable ~= false
	if GS_TIEnabled ~= Enable then
		local func = Enable and common.RegisterEventHandler or common.UnRegisterEventHandler
		func( OnTargetChanged, "EVENT_AVATAR_TARGET_CHANGED" )
		func( OnTargetChanged, "EVENT_AVATAR_SECONDARY_TARGET_CHANGED" )
		GS_TIEnabled = Enable
		if Enable and avatar.IsExist() then
			if unitId then
				RequestInfo( unitId )
			else
				OnTargetChanged()
			end
		end
	end
end
Ссылка на комментарий
Поделиться на другие сайты

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

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

 

У юнита есть руны к примеру 999 999 каким образом вывести можно при помощи библиотеки сами цифровые значения рун.

Ссылка на комментарий
Поделиться на другие сайты

Цифровые значения рун возвращаются в полях

runes                   - таблица, индексированная по [DRESS_SLOT_*RUNE*]
    runeQuality         - number - ступень руны (0..13)

Ссылка на комментарий
Поделиться на другие сайты

Цифровые значения рун возвращаются в полях

runes                   - таблица, индексированная по [DRESS_SLOT_*RUNE*]

    runeQuality         - number - ступень руны (0..13)


function ShowGearScore(params)
    if params.unitId == avatar.GetTarget() then
        runes = params.runeQuality
        LogInfo(runes)
    end
end
...
common.RegisterEventHandler( ShowGearScore, "LIBGS_GEARSCORE_AVAILABLE" )
...

На выходе получаем в логах

Info: addon Test: nil

Подскажите где, что не так пишу?

Ссылка на комментарий
Поделиться на другие сайты

params.runes[DRESS_SLOT_OFFENSIVERUNE1].runeQuality

function ShowGearScore(params)
    if params.unitId == avatar.GetTarget() then
        runes0 = params.runes[DRESS_SLOT_OFFENSIVERUNE1].runeQuality
        runes1 = params.runes[DRESS_SLOT_OFFENSIVERUNE2].runeQuality
        runes2 = params.runes[DRESS_SLOT_OFFENSIVERUNE3].runeQuality
        runes3 = params.runes[DRESS_SLOT_DEFENSIVERUNE1].runeQuality
        runes4 = params.runes[DRESS_SLOT_DEFENSIVERUNE2].runeQuality
        runes5 = params.runes[DRESS_SLOT_DEFENSIVERUNE3].runeQuality
        LogInfo(runes0," ",runes1," ",runes2," ",runes3," ",runes4," ",runes5)
    end
end

В итоге получаем

Info: addon Test: 0 0 0 0 0 0

Все бы хорошо но post-14605-0-68014300-1416770687_thumb.j

Ссылка на комментарий
Поделиться на другие сайты

Я на всякий случай уточню, что HugoOlivera речь ведет за клиент версии 4.0.02

Ссылка на комментарий
Поделиться на другие сайты

Я на всякий случай уточню, что HugoOlivera речь ведет за клиент версии 4.0.02

 

Да, спасибо за уточнение, ибо совсем заработался и забыл про версию.

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

Что нового в этой версии 2014-11-24
  • Исправлено получение ступеней рун на клиенте 4.0
  • Исправлены ошибки, возникающие при отсутствии экипировки у инспектируемого игрока
  • Поля fairyScoreDamage и fairyScoreHeal приведены в соответствие описанию (показывают процент, на который увеличивается урон/лечение)
  • В таблицу результата добавлено поле inspected, показывающее, есть ли у аватара необходимое умение для инспектирования цели, и присутствуют ли поля gearscore* и equipment* в таблице.
  • В функцию GS.EnableTargetInspection добавлен параметр SkipInitial. Подробности в описании.
  • В функцию GS.Init добавлен параметр SkipInitialTargetInspection, аналогичный параметру SkipInitial функции GS.EnableTargetInspection.
Ссылка на комментарий
Поделиться на другие сайты

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

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 может приходить в твой аддон даже если ты не запрашивал инспектирование (сообщения нынче глобальные), поэтому всегда есть шанс конкуренции с другими аддонами при жесткой привязке к очередности. Поэтому жесткую привязку - в топку :) (не, ну правда, нехорошо так делать :very_happy: ).

 

 

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

 

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

Ссылка на комментарий
Поделиться на другие сайты

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

За эту доработку спс

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

Мне просто при старте инициализации нужно первым проинспектировать аватара.

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

А в твоём 1 варианте он тупо инспектировал Цель.

Из за этого приходилось запускать - перезапускать инспекцию Аватара а потом опять цели Аватара

Ссылка на комментарий
Поделиться на другие сайты

 

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

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

Что нового в этой версии 2014-11-24
  • Исправлено получение ступеней рун на клиенте 4.0
  • Исправлены ошибки, возникающие при отсутствии экипировки у инспектируемого игрока
  • Поля fairyScoreDamage и fairyScoreHeal приведены в соответствие описанию (показывают процент, на который увеличивается урон/лечение)
  • В таблицу результата добавлено поле inspected, показывающее, есть ли у аватара необходимое умение для инспектирования цели, и присутствуют ли поля gearscore* и equipment* в таблице.
  • В функцию GS.EnableTargetInspection добавлен параметр SkipInitial. Подробности в описании.
  • В функцию GS.Init добавлен параметр SkipInitialTargetInspection, аналогичный параметру SkipInitial функции GS.EnableTargetInspection.

 

 

Благодарю и это скорее не косяк, а просто всего не проверишь и не уследишь ведь. Еще раз спасибо.

Изменено пользователем HugoOlivera
Ссылка на комментарий
Поделиться на другие сайты

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

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

Важная информация

Пользуясь сайтом, вы принимаете Условия использования