Zitat von Mistral@edit: Er ist nicht weg - die Antwort der DB ist manchmal Müll (8.1<8.1 ist nicht so richtig wahr)
Doch, 8.1<8.1 kann schon wahr sein, Fließkommazahlen haben schließlich intern mehr Stellen, als nach außen hin dargestellt werden. Auch wenn du einer Fließkommavariablen ausdrücklich 8.1 zuweist, kann das intern als 8.100000001 gespeichert werden, was dann größer ist als 8.1.
Eine mögliche Abhilfe: Die zwei Fließkommazahlen nicht direkt vergleichen, sondern die Ergebnisse einer Rundungsfunktion vergleichen, die die Fließkommazahlen auf n signifikante Nachkommastellen rundet.
Ich hoffe jetzt nur, daß dir das was bringt, und der Fehler nicht in datenbankinternem Code auftritt.
Das Problem war durchaus erkannt und klar, allein die Lösung war noch nicht erarbeitet. Jetzt sollte es tun. Ich runde jetzt auf vier Nachkommastellen und multipliziere mit 10000. Sicherheitshalber runde ich nochmal ab. Damit stehen die Averages ohne Nachkommastelle in der Datenbank, mit 10^4 zu gross halt. Bei der Anzeige wird einfach wieder durch 10000 geteilt.
zeigen jetzt Datum/Uhrzeit des Rekordes an. War das wieder ne Fummlerei, weil das Datum in der $record-Struct nicht ausgefüllt war. Besorg ich mir das halt selbst aus der DB.
Weiterhin zeigen die Kommandos
1 2
/top /recs
die Nicknamen jetzt mit ihren Farbcodes an. Schön, die Teammembers gleich erkennen zu können.
Ausserdem sollte sich ASECO automatisch neustarten wenn die Challengeinfo [none] oder [] ist. Das passiert immer beim Challengewechsel wenn der Server leer ist. Von selbst fängt sich das Skript dann nicht mehr.
Es gab in diesem Zusammenhang zwar ein Timing-Problem wenn ich den Server schlafen gelegt habe (und ASECO sich dann restartet hat), das sollte aber weg sein. Wenn das Problem morgen früh wieder zu beobachten ist bevor ich zum Flughafen fahre, muss ich diesen automatischen Reparatur-Neustart wieder ausbauen.
Zitat von Mistral... Es gab in diesem Zusammenhang zwar ein Timing-Problem wenn ich den Server schlafen gelegt habe (und ASECO sich dann restartet hat), das sollte aber weg sein. Wenn das Problem morgen früh wieder zu beobachten ist bevor ich zum Flughafen fahre, muss ich diesen automatischen Reparatur-Neustart wieder ausbauen.
Guten Morgen,
das Timingproblem ist gelöst und sowohl Server, als auch das Script schlafen jetzt brav. Mal sehen, ob der Server die 3 Tage durchhält. Ich muss in 1.5h zum Flughafen. Sollte es Probleme geben und der Server nicht verfügbar sein, soll Tweety meiner Frau was aufn AB säuseln, oder mir ne SMS schicken (bitte nicht anrufen, das teuert in UK wie Sau). Sie wird dann bei nächster Gelegenheit den Server neu starten (gegen Abend).
Ich hoffe alles funktioniert und der Server stirbt nicht den Hitzetod - bis Mittwoch Nacht/Donnerstag Vormittag,
Ein paar werden die letzten Tage schon mitbekommen haben, dass es einen "Mistral Test" Server gab. Einige von euch wissen wieso, einige nicht.
Vor 10 Minuten ist es passiert: Mistral ist umgezogen.
Er läuft jetzt nicht mehr auf meinem Rechner sondern 24/7 auf einer Linux-Maschine in Frankfurt, auf der FlipFlapFly uns ein Eckchen freigemacht hat. FlipFlapFly hatte auch einigen Aufwand weil erst MySQL5 und PHP5 dort installiert werden mussten.
Nochmals ein dickes Danke von uns allen FlipFlapFly!
Was ändert sich für euch? NICHTS!
Alle Daten, Tracks, Skripte u.s.w. wurden übertragen. Alle Webinterfaces umgeleitet.
Zitat von MistralFlipFlapFly hatte auch einigen Aufwand weil erst MySQL5 und PHP5 dort installiert werden mussten.
Hrhr, im Vergleich zu deinem Aufwand hab ich quasi in der Hängematte gelegen und Cocktails geschlürft
Sie Skripte "server" und "aseco" waren schon bitter. Seit 3 Jahren nix mehr mit UNIX gemacht und noch nie /bin/sh-Skripte geschrieben - meine Shell war unter Solaris immer die C-Shell Aber es tüdelt ja.
Wie ihr alle wisst läuft Mistral (TMN) auf einer relativ alten ASECO/RASP-Version. Der Grund dafür ist, dass ich alle unsere Modifikationen/Bugfixes direkt in die Original-Skripte eingebaut habe. Daran werde ich ich auch nichts mehr ändern, da Mistral (TMN) stabil läuft.
Das Gleiche hatte ich am Anfang für die TMU-Version von Mistral gemacht. Das war auch der Grund warum es ein paar Stunden gedauert hat bis das Skript online war.
Leider ist es so, dass die RASP Versionen ziemlich buggy sind und der Author fast jeden 2. Tag eine überarbeitet Version ins Netz stellt. Eine Übersicht was er wo geändert hat liefert er nicht. Stellenweise werden Funktionen total umgestrickt oder in andere Dateien übertragen. Das macht ein Update fast unmöglich ohne unsere eigenen Funktionen immer wieder zu überschreiben.
Deswegen habe ich gestern, in ein paar stillen Stunden, mein Konzept völlig überarbeitet. Ich habe alle unsere Anpassungen in mein Plugin ausgelagert und muss nur noch wenig in die Original-Skripte eingreifen (Original-Funktion deaktivieren/meine aufrufen). Dadurch kann man den "Mistral"-Zustand nach einem Update in ca. 20 Minuten wieder herstellen.
Ich habe mir eine "Todo-Liste" erstellt und anhand Dieser heute auf die neuste Version aktualisiert. Soweit, denke ich alles getestet zu haben und mir ist nichts aufgefallen, aber ich bin halt auch nicht unfehlbar. Sollte euch also was auffallen, bitte PM an mich.
Soo ... bin endlich dazu gekommen das "alte" gewachsene Skript von Mistral (TM Nations), das immernoch auf RASP 0.2 basierte zu aktualisieren. Ich habe also das Mistral-Plugin vom TMU-Server auf TMN umgeschrieben, auf ASECO 0.61b und RASP 1.4 aktualisiert und unsere Änderungen wieder reingefummelt. (Ausserdem ein paar Bugs von RASP 1.4 entfernt - der Typ ist manchmal ein Blindfisch)
Bis jetzt sieht alles gut aus. Sollte euch etwas auffallen -> PM an mich.
Features (TMN+TMU): /list - zeigt alle Tracks an /list nofinish - zeigt alle Tracks an, die ihr noch nicht gefahren seid /list ron - zeigt alle Tracks an, deren Author "ron" enthält (z.B. Ron Turbo) /jukebox - gebt einfach die Nummer des letzten /list-Kommandos an, um euren Wunschtrack als nächstes zu spielen. /admin remove - entfernt einen Track aus dem Map-Cycle TMN-Server: /admin add - lädt den Track von TMX runter (z.B. id=13624 ist Moving Power von Panis) und setzt ihn ans ENDE der Trackliste (holt ihn mit der Jukebox nach vorne) TMU-Server: /admin add TMU|TMN|TMS|TMO - siehe oben. Beim TMU-Server müsst ihr angeben, von welchem TMX der Track runtergeladen werden soll.
Ansonsten: /help /admin help
um euch nochmals zu versichern, dass ihr alle Kommandos kennt.
Da ich jetzt die ersten Klagen über die Jukebox lese ("Immer die gleichen Leute wünschen sich immer die gleichen Tracks") habe ich den buffer von 10 Tracks (ca. 1h) auf 60 Tracks (ca. 6h) erhöht.
In anderen Worten: Es kann kein Track in die Jukebox eingefügt werden, der die letzten 6h bereits gelaufen ist.
macht sinn. was mich nur mal grad interessieren würde wie's am trainingserver ist .... da sind ja eh nur 10tracks und da machts ja im prinzip keinen sinn wenn der buffer bei 10 tracks ist.
Zitat von d!4b0LuSmacht sinn. was mich nur mal grad interessieren würde wie's am trainingserver ist .... da sind ja eh nur 10tracks und da machts ja im prinzip keinen sinn wenn der buffer bei 10 tracks ist.
Wenn ich mich recht erinnere hatte ich den Buffer, bzw. die Abfrage für euch auf dem Trainingsserver ausgebaut. Oder funktioniert die Jukebox dort etwa nicht?