Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002327EresseaZAUBERöffentlich2017-07-10 09:39
ReporterKBearbeitung durchEnno 
PrioritätnormalAuswirkungkleinerer FehlerReproduzierbarnicht getestet
Status erledigtLösungwird nicht behoben 
Produktversion3.12.1 
Zielversion3.13Behoben in Version 
Zusammenfassung0002327: Wiedersprüchliche Fehlermeldungen
Beschreibung

Ich erhielt wiedersprüchliche Fehlermeldungen, der Magier hat ein Schiff verlassen und (erfolglos) eine Burg versucht zu betreten während des Zauberns.
Region ist feindlich bewacht.

Schritte zur Reproduktion

Nadelkrieger (cpj3) in Sogapisun (16, -40): 'ZAUBERE REGION 17 40 STUFE 1 Bergwächter' - Die Einheit kann keine weiteren langen Befehle ausführen.
Nadelkrieger (cpj3) in Sogapisun (16, -40): 'ZAUBERE REGION 17 40 STUFE 1 Bergwächter' - Der Zauber schlägt fehl.

Parteiovis
SpielE3
Report408

Notizen / Dateien

Enno

Enno

2017-06-18 14:52

Administrator   ~0007266

Die Einheit hat einen LERNE Hiebwaffen Befehl und den ZAUBERE, insofern stimmt der erste Fehler schon, aber "Der Zauber schlägt fehl" sollte dann natürlich nicht kommen.

Das heißt, nein: Ich glaube, da wird die Reihenfolge der Befehle nicht beachtet, und der LERNE-Befehl ist es, der nicht ausgeführt wird. ZAUBERE kommt vor LERNE in der Reihenfolge, und wird ausgeführt. Dass der Zauber fehlschlägt, liegt sicher an etwas anderem.

Enno

Enno

2017-06-18 14:52

Administrator   ~0007267

Genau. Man kann keine Bergwächter in einem Vulkan zaubern.

Enno

Enno

2017-06-18 16:35

Administrator   ~0007268

Note to self: Zum Debuggen reproduziert man das mit einem breakpoint in cmistake, condition u->no==592959

Enno

Enno

2017-07-09 15:55

Administrator   ~0007334

Ausser dem Problem mit der Reihenfolge (und dass der falsche Befehl angemeckert wird), gibt es hier wirklich einen Bug? Dass ein Zauber fehl schlägt, kommt ja mal vor.

K

K

2017-07-09 16:14

Reporter   ~0007335

Mir ging es nur um die beiden Fehlermeldungen. Entweder konnte ich nicht zaubern oder der Zauber schlägt fehl, also hab ich gezaubert.

Xolgrim

Xolgrim

2017-07-10 08:51

Entwickler   ~0007338

@K: Das liegt an der sehr... gewöhnungsbedürftigen Art wie Eressea die Befehle verarbeitet. Alle befehle die Du einsendest werden komplett eingelesen und dann im ersten Schritt auf Fehler geprüft, für die eine Fehlermeldung ausgegeben wird. Ob der Befehl später geändert oder überschrieben wird ist dem Server egal (nicht für die Verarbeitung, aber für die ausgegebene Fehlermeldung).
Wenn Du einer Einheit also Beispielsweide den Befehl gibst "RNach NO NO" Weils erst ne Route werden sollte und dann doch nach geworden ist, so wird dies von echeck bemängelt, da es keine Ahnung hat was RNach denn für ein Befehl ist. Änderst Du dies dann, findet echeck keinen Fehler mehr, die Einheit wird Nach NO NO laufen wie sie es soll, om Report steht jedoch trotzdem die Fehlermeldung. Das ist ganz sicher kein wirklich gelungenes Konzept. Da man jedoch auch Teilbefehle einsenden kann, kann der Server halt dei alten Befehle nicht einfach komplett überschreiben. Dieses komische Verhalten ist der Preis dafür.

@Enno: Kein Bug, es sei denn du willst und kannst die Befehlsverarbeitung des Servers ändern.

Enno

Enno

2017-07-10 09:38

Administrator   ~0007339

Obwohl Xolgrim das richtig beschreibt, geht es hier um ein etwas anderes Problem, das auch auftritt, wenn man nur einmal Befehle eingeschickt hat. Wenn Deine Einheit zwei lange Befehle bekommen hat, dann wird der Server über einen davon meckern, ohne dass garantiert ist, dass es der ist, der bei der Auswertung "verliert", weil er erst als zweiter ausgeführt wird.

Beim Lesen schon zu wissen, welcher Befehl gewinnen wird, geht leider nicht. Und Befehle wie FOLGE und ATTACKIERE, die nur unter bestimmten Umständen lange Befehle sind, machen das alles noch schwieriger. Ganz zu schweigen von Befehlen, die man mehrfach pro Runde ausführen darf (ZAUBERE, VERKAUFE). Deshalb lasse ich hier mal die Finger davon, so verwirrend ist die Meldung auch wieder nicht.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2017-05-21 01:52 K Neuer Eintrag
2017-06-18 14:52 Enno Notiz hinzugefügt: 0007266
2017-06-18 14:52 Enno Bearbeitung durch => Enno
2017-06-18 14:52 Enno Status neu => zugewiesen
2017-06-18 14:52 Enno Notiz hinzugefügt: 0007267
2017-06-18 15:03 Enno Produktversion => 3.12.1
2017-06-18 15:03 Enno Zielversion => 3.13
2017-06-18 16:35 Enno Notiz hinzugefügt: 0007268
2017-07-09 15:55 Enno Notiz hinzugefügt: 0007334
2017-07-09 16:14 K Notiz hinzugefügt: 0007335
2017-07-10 08:51 Xolgrim Notiz hinzugefügt: 0007338
2017-07-10 09:38 Enno Notiz hinzugefügt: 0007339
2017-07-10 09:39 Enno Status zugewiesen => erledigt
2017-07-10 09:39 Enno Lösung offen => wird nicht behoben