DarkDPSMeter

[SLA]

Ramirez, респект! Библиотека оптимизирована славно, нужно теперь проверить, насколько это ускорит DarkDPSMeter.

Только, имхо, основные тормоза, всё же, в самом подсчёте статистики. Вернее в том, наверное, что там выполняется слишком много операций со строками... Надо бы посмотреть, везде ли оправдано использование строк, может, можно заменить где-то строки на числа... А ещё, можно здорово упростить рассчёты при скрытом окне, ведь многое можно не считать и не обновлять...

Кстати, заканчиваю изучать твои оптимизации, и наткнулся на использование функции table.getn() вместо GetTableSize(). Здесь нужно разобраться, можно ли её использовать. Как известно, в АО используется движок LUA 5.0.3. Так вот, Google сразу выдал такую ссылку про эту функцию: table.getn in Lua 5.0.2/3. Это всё в продолжение темы о багах LUA 5.0 в работе с таблицами, начатой здесь. Так что, сначала проводим тест. Если НЕ работает, то возвращаемся к GetTableSize(). Если работает, то ДОБАВЛЯЕМ в аддон новую функцию GetTableSize(), вычисляющую всё через table.getn(). Потому, что этот GetTableSize() в аддоне используется повсеместно.

[ramirez]

Quote:

Только, имхо, основные тормоза, всё же, в самом подсчёте статистики.

Сначала надо попробовать. У меня, например, есть мнение, что тормоза там от беспощадной работы с виджетами. Lua специально оптимизирована для работы со строками, так что, если там не фигурирует массированная конкатенация, то конкретно за строки, в общем, можно не беспокоится. Ну и не считать и не обновлять три тыщи раз одно и то же тоже конечно надо. =)

Quote:

...наткнулся на использование функции table.getn() вместо GetTableSize().

Про GetTableSize(). Призываю всех перестать использовать эту функцию вообще, удалить отовсюду ее вызовы, а ее саму стереть к чертям. Это очень, очень плохая функция.
Про table надо понимать три простые вещи:

• Функции библиотеки table существуют для работы с массивами .
• Массив есть таблица с элементами, индексированными uint'ами, идущими подряд без пропусков, начиная с 1.
• В Lua первым элементом массива считается элемент с индексом[1] , а не [0] , как считают в Нивале.

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

Лист, начинающийся с [0] превращается в лист, начинающийся с [1] так:

Code:

table.insert( list, 0, nil )

После этого table.getn() выдает коррекный размер, и с листом можно полноценно работать (и сортировать QuickSort'ом, а не руками), но надо помнить, что теперь индексы смещены, и отдавать их в таком виде обратно в AO LuaAPI нельзя...

[SLA]

Quote:

, а не [0] , как считают в Нивале.

=))))))))))))))))) Я плакал... Так вот, оказывается, у кого руки не из того места растут. А я и думаю, почему не получается обойтись без такой уродской функции как GetTableSize()...

Значит, получается, для спасения DarkDPSMeter, надо добавить в библиотеку что-то типа этого?

Code:

function GetTableSize( t )
if not t then return 0 end
if t [0]  then return table.getn(t)+1 end
return table.getn(t)
end

Я только протестирую всё это, сначала. Если такой фикс будет работать, то это значительно ускорит весь DarkDPSMeter.

P.S. А в LUA можнл ли вместо
local wtChildren = self.Widget:GetNamedChildren()
local wtChild = wtChildren [ index ]
сделать так?
local wtChild = self.Widget:GetNamedChildren() [ index ]

P.S.2. Кстати, аналогичный стиль программирования и в файле DarkDPSMeterData.lua, так что его тоже можно аналогичным образом оптимизировать. Там даже есть любопытная СОРТИРОВКА массива в трёх функциях:

TSpellDamageData:SortSpellDetailsByCount()
TCombatant:SortSpellByDamageAmount()
TFight:SortCombatantsByDamageAmount()

Функции эти вызываются при каждом ударе, как я понял. Так что, возможно, это именно они хавают все ресурсы ЦПУ?
Ramirez, можешь, как специалист по LUA, посмотреть, что можно с ними сделать?

[Nikon]

В Нивале хз че и кто считает

Ихняя функция белибердень выдает, если в массиве есть значения типа nil

Ну, на самом деле, не белибердень, но не то что (по мнению написавшего) должна выдавать

Она выдает количество не nil-элементов в массиве

[SLA]

Quote:

Она выдает количество не nil-элементов в массиве

Дык ведь Дарк удаляет элементы массива именно так: массив [элемент] = nil
Но тут очень запутанная история, почитай этот холивар о работе массивов в луа. Там наши даже выложили примеры кода, воспроизводящие баг.

[Nikon]

Сори, ошибся... Не то написал

Лучше сотру это нубство

Но, то что он стирает методом nil не означет, что у него элементов в массиве станет меньше

..Читал я ту тему.. даже отписывался..

Кстати, она меня сподвигла на написание ДПСметра(попроще, чем этот)....

Попробую доделать завтра-послезавтра. Вдруг чего и получится

[ramirez]

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

File: Scripts.zip

[ramirez]

Лучше так:

Code:

function GetTableSize( t )

  assert( type(t) == "table", "invalid argument passed." )

  local n = table.getn( t )

  return t [0]  and (n + 1) or n

end

Замалчивать ошибки в скрипте нехорошо, нечего спрашивать размер у всякого мусора. Я не знаю, насколько быстр Lua'шный ассерт (вроде достаточно), но мне краткость нравится. =)

Code:

local wtChild = self.Widget:GetNamedChildren()  [ index ]

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

Quote:

Ramirez, можешь, как специалист по LUA, посмотреть, что можно с ними сделать?

Посмотрел, переделал. Думаю, этого недостаточно. Там очень много задействовано всяких поисков перебором, которые не трогал, но которые по-хорошему стоит заменить хэш-таблицами. Часть функций почему-то не используется. Сама структура аддона диктует многократные перевызовы одних и тех же функций, но тут уже мало что можно поделать. Я так толком и не въехал, как все это работает, смотрел по месту в основном.

[ramirez]

Нет никакой запутанной истории. =)

table.getn возвращает не размер массива, а n - индекс последнего элемента. Элемент массива считается последним, если за ним следом идет nil.

Этот самый n считается лишь однажды, а дальше бережно хранится в недрах Lua'шных хэш-таблиц. После того, как он там сохранился, повлиять на него могут только функции библиотеки table. insert, например, увеличивает на 1, а remove - уменьшает на 1. Его даже руками можно задать через table.setn.

Элементы из массива правильно удалять через table.remove, тогда все последующие элементы быстро и аккуратно сдвинутся на -1, и никакой дырки не останется, а n будет корректным. А присваивание элементу nil'а - суть указание, что элемент массива все еще есть, просто он стал nil'овым, а индекс последнего элемента массива при этом так и не поменялся.

[SLA]

НИФИГА СЕБЕ, быстрый Ramirez быстр !!! =)

Всё это этой ночью окажется в обновлении аддона. Я не успеваю так быстро вникать в код, как быстро ты его пишешь )

Это что-то. Смотрю, и охреневаю. GetTableSize() растворился как утренний туман. И функции сортировки стали совсем-совсем короткими...

P.S. LUA ведь почти нигде профессионально не используется, откуда у тебя такие навыки в LUA ?

[Гость Kaato]

очень хотелось бы иметь кнопочку включения/выключения подсчета детальной статистики.

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

[SLA]

Quote:

Замалчивать ошибки в скрипте нехорошо, нечего спрашивать размер у всякого мусора.

Но ведь некоторые функции API, при некоторых обстоятельствах, могут вернуть nil вместо таблицы. В таких случаях, имхо, лучше вернуть 0, чем генерировать ошибку.

[Гость Shadadin]

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

[Гость Shadadin]

c table.getn тоже не все гладко:

Code:

Shadadin@cp1251 ~/lua-5.0.3/bin

$ lua -v

Lua 5.1.4  Copyright © 1994-2008 Lua.org, PUC-Rio

Shadadin@cp1251 ~/lua-5.0.3/bin

$ lua t2.lua

4

Shadadin@cp1251 ~/lua-5.0.3/bin

$ ./lua -v

Lua 5.0.3  Copyright © 1994-2006 Tecgraf, PUC-Rio

Shadadin@cp1251 ~/lua-5.0.3/bin

$ ./lua t2.lua

1

Shadadin@cp1251 ~/lua-5.0.3/bin

$ cat ./t2.lua

t = {1,nil,3,4}

print(table.getn(t))

Shadadin@cp1251 ~/lua-5.0.3/bin

$

разные версии луа выдают разный результат. в игре используется как раз версия 5.0.3

[ramirez]

Quote:

Но ведь некоторые функции API, при некоторых обстоятельствах, могут вернуть nil вместо таблицы.

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

[Гость Carnifex]

Quote:

And sorting functions have become very, very short ...

And I think also very very fast. Because the sorting function, which is in the current version is worse the bubble-sort and I hope, that the internal sorting function is like Quicksort or Heapsort. And this can make sorting much faster (by only max 24 elements I think 10 times or more!

[Omegablade]

А собственно когда будет залита новая версия, а не тупо описание ее?)

[Гость Carnifex]

I think, it was planed today

Я думаю, это было запланировано сегодня

BTW is it possible to make the same addon with heal instead of damage (or make a switcher in tihis)

[SLA]

ОБНОВЛЕНИЕ R27 / UPDATE R27 :

RU:

-- ЗВЕРСКИ ОПТИМИЗИРОВАН ВЕСЬ КОД, огромное спасибо Ramirez !!! Он частично или полностью переписал примерно с половину функций, тотально упростил и ускорил работу с массивами, их сортировку, и многое другое. Однозначно, это самая крупная переработка скриптов после DarkMaster'а. Аддон стал невероятно "лёгким", возможно даже, что больше НЕТ необходимости делать кнопку выключения/упрощения подсчёта статистики.

-- Исправлено определение немецкой и французской локализаций. Спасибо Carnifex, без него мы бы и не узнали, что у немцев и французов аддон был на английском. Теперь это исправлено, аддон показывается немцам по-немецки, и французам по-французски.

EN:

-- Addon is TOTALLY OPTIMIZED by Ramirez It is now several times faster than before! Update is highly recommended!

-- Localization detection is now fixed, thanks to Carniflex for reporting this bug. Now, German players will see it in German language, and French players will see it in French language.

DE:

-- Addon ist nun VOLLSTÄNDIG OPTIMIERT von Ramirez Es ist nun um ein Vielfaches schneller als vorher! Update wird dringend empfohlen!

-- Sprache Erkennung ist nun behoben, dank Carniflex für die Meldung dieses Fehlers. Nun Deutschen Spielern wird es in Deutscher Sprache sehen, und Französisch Spielern wird es in Französisch Sprache sehen.

FR:

-- Addon est ENTIÈREMENT OPTIMISÉE par Ramirez Il est maintenant plusieurs fois plus rapide qu'avant! Mise à jour est fortement recommandée!

-- Détection de la langue est maintenant corrigé, Merci à Carniflex pour avoir signalé ce bug. Maintenant, les joueurs français le verrez dans la langue française, et les joueurs allemands le verrez dans la langue allemande.

[SLA]

Yes, heal-meter is possible, and it is planned to be included in future versions of DarkDPSMeter.

BTW, even aggro-meter is possible, but it is harder to make it, because it requires a knowledge of how different spells modifies aggro (some spells have different aggro multipliers, and some spells acts with aggro even more tricky). "RealAgroR" was very simple addon, without any logic or calculation, it was just getting aggro-list via special API function. This API function is now forbidden, that's why "RealAgroR" stopped working. But it is still possible to create an advanced and complicated aggro-meter, based on the knowledge about how different spells modifies aggro.

[sergey]

очень хотелось бы в рейде иметь выбор видеть весь ДПС рейда и только свой при этом уменьшая нагрузку и лаги

[Гость Darkness13]

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

ЗЫЖ машина кор2дуо 3.33, 3.2гб ОЗУ.

[Гость Carnifex]

Quote:

it requires a knowledge of how different spells modifies aggro (some spells have different aggro multipliers, and some spells acts with aggro even more tricky)

Is there a way to find these aggro multipliers out? Or is this only possible by testing it for every different skill ingame? If it is possible to readout the aggro multiplies in LUA, than you only have to multiple it with the damage (or heal) of the skill. The mor tricky skills are non heal or daming taking skills like command controls (fear, hypnosis ...), right?

BTW: A few days ago, I started to learn LUA (I hate the very complicated way of making user interfaces but the rest of programming is easy. I have experience in: Java, Python and Pascal and it seems to be a mix of all^^). One mor problem is, that the api is only available in russian (and google translator is not the best way to understand all^^).

One last question (sry for the offtopic^^): Is it possible to make a similar addon to this one: https://forum.runesofmagic.com/showthread.php?t=228037 (from an other game using lua, but in an other version). They use an LUA command to read an temporary txt file. Is such an command also aviaable in the AO version of LUA?

BTW²: your german is very bad xD

[Гость andi]

Вчера оптимизированный ДПСметр был опробован в ГД. Вывод:

1) Лаги уменьшились, однако до комфортной игры еще далеко

2) Отыскать среди 24 строчек две самые важные в бою - свою и строчку танка практически нереально (мало того что мелкий шрифт, так ведь строчки передвигаются вверх-вниз).

Повторяю свои предложения:

"Предлагаю предусмотреть следующие возможности:

1) При клике по строчке, появляется дополнительное окно с ником и дпсом. Окно значительно больше начальной строчки и шрифт в нем крупный. Таких окон должно быть не больше двух - одно для танка, другое - для конкретного дд, сидящего перед монитором.

2) Если в рейд режиме DarkDPSMeter не удастся (или просто слишком трудно) сделать меньшим лагогенератором, то в дополнение к первому пункту можно предусмотреть выключение обсчета для остальных членов рейда. Иначе говоря, добавить к режиму "рейд" и "группа" режим "пара"."

ПК: AMD Athlon 64 X2 Dual Core Processor 4200+ 2.20ГГц. 3.25 ГБ ОЗУ ATI Radeon HD 5700

[Гость Uldemir]

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