gameMinLength Verbesserung

11/22/2010 16:43 Grommel#1
Bisher prüft ja das Einstiegsscript (NTBot.ntj oder NTBotLeech.ntj) das zwischen 2 Games (Erstellungszeitpunkt) immer mind. die in gameMinLength eingestellte Zeit verstreicht (meist 3min).

Nun kam mir die Idee das es doch sinnvoller wäre den Durchschnitt der letzten Games für diese Kontrolle zu verwenden. Wenn er also nach 2 Games (zu je 6 Minuten) ein Game nach nur einer Minute wieder verlässt, brauch er theor. nicht 2 Minuten warten da die letzten Games signifikant länger als 3 Minute gedauert haben. Sinnvoll erscheint mir dabei der Durchschnitt der letzten 10 Spiele.

Nun die Fragen:

ist mein Logik verständlich formuliert ?
wenn ja, was haltet ihr davon ?
sinnvoll sowas weiter umzusetzen ?

Am Schluss noch meine grobe Idee wie sowas umzusetzen wäre:
Code:
//Sobald ein Spiel gejoint/erstellt wurde
lastGamesJoined.push(GetTickCount());
if(lastGamesJoined.length > 10) 
     lastGamesJoined.shift();

// Prüfung bevor ein Spiel gejoint/erstellt wird
if(lastGamesJoined[0] > (GetTickCount()-gameMinLength*lastGamesJoined.length))
		SetStatusText(' Need to Wait XXX Seconds');
else // ganz normal weitermachen
11/22/2010 17:29 njomnjomnjom#2
Hey das ist eine ganz nette Idee!
Den Gedanken kann man noch weiterstricken.


Jetzt musst du dir nurnoch überlegen was passiert wenn er in Game 1 und in Game 2 einen restart nach sagen wir jeweils 60 Sekunden hatte.
Und die restlichen 18 games exakt 3 Minuten jeweils dauern.
11/22/2010 17:56 Grommel#3
Zwar eine sehr unwahrscheinliche Konstellation, könnte aber durchaus wie beschrieben auftreten und wurde von mir bisher auch so nicht bedacht.

Problem ist das der Bot bei einem Restart alle seine Variablen vergisst. (jedenfalls so weit ich die Programmierung bisher durchschaue)
Einzige Lösung wäre daher, dass der Bot beim ersten starten(bzw nach restart) grundsätzlich erstmal 3 min wartet bevor er mit seiner Arbeit beginnt. Sprich wenn kein Durchnitt gebildet werden kann, weil noch keine Games gelaufen sind, erstmal sicherheitshalber gameMinLength als Delay ausführen.

Natürlich fehlen einem dann bei jeden Start/Restart die besagte gameMinLength Zeit. Ich denke aber bei locker hundert runs pro Restart kann man den Nachteil gut vernachlässigen, wenn er nicht sogar durch die Verbesserung wieder wett gemacht wird.
11/22/2010 18:10 njomnjomnjom#4
Schon :P

Mir ist es nur soffort eingefallen, dass das passieren könnte und dachte mir "hmm na wenner schon dabei ist" ;)

Du könntest die Variablen extern speichern.
In einem xml file oder ähnlichem, dann wären sie nach dem restart noch da.
Aber das wäre wohl deutlich zuviel Arbeit.
11/22/2010 19:05 Grommel#5
Über ein externes File würde ich es nur sehr ungern regeln, da ich solche Lösungen immer etwas "dreckig" finde. Evtl hat ja hier jemand der tiefer in der Programmierung steckt noch nen Tip für ne Art globale Variable dafür.

Bis dahin werde ich mal versuchen das ganze wie beschrieben umzusetzen.

Sollte noch jemand Logikfehler meinerseits finden freue ich mich über jeden Hinweis, da ich natürlich nicht beim ersten Test direkt RD haben möchte.
11/22/2010 20:03 Muddy Waters#6
Die Idee ist durchaus interessant, wenn auch eher was für public runs.
Bei mir sind die Spiele grundsätzlich private und da ist es mir herzlich egal, ob dort mal die ein oder andere Minute wartend verbracht wird. :)

Quote:
Originally Posted by Grommel View Post
Über ein externes File würde ich es nur sehr ungern regeln, da ich solche Lösungen immer etwas "dreckig" finde. Evtl hat ja hier jemand der tiefer in der Programmierung steckt noch nen Tip für ne Art globale Variable dafür.

Bis dahin werde ich mal versuchen das ganze wie beschrieben umzusetzen.

Sollte noch jemand Logikfehler meinerseits finden freue ich mich über jeden Hinweis, da ich natürlich nicht beim ersten Test direkt RD haben möchte.
Das hat hier weniger mit "tiefer in der Programmierung" zu tun, wir haben leider keinen Zugriff auf alle D2NT Ressourcen in Quellcode Form, darum sind die Möglichkeiten schlichtweg eingeschränkt und wir müssen uns behelfen. :(

Darum wirst du es wohl oder über auf die "dreckige" Tour lösen müssen...
Einplanen sollte man Restarts aber in jedem Fall, da sie leider einfach die Regel sind.

Was ich noch nicht verstanden habe: Wie genau wird die Laufzeit berechnet?
Hier gibt es ja sicherlich verschiedene Ansätze, darum die Frage.

Lg
Muddy
11/22/2010 21:06 Grommel#7
Quote:
Darum wirst du es wohl oder über auf die "dreckige" Tour lösen müssen...
Einplanen sollte man Restarts aber in jedem Fall, da sie leider einfach die Regel sind.
Hier gibt es ja schon die Alternative "3min warten" Lösung. Was hälst du davon ?
Bei mir sind Restarts übrigens äußerst selten geworden (auf 1000 runs evtl 2-3).

Quote:
Was ich noch nicht verstanden habe: Wie genau wird die Laufzeit berechnet?
Hier gibt es ja sicherlich verschiedene Ansätze, darum die Frage.
Die Frage versteh ich grade nicht. Gibt eigtl nur einen Denkansatz der im ersten Post so gut ich es vermag beschrieben steht. Wüsste auch nicht wie ich es allgemein verständlich besser formulieren könnte ohne mich zu wiederholen. Wie ich es programmiertechnisch umsetzen würde müsste eigtl. an dem Codestück oben ersichtlich sein.

Aber evtl steh ich jetzt auch auf dem Schlauch , wenn ja bitte nochmal genau erklären welche Laufzeit Berechnung du jetzt meinst ...
11/22/2010 21:48 Muddy Waters#8
Quote:
Originally Posted by Grommel View Post
Hier gibt es ja schon die Alternative "3min warten" Lösung. Was hälst du davon ?
Bei mir sind Restarts übrigens äußerst selten geworden (auf 1000 runs evtl 2-3).



Die Frage versteh ich grade nicht. Gibt eigtl nur einen Denkansatz der im ersten Post so gut ich es vermag beschrieben steht. Wüsste auch nicht wie ich es allgemein verständlich besser formulieren könnte ohne mich zu wiederholen. Wie ich es programmiertechnisch umsetzen würde müsste eigtl. an dem Codestück oben ersichtlich sein.

Aber evtl steh ich jetzt auch auf dem Schlauch , wenn ja bitte nochmal genau erklären welche Laufzeit Berechnung du jetzt meinst ...
Das mit den 3 Minuten würde sicherlich gehen. :)

Ich kann einfach die Berechnung nicht ganz nachvollziehen.
Einen Mittelwert berechnet man ja typischerweise, indem man alle zu mittelnden Werte addiert und danach durch die Anzahl der Werte dividiert.

Das finde ich in deinem Code Beispiel nicht, oder ich habe grundsätzlich deinen Ansatz nicht richtig verstanden - was ja durchaus nicht ganz abwegig wäre. :o

Um die tatsächliche Spielzeit zu messen müsste man ja die Zeitdifferenz zwischen Einstieg ins Spiel und Wiedereintritt in den Channel aufnehmen.
In dem obigen Beispiel sieht es für mich so aus, also würden nur die Ticks beim Spieleintritt aufgenommen. Channel Wartezeiten bleiben damit außen vor, wodurch der eigentliche Durchschnittswert hin zu einer längeren Spieldauer als eigentlich vorhanden verfälscht wird, abhängig von der jeweiligen Wartezeit vorm Erstellen eines Spiels.

Eventuell ist das ja auch so gedacht, auch wenn ich mir nicht vorstellen kann warum.

Generell fände ich es aber allein von der Nachvollziehbarkeit her besser, die Tick Differenzen direkt in Zeiträume in Sekunden oder Millisekunden zu verwursten - das kann man sich nämlich viel besser vorstellen und somit leichter nachvollziehen, ob das Programm auch das tut was es soll.

Aber wie gesagt, vielleicht bin ich hier ja auch gedanklich auf dem Holzweg. :)

Lg
Muddy
11/22/2010 22:12 Grommel#9
klares verständnis problem, da ich den durchschnitt wirklich nie berechne ... aber es beschreib es halt für den "nicht coder" recht genau

Es wird quasi eine Array der Startzeiten angelegt, und dann vor dem (X+Y)ten spiel nur geprüft wann das Xte Spiel gestartet wurde und ob minLength*Y Abstand dazwischen sind.

Er guckt also Y Spiele rückwärts nach der Startzeit und prüft ob mind. Y*mindestLänge dazwischen liegen. Da alle Werte des Arrays die weiter als Y zurückliegen nicht mehr gebraucht werden das shift() bei > Y Einträgen.

Y = 10 da ich es besser finde auf 10games pro 30min zu checken anstatt auf 20 pro Stunde.
11/25/2010 01:55 Grommel#10
soo .. dachte ich geb mal ne Statusmeldung ab ... hab entsprechende Zeilen passend untergebracht und mittlerweile auch fast 800 Runs damit gemacht ... ohne rd

Bei einem schnellem Test reagiert die Sache genau wie gedacht. Also nach 2 Games zu 6min kann ich ein Game manuell nach 1min beenden und er joint/erstellt sofort das nächste. Zwinge ich ihn das nächste Game auch wieder nach 1min zu beenden, wartet er ~60sek vorm nächsten Game. (Zwinge ich ihn sofort im ersten Game nach einer Minute raus wartet er danach direkt 2min)

Wenn man nach paar 100 Runs sich mal das Log genauer anschaut findet man auch einige Stellen an der 2 Games durchaus weniger als 180sek auseinander sind. Soweit scheint die grobe Funktion also gegeben.

Die 3min Delay zu Beginn haben sich jedoch als ziemlich nervig erwiesen, deswegen hab ich das auch momentan erstmal wieder rausgenommen.

Desweiteren habe ich ihn auch einmal erwischt als er im Channel noch ein paar tausend Sekunden warten wollte (und das wohl schon seit 20min). Da der Wert ~65000 betrug, geh ich davon aus das eine unsigned value ins negative gerutscht ist. Seitdem trat der Fehler allerdings auch nicht erneut auf (hab im log nachgeschaut).

Das er bei einem "GameCreateBug" nie im Game ankommt, aber es trotzdem als erstelltes Spiel gilt, habe ich bisher auch nicht bedacht. Hier müsste ich noch die passende Stelle im Code suchen.

Soweit zum aktuellen Stand. Eure Meinungen, Anregungen und Ideen sind natürlich weiterhin erwünscht.
10/25/2011 13:17 Grommel#11
... one year later ...

Ich nutze das ganze jetzt so mittlerweile fast ein Jahr und kann nun mit gutem gewissen das ganze auch mal weitergeben. Da ich vor kurzen auch von meinem eigenen Bot gefummel mal zu Muddy´s gewechselt bin, kann ich den Einbau jetzt auch anhand Muddy´s NTBot.ntj beschreiben.

Vorgensweise der Veränderung

Angenommen das 41. Spiel ist gerade nach 1,5min zuende gegangen und gameMinlength steht aber auf 3min. Die letzten 10 Spiele haben aber alle gute 4min gedauert. ( LastGamesStackSize steht auf 10 )

standard verhalten :
er wartet stur die 1,5min ab, da er nur den startpunkt des 41. Spiels kennt, und nicht weiß was vorher war.

verbessertes verhalten:
er erkennt das seit dem Start von Spiel 31. mehr als 40 min vergangen sind und er daher direkt ein neues Spiel öffnen kann. Schließlich hat der Bot eigtl schon 10 Min RD Vorsprung, die er bisher einfach nicht nutzen konnte.


Sinnvolle Verwendung
Bei Publicruns mit nicht gleichmässiger runlänge .
z.B. Public Baalruns mit Zeiten von 2:40 - 3:20 und nur einem CDKey, da sich hier die wartezeten der kürzeren runs mit den überhangzeiten der längeren runs aufheben.


Einbauanleitung für Muddys NTBot.ntj :

bei Zeile ~ 166 unter folgenden :
Code:
 var MadeAnnouncement = false;
bitte folgendes einfügen :
Code:
var LastGamesStackSize = 10
var LastGamesStack = new Array()

bei Zeile ~ 380 über folgendem :
Code:
 if( GetTickCount() > NextGameMake)
bitte folgendes einfügen :
Code:
if( LastGamesStack.length == 0 ) 
	LastGamesStack.push( GetTickCount() - GameMinLength)
NextGameMake = LastGamesStack[0] + (GameMinLength * LastGamesStack.length)

bei Zeile ~ 500 unter folgendem :
Code:
LastGameMade = GetTickCount();
bitte folgendes einfügen :
Code:
LastGamesStack.push(LastGameMade);
if(LastGamesStack.length > LastGamesStackSize)
	LastGamesStack.shift();
Alle sonstigen features von Muddy´s NTBot.ntj bleiben voll funktionstüchtig erhalten. Bei mir nennt sich das File dann NTBotPublic.ntj, aber das bleibt jedem selbst überlassen.

Gruß