DarkDPSMeter

[Гость Carnifex]

hi, with this sorting should only done every second. (Not tested, if it solve the prblems with big raids, because it is midnight and there are no big raids )

copy it into DarkDPSMeter\Scripts\ and replace the existing files

Google translation:

привет, с этим сортировки только сделать каждую секунду. (Не проверено, если решить prblems с большим рейды, потому что это полночь, Есть нет больших налетов)

скопируйте его в DarkDPSMeter \ Scripts \ и заменить существующие файлы

Edit: now files without textmessage in mod.txt

BTW: are you sure, that the sorting is the problem? I think, that the permantent repainting of the damagenumbers in the player widgets could also be a perfomance problem.

Изменить: теперь файлы без смс в mod.txt;)

Кстати: вы уверены, что сортировка проблему? Я думаю, что permantent перекраску damagenumbers в проигрывателе виджеты можно также производительность проблемы.

File: 5mAM37air0jPFwY.zip

[Zanzarah]

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

[Гость Crab]

Поддерживаю. Мне как РЛ это тоже необходимо. Еще бы супер было добавить кнопку выключения "рейд дпс" в "пати дпс" для экономии производственных ресурсов пк.

[Lemur]

нашел баг, при попытке посмотреть подробную статистику по конкретному игроку, показывает лишь по первым 10 игрокам. соответственно 11 и 21 показывают подробную статистику 1, 12 и 22 - второго, 13 и 23 - третьего и т.д.

[SLA]

Ого! Точно, я знаю, в чём дело. Завтра (то есть, уже сегодня) исправлю.

[Гость nicetest]

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

[Гость Shadadin]

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

[Nikon]

ДПС - урон за секунду конкретного боя конкретного персонажа или всей группы

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

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

И нет никакой разницы, сортировать по ДПС или по нанесенноому урону

[Гость nicetest]

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

[Гость Shadadin]

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

[Nikon]

У меня как то плохо с логикой. ДПС не пересчитывается у тех кто умер до конца боя?

[ekemov]

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

[Гость Shadadin]

нет. именно по этому важна сортировка по суммарному дамагу.

[Nikon]

Бага с петами в солорежиме:

1. Когда еще нет инфы по боям попробуйте атаковать петом противника - ДПС текущего боя будет равен урону пока в бой не вступит хозяин (проблемы с таймером боя?)

2. Когда есть инфа по текщему(прошедшему) бою. Атакуем петом противника - урон будет добавляться к старому бою

И только когда в бой вступает хозяин - проходит сброс инфы старого боя

По этой причине иногда отсутствует часть урона пета (просто пропадает) в текущем бою, хотя в полном отчете весь урон есть с нереально высоким ДПС (счетчик времени не обновляется, когда бьет пет)

[Lemur]

жду

[SLA]

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

-- Исправлена ошибка, приводившая к тому, что подробная статистика показывалась правильно только для первых 10 человек в списке, а у остальных показывалась статистика первой десятки (11 и 21 = 1, 12 и 22 = 2, и т.д.). Эта ошибка существовала с выпуска R22.

-- Исправлен подсчёт среднего урона от заклинаний. Раньше было почему-то (Min+Max)/2. Теперь исправлено на КоличествоУрона/КоличествоУдаров, так должно быть.

[Гость yurdos]

Когда находишься в группе\рейде постоянно происходит сортировка участников с нулевым уроном. Они перемещаются по списку вверх-вниз.

обновление R28

[Гость Carnifex]

You do not have to read this (This was only my thinkings while trying to fix this)

----------------------------

This problem is there since the sort functions are optimized.

If the party/raid is not in a fight: no sorting (no up an down)

If the party/raid is in a fight: up and down of members with the same damage count (e.g. 0)

I Think, this should work in Russian gameversion

Code:

local function CompareCombatantsByDamageAmount( v1, v2 )

    if v1.DamageAmount==v2.DamageAmount then

    return usermods.fromWString(v1.Name) < usermods.fromWString(v2.Name)

    else return v1.DamageAmount > v2.DamageAmount end

end

This is an error (is not realy an error but an not nice handling of same values) in the lua-internal table.sort function

@SLA: why is TCombatant.ID sometimes a nile value (I like to sort after it for EU/US instead of the name) --> Updatet: Now check if it is a nil value and it works. (ID's only excist if you are in a fight?)

wtf, both version makes the up and down (the last one in senseless i know^^)

I think table.sort is somethink like quicksort or heapsort, and there it can come of swichen positions of same values.

[Гость Carnifex]

Here is a working fix for this issue (up and down). If there are members with the same damage amount, it will sort them lexicographically.

Вот рабочий исправление данной проблемы (вверх и вниз). Если Есть членов с тем же количеством повреждений, то они будут отсортированы лексикографически.

Code:

local function CompareCombatantsByDamageAmount( v1, v2 )

    if v1.DamageAmount == v2.DamageAmount then

        return common.CompareWString(v1.Name,v2.Name)==-1

    else return v1.DamageAmount > v2.DamageAmount end 

end

@Ramirez: thy for your help. (I will have the next patches in eu version, so that we can bether handle wstrings)

File: DarkDPSMeter_fix_final.zip

[Гость Carnifex]

*please ignore me*

[Nikon]

Просто надо информацию обновлять раз в секунду по таймеру во время боя. Зачем там все остальное прикручено - непонятно

И то что люди с одинаковым (не обязательно нулевым) уроном вверх-вниз прыгают - это уж издержки сортировки: сейчас 1 повезло наверху оказаться, потом 2-й вылезет наверх

[ramirez]

Quote:

I think table.sort is somethink like quicksort or heapsort, and there it can come of swichen positions of same values.

Oh, c'mon already! =) It's quicksort.

http://lua-users.org/wiki/LuaSorting
http://www.lua.org/manual/5.0/manual.html#5.4

About table.sort:

Quote:

The sort algorithm is not stable, that is, elements considered equal by the given order may have their relative positions changed by the sort.

BTW, there is common.CompareWString( arg1, arg2 ) internal Lua API function, use it instead of standard Lua string comparison operators.

[Гость Carnifex]

if it is quicksort, then it's clear, why there is an up and down (everyone how knwo, how quicksort work can image that)

have I check for 1 or -1 to have an A to Z sort? (why is the AO LUA API only available in russian and why is the google translator so bad) --> Edit: -1 (try and fail is still the best method to find something out^^)

BTW: I have edit the code in my first comment to this, before you notice, that this was an Z to A sort

[ramirez]

-1 --> arg1 < arg2; table.sort second argument function should return true

0 --> arg1 == arg2; table.sort second argument function should return true (?)

1 --> arg1 > arg2. table.sort second argument function should return false

[SLA]

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

-- Исправлена сортировка участников, чтобы участники с нулевым уроном не перемещались по списку вверх-вниз.