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...)

Aktuelle Daten (AW 306):

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

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

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

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.

Also wirkt das trotz der Fehlermeldung? Seltsam.

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.

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...

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...

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.

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.

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?

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.

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