Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0001983EresseaGeneralöffentlich2014-02-20 09:54
ReporterThoran Bearbeitung durchEnno  
PrioritätnormalSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status geschlossenLösungerledigt 
Zusammenfassung0001983: Message-IDs durcheinander
Beschreibung

Mit der Auswertung 858 haben sich offenbar die Message-IDs geändert. Das geschah ja öfter schon einmal. Diesmal allerdings hat sich da ein fehler eingeschlichen!

Vorher gab es für verschiedene Nachrichtenarten (Kamp, Handel, etc.) jeweils verschiedene IDs, d.h. man konnte anhand des Feldes ";type" einer Nachricht herausfinden, worauf sich die Nachricht bezieht und diese dann entsprechend auswerten.

Mit der jetzigen Auswertung allerdings gibt es da Doubletten, was eine automatische Auswertung (ohne den Nachrichtentext selbst zu parsen) nahezu unmöglich macht.

So haben z.B. die Nachrichtenarten zum Ankauf bzw. Verkauf jetzt die gleiche ID, nämlich -1210949232. Vorher war das für den Ankauf die ID 1549031288 und für den Verkauf die ID 1478912224. Auch für Kampfnachrichten hat sich die ID (oder mindestens einer der IDs) geändert. Aus 1964885468 wurde -1210949192; leider ist das auch die ID, die für Einnahmen aus Arbeit etc. verwendet wird. Das ist schon etwas diffiziler zu fixen, wenn man weiterhin die IDs auswerten will, um daraus eine Zugvorlage zu erzeugen.

TagsKeine Tags zugeordnet.
Parteid08a
Spiel
Report858

Notizen / Dateien

Fiete

Fiete

2014-01-05 20:09

Reporter   ~0005102

Nebenwirkungen für Magellan sind deutlich spürbar: Magellan lädt dadurch ewig, weil er ständig diese WWs auswirft: (WW) 05.01.2014 19:55:03.858: unknown battle message type -1210990112 Weiterhin stürzt dabei das BattleAnalyzer-Plugin ab (nicht abschaltbar, OK, Magellan-Internika, aber sehr unschön). Gruß

Enno

Enno

2014-01-05 21:21

Administrator   ~0005103

Ich sehe einen Fehler: Die message-types sind unsigned int, aber der output ist mit %d. Und 0 sollte evtl. einfach nie ein gültiger typ sein.

Enno

Enno

2014-01-05 21:27

Administrator   ~0005104

Noch besser: mt_new initialisiert den hash nicht, und auch mt_register macht das nur, wenn ql_set_insert ein return value von 0 hat. Das hat sich aber in der Semantik geändert, und ist jetzt 'true'. Daran liegt's!

Enno

Enno

2014-01-05 21:51

Administrator   ~0005105

Bug ist gefixt.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2013-12-29 16:08 Thoran Neuer Eintrag
2014-01-05 20:09 Fiete Notiz hinzugefügt: 0005102
2014-01-05 21:21 Enno Notiz hinzugefügt: 0005103
2014-01-05 21:21 Enno Bearbeitung durch => Enno
2014-01-05 21:21 Enno Status neu => bestätigt
2014-01-05 21:27 Enno Notiz hinzugefügt: 0005104
2014-01-05 21:51 Enno Notiz hinzugefügt: 0005105
2014-01-05 21:51 Enno Status bestätigt => erledigt
2014-01-05 21:51 Enno Lösung offen => erledigt
2014-01-06 02:44 Enno Behoben in Version => 860
2014-02-20 09:54 Enno Status erledigt => geschlossen