W związku z pojawiającymi się regularnie zastrzeżeniami dotyczącymi tzw. "procentów", chciałem zwrócić uwagę na powiązany z nimi błąd i zaproponować kilka mechanizmów, o które można by wzbogacić już istniejącą funkcję /stats.
Potrzebne są lepsze narzędzia analityczne wbudowane w Taern. Wreszcie można by coś konkretnego wykazać (czy w jedną, czy drugą stronę).

Błąd wyświetlania:

Obecnie /stats pokazuje pokrywające się przedziały:
0-10%, 10-20% itd.
Jest to oczywisty błąd (bo nie wiadomo do którego przedziału należy np. atak na 10%), zakładam że przedziały w rzeczywistości wyglądają jakoś tak:
0-9%, 10-19% etc.
lub
1-10%, 11-20%...

Sugerowałbym wydzielenie wyników o prawdopodobieństwie 0% (to wynik uników, czy odporności na korzenie, i zaniża cały przedział) oraz 100% (brak obrony/odporności, zawyża cały przedział). Przykładowo: rzucam korzenie na 9%, na przeciwnika z odpornością na korzenie. Połowa ataków nie wejdzie z racji odporności (lub już nałożonych korzeni). Statystyki zamiast do 9%, będą zmierzały do 4,5% (lub mniej).

Segregacja wyników powinna według mnie wyglądać następująco:
0%
1-10%
11-20%
...
91-99%
100%



Dodatkowe funkcje statystyk:

W poprzednich podobnych tematach administracja zawsze broniła się żądając próbki wyników z wielkiej liczby zdarzeń.
Słusznie, oczywiście, gdyby nie fakt że jest to niemożliwe z czysto praktycznych przyczyn (DC po 10 minutach, zebranie wyników z kilku tysięcy walk bez choćby odwiedzenia wychodka jest raczej niemożliwe, gra potrafi się wywiesić bez wyraźnego powodu, a niektórzy z nas też mają pracę, rodzinę).


Muszę też wypomnieć kwestię, na którą forumowicze zwracali uwagę wielokrotnie - metoda zliczania /stats była sama w sobie niemiarodajna. Fakt, ostatni UP poprawił wykazane PRZEZ GRACZY nieścisłości. Czy wszystkie, nie wiemy (pewnie nie).

Wystarczy błąd jednej umiejętności, by zaburzyć wyniki wszystkich statystyk. Dlatego proponowałbym
dodanie narzędzia zliczającego statystyki trafień każdego skila z osobna, a /stats wyświetlałoby średnią z wszystkich. Takie narzędzie umożliwiłoby skuteczniejszą analizę potencjalnych błędów poszczególnych umiejętności (jak miało to miejsce z urokami czy blokiem).
Żeby nie komplikować, można by zrobić tablicę z numerowanymi skilami, wg. kolejności występowania na liście umiejętności, np.
/stats1A (statystyki pierszego skila z pierwszej zakładki)
/stats4B (statystyki czwartego skila z drugiej zakładki)

które wyświetlałoby podsumowanie podobne do obecnych /stats, ale dla jednej, konkretniej umiejętności postaci.



Grupowanie wyników (częste nieprawdopodobne statystycznie serie porażek/sukcesów):

Łatwiej zauważa się serie "pechowe" od "szczęśliwych" (który to argument też widziałem w jednym z poprzednich tematów).
Owszem, zgadza się. Tyle że tak jedne, jak i drugie powinny występować odpowiednio rzadko.
Jak ktoś wygrywa w totka co drugi dzień (korzystając z już przytoczonej hiperboli), ale zostaje porażony piorunem trzy razy dziennie, to wcale nie znaczy że wszystko się "uśrednia". A to, zdaniem niektórych graczy (w tym OP) ma miejsce.

Przeprowadziłem testy na MO, wyłącznie ataki iskrą, na wilkach. Jakoś 300 ataków łącznie, zanim zabrakło mi cierpliwości.
Zgodnie z oczekiwaniami, wartości się nieco uśredniły.
Zgodnie z przewidywaniami, zdarzyły się serie 4 i 5 pudeł na 80%. Może mam pecha, ale wiem że słabe rozproszenie wyników jest typowe dla kiepskich PRNG.



Przydałoby się notowanie najbardziej nieprawdopodobnych serii, np. jeśli seria zdarzeń miała szanse zaistnienia poniżej 5% (arbitralnie i do ustalenia), dopisywany jest raport do listy, której odczytanie umożliwiałaby komenda w stylu:

/statsLOTTO

dająca wyniki np. w formacie analogicznym do poprzedniej propozycji:
Szansa wystąpienia całej serii w % liczba(numer skila) litera (zakładka) liczba (szansa powodzenia) boolean literowo (czy wyszło):

0,15% 1A-40-F 4B-5-T 5B-95-F
(szansa niepowodzenia ataku o celności 40%, powodzenia ataku o celności 5% i niepowodzenia ataku o celności 95% wynosi 0,15%)


Ponadto wrzucenie na serwer czystej tekstowej stronki ze skryptem PRNG do testów umożliwiłoby zbadanie jakości algorytmu, bez poznania kodu. Dodajcie Captcha do wypełnienia co wywołanie strony (z np. 1000 wyników) i nie ma ryzyka DoSu, a społeczność mogłaby wreszcie rzetelnie i na dużej liczbie prób ocenić jak "poprawnie" to działa.

Wtedy tak my (gracze) jak i administracja, mielibyśmy podstawy do rzetelnej oceny mechanizmów gry, wyłapywania ewentualnych błędów na poszczególnych skilach czy nawet błędów na przeciwnikach (w określonych sytuacjach).

W komendzie /stats było kilka błędów powodujących zaniżanie % udanych trafień wyników.

Jako ataki nieudane były brane ataki, które trafiły lecz zostały zniwelowane przez:
- unik
- skok farida
- rozproszenie holma
- bloka tarczą
- tarcza ognia
- uderzenie krytyczne

Dlatego też nawet przy dużej próbie wyniki wyglądały na nieco pechowe.

Dzisiaj poprawiłem te problemy (poprawka będzie wgrana przy kolejnym upie). Dodałem też dodatkowy parametr do komendy /stats. Teraz możemy podać również dzielnik. Domyślnie jest to 10. Dla dzielnika 5 otrzymamy 20 wyników, podzielone co 5%. Podając 1 komenda przedstawi 100 wyników.


Jeżeli chodzi o wyłapywanie pechowych serii to incjatywa dobre lecz na to już niestety nie mam czasu. Mamy mnóstwo nie cierpiących zwłoki rzeczy do wprowadzenia (wielki update Alaril) więc jeżeli ktoś ma ochotę to łapać pechowe serie musi póki co sam Może w późniejszym terminie je dorobimy.

Tak samo z grupowaniem skilli. Niby nie dużo roboty ale niestety czasu nam ciągle brakuje. Nie jest to też za bardzo potrzebne ponieważ każda kategoria umiejętności (buffy,debuffy,dystansowe,wręcz, grupowe) korzysta ze wspólnego kodu obliczającego trafienie. bierze tylko na wejściu różne parametry.


Jakiego algorytmu używamy? 2 różnych:
1. Standardowy javowy Math.random().
2. Połączenie 2x XorShift + LCG + multiply with carry generator. ( http://javamex.com/tutorials/random_num ... ipes.shtml )

W walce do obliczenia trafienia działa nr 2. Problemem może jednak być też to, że przy równocześnie toczonych kilkudziesięciu walkach mogą one sobie podkradać "dobre wyniki" ponieważ korzystają z jednej instancji generatora. W najbliższym updacie wgram tu lekką poprawkę + zmodyfikowaną funkcję /stats.

Jak wygląda komenda "/stats" z dodanym dzielnikiem?

Wpisywałem "/stats1" i efektem było "[wrong command]". Wpisałem "/stats 1" i nic się nie wyświetliło...

@up

Przepraszam... chyba z zaspania przegapiłem...

Wobec tego nie pozostaje mi nic tylko czekać na update

Zastanawia mnie też na ile plastyczny jest skrypt generatora liczb losowych (tzn. czy da się łatwo poprawić jeśli okaże się, że działa źle)

LCG jest słaby, ale opisany hybrydowy generator jest dobry i bardzo wydajny, a korekta, o ile dobrze rozumiem, nie powinna być trudna, możliwą przyczynę ewentualnego błędu masz opisaną w temacie podlinkowanym przez dryga:



I w zasadzie ogranicza się do 1 biblioteki i dodania/odkomentowania kilku linijek.

http://www.win.tue.nl/~marko/2WB05/HighQualityRandom.java

A wyjaśnienie dlaczego wielowątkowość może obniżyć jakość PRNG zgrubnie opisane tutaj: http://stackoverflow.com/questions/616434/do-prng-need-to-be-thread-safe
A tu bardziej szczegółowo: http://blogs.msdn.com/b/pfxteam/archive/2009/02/19/9434171.aspx



Dzięki i za to, co miałeś czas zrobić
Mam nadzieję tylko że przedziały będą miały jawne granice np.
0-5%
6-10%
Bo obecnie nie było wiadomo, czy przedziały są zamknięte, czy otwarte, i w którą stronę (no dobra, wiem że wartość górna przedziału była otwarta, a dolna zamknięta, bo przetestowałem: równe 80% trafiało w przedział 80-90 a nie 70-80).

Ponieważ na s3 był dzisiaj drobny crash przy okazji wgrałem tam wspomniane poprawki po stronie serwera. Co prawda z komendy /stats z dodatkowym parametem nie da sie jeszcze skorzystać ale widac poprawe w zliczaniu statystyk. Poniżej wyniki po 25 min dla całego serwera:

0-9: 5 / 101 = 4
10-19: 47 / 280 = 16
20-29: 188 / 658 = 28
30-39: 378 / 1172 = 32
40-49: 787 / 1713 = 45
50-59: 1223 / 2262 = 54
60-69: 1632 / 2538 = 64
70-79: 2057 / 2750 = 74
80-89: 1699 / 2045 = 83
90-100: 2137 / 2176 = 98

Po dłuższej chwili:
0-9: 6 / 428 = 1
10-19: 112 / 726 = 15
20-29: 446 / 1765 = 25
30-39: 901 / 2524 = 35
40-49: 1465 / 3314 = 44
50-59: 2329 / 4150 = 56
60-69: 3274 / 5122 = 63
70-79: 4460 / 5845 = 76
80-89: 3498 / 4157 = 84
90-100: 6427 / 6509 = 98

Hehe, w ogóle nie da sie skorzystać z komend stats i statsd

Póki co klient nie jest kompatybilny z wersją serwera na s3. Dlatego wyrzuca błąd. Wgram odpowiednią wersję jak będzie mniej osób na serwerze.

Czyli kiedy? najmniej ludzi powinno być koło 5:00 rano od tamtego czasu ta pora nadeszła już trzykrotnie... chodziło o porę doby, tygodnia czy może święta bożego narodzenia?

A na poważnie - mam wrażenie że wczoraj coś się zkwasiło z % i nie mogę tego udowodnić :/

Proszę drygu wgraj ten update