Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002080EresseaNACH/ROUTEöffentlich2017-03-02 08:15
ReporterK Bearbeitung durchEnno  
PrioritätnormalSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status geschlossenLösungerledigt 
Produktversion3.5 
Zielversion3.6Behoben in Version3.6 
Zusammenfassung0002080: Bewegung und ZERSTÖRE immernoch möglich
Beschreibung

Einheit 5nn9 konnte eine Burg zerstören und in der selben Runde weiter FOLGEN in die nächste Region.

Schritte zur Reproduktion

Befehle waren:

BETRETEN BURG nkzy
ZERSTÖREN
ATTACKIEREN ebzy
ATTACKIEREN krzo
ATTACKIEREN mf01
@FOLGE EINHEIT mLa5
LERNE Hiebwaffen
@GIB 0 ALLES
@RESERVIERE je 1 Schwert
@RESERVIERE je 1 Plattenpanzer
@RESERVIERE je 1 Schild
@RESERVIERE je 1 Pferd

Zusätzliche Informationen

Wollschaf (5nn9) zerstört Sturmfeste (nkzy).
Wollschaf (5nn9) reitet von Orkanhügel (3, -12) nach Eichenhöhlen (3, -13).

Parteiqy7x
SpielE3
Report295

Notizen / Dateien

CTD

CTD

2015-03-02 09:51

Entwickler   ~0005694

Ich denke es liegt am aufruf:

for (ord = u->orders; ord; ord = ord->next) {
keyword_t kwd = getkeyword(ord);
if (kwd == K_DESTROY) {
if (!destroyed) {
if (destroy_cmd(u, ord) != 0)
ord = NULL;
destroyed = true;
}
}

Und ein paar Flags müssen in destroy_cmd auch noch gesetzt werden (long oder...)

K

K

2015-05-16 21:39

Reporter   ~0005825

Zuletzt bearbeitet: 2015-05-16 21:40

2 Überarbeitungen anzeigen

Aktuelle Daten (AW 306):

Wollschaf (2efc) zerstört Grundmauern (mbky).
Wollschaf (2efc) verdient in Kilzot (0, 2) 10 Silber.

Enno

Enno

2015-07-02 11:40

Administrator   ~0005911

Neuer Test: test_dont_move_after_destroy
Fehler bestätigt, ist glaube ich easy (die Flags setzen).

Enno

Enno

2015-07-02 11:47

Administrator   ~0005912

Test geschrieben und Problem gelöst.
https://github.com/eressea/server/pull/242

K

K

2015-08-04 09:45

Reporter   ~0006004

Zuletzt bearbeitet: 2015-08-04 09:46

2 Überarbeitungen anzeigen

Wollschaf (d99w) in Pelfidopir (2, -3): 'ZERSTÖRE' - Die Einheit kann keine weiteren langen Befehle ausführen.
Wollschaf (d99w) zerstört Gerüst (8r22).
Wollschaf (d99w) in Pelfidopir (2, -3) produziert 3 Holz.

Runde 317

Es sind wohl immernoch lange Befehle möglich.

Enno

Enno

2015-08-04 09:51

Administrator   ~0006005

Also wirkt das trotz der Fehlermeldung? Seltsam.

Enno

Enno

2015-08-04 11:25

Administrator   ~0006006

Warum zum Teufel heissen denn hier alle Einheiten Wollschaf, und von verschiedenen Paerteien? Dazu ist das betroffene Schaf nicht mal Mitglied der Partei qy7x, von der der Bugreport ist, sondern scheinbar von ovis? Grrrmbl, das hat mich gerade ganz schön in die Irre geführt, aber ich glaube jetzt bin ich auf dem richtigen Weg.

Enno

Enno

2015-08-04 11:32

Administrator   ~0006007

Hmm. Fehler ist gefunden, glaube ich. Aber check_log_orders() meckert jetzt:

'ZERSTÖRE' - Die Einheit kann keine weiteren langen Befehle ausführen.

Das kennt die Befehlsreihenfolge nicht, sieht in den Befehlen ein MACHE und ein ZERSTÖRE, und meckert über das zweite (in der Reihenfolge der Befehle in der Email, was Mist ist). Das sollte da aber überhaupt nicht gemacht werden, sondern im jeweiligen Befehl. Hat sicher mit u->thisorder zu tun? Weitere Forschung ist notwendig...

Enno

Enno

2015-08-04 12:23

Administrator   ~0006008

Das erklärt das ursprüngliche Problem ein wenig besser, glaube ich. produce() schaut aut u->thisorder, welches der lange Befehl ist, der ohne Berücksichtigung auf die Befehlsreihenfolge gewählt wurde (MACHE, weil es der erste in der Email war). der Aufruf von destroy_cmd() wird durch iteration über u->orders gemacht, was eigentlich nur für kurze Befehle notwendig sein sollte.

Das Problem im Grunde ist also, das update_long_order() nicht tut, was man erwartet, nämlich den langen Befehl aus einer Auswahl von mehreren zu nehmen, der in der Befehlsreihenfolge als erster verarbeitet wird. Das zu tun, wäre auch schwierig. Deshalb kann man sich auf u->thisorder nicht verlassen, was aber eine eher grundlegende Annahme im gesamten Code ist. So ein Scheiss...

Enno

Enno

2015-08-04 16:16

Administrator   ~0006009

Neuer Versuch: destroy_cmd nur noch mit u->thisorder machen, und alles andere lassen, wie es war. Ergebnis:

Wollschaf (d99w) übergibt 3 Holz an die Bauern.
Wollschaf (d99w) in Pelfidopir (1,-1): 'ZERSTÖRE' - Die Einheit kann keine
weiteren langen Befehle ausführen.
Wollschaf (d99w) in Pelfidopir (1,-1) produziert 3 Holz.
Wollschaf (d99w) treibt in Pelfidopir (1,-1) Steuern in Höhe von 752 Silber
ein.

Sprich, sie produziert, aber zerstört nicht. Es gibt m.W. keine Garantie, dass eine Einheit mit mehreren langen Befehlen immer den in der Befehlsreihenfolge früheren macht. Wie der Code entscheidet, ist egal, so lange man als Spieler korrekte Befehle gibt, und nur ein langer Befehl pro Woche ausgeführt werden kann. Mit ein bisschen Code-Kosmetik kann ich das glaube ich einchecken.

K

K

2015-08-04 20:12

Reporter   ~0006010

Klingt gut, sofern es eine Fehlermeldung für den nicht ausgeführten Befehl gibt.

Zum Teil schien es ja schon funktioniert zu haben, inzwischen ein Beispiel entdeckt bei dem es funktionierte:
Wollschaf (s1mf) in Pedathirbis (1, -1): 'ARBEITE' - Die Einheit kann keine weiteren langen Befehle ausführen.
Wollschaf (s1mf) zerstört Grundmauern (yh7).

Partei ovis

Und tut mir leid mit den Namen und der Partei. Ich führe momentan beide wobei qy7x nur noch abgewickelt und demnächst aufgelöst wird. Das der 'neue' Report nicht von ihr war, hatte ich nicht beachtet.

Enno

Enno

2015-08-04 21:59

Administrator   ~0006011

Preisfrage, da wir hier bei neuem Code die Wahl haben. Wenn ich folgedne Befehle habe:

EINHEIT abc
ARBEITE
LERNE Segeln
BEWACHE

welchen langen Befehl sollten wir dann ausführen? LERNE, weil er in den Befehlen weiter unten steht? Oder ARBEITE, weil er Geld verdient? Oder doch LERNE, weil er in der Befehlsreihenfolge vor ARBEITE passiert?

Und wenn ja, was dann mit UNTERHALTE vs. ARBEITE, die ja quasi gleichzeitig passieren, und beide (möglicherweise) Silber produzieren?

Enno

Enno

2015-08-04 22:45

Administrator   ~0006012

In erster Näherung mache ich mal "der erste Befehl, den der Server sieht, ist der lange, den er benutzt". Resultat sieht jetzt so aus:

Wollschaf (d99w) in Pelfidopir (1,-1): 'ZERSTÖRE' - Die Einheit kann keine weiteren langen Befehle ausführen.
Wollschaf (d99w) in Pelfidopir (1,-1) produziert 3 Holz.
Wollschaf (d99w) übergibt 3 Holz an die Bauern.
Wollschaf (d99w) treibt in Pelfidopir (1,-1) Steuern in Höhe von 752 Silber ein.

Ich sollte die ganzen Edge-Cases noch einmal testen, dann bin ich fertig.

Enno

Enno

2015-08-05 11:05

Administrator   ~0006013

Im nächsten pre-release ist der bug behoben.
https://github.com/eressea/server/pull/262

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2015-03-01 09:22 K Neuer Eintrag
2015-03-02 09:51 CTD Notiz hinzugefügt: 0005694
2015-03-02 12:34 CTD Bearbeitung durch => CTD
2015-03-02 12:34 CTD Status neu => zugewiesen
2015-05-16 21:39 K Notiz hinzugefügt: 0005825
2015-05-16 21:40 K Notiz bearbeitet: 0005825 Überarbeitungen anzeigen
2015-07-02 11:40 Enno Notiz hinzugefügt: 0005911
2015-07-02 11:47 Enno Notiz hinzugefügt: 0005912
2015-07-02 11:47 Enno Status zugewiesen => erledigt
2015-07-02 11:47 Enno Behoben in Version => 3.6
2015-07-02 11:47 Enno Lösung offen => erledigt
2015-07-02 11:47 Enno Bearbeitung durch CTD => Enno
2015-07-03 18:34 Enno Zielversion => 3.6
2015-08-04 09:45 K Notiz hinzugefügt: 0006004
2015-08-04 09:45 K Status erledigt => Rückmeldung
2015-08-04 09:45 K Lösung erledigt => wiedereröffnet
2015-08-04 09:46 K Notiz bearbeitet: 0006004 Überarbeitungen anzeigen
2015-08-04 09:51 Enno Notiz hinzugefügt: 0006005
2015-08-04 09:52 Enno Status Rückmeldung => zugewiesen
2015-08-04 11:25 Enno Notiz hinzugefügt: 0006006
2015-08-04 11:32 Enno Notiz hinzugefügt: 0006007
2015-08-04 12:23 Enno Notiz hinzugefügt: 0006008
2015-08-04 16:16 Enno Notiz hinzugefügt: 0006009
2015-08-04 16:18 Enno Produktversion => 3.5
2015-08-04 20:12 K Notiz hinzugefügt: 0006010
2015-08-04 21:59 Enno Notiz hinzugefügt: 0006011
2015-08-04 22:45 Enno Notiz hinzugefügt: 0006012
2015-08-05 11:05 Enno Notiz hinzugefügt: 0006013
2015-08-05 11:05 Enno Status zugewiesen => erledigt
2015-08-05 11:05 Enno Lösung wiedereröffnet => erledigt
2017-03-02 08:15 Enno Status erledigt => geschlossen