 |
Habe ein paar Hinweise gesammelt: Einheit 329828, "Alchemist", in Gebäude 1153103, AaCademy LEHREN npwd 72hw jvhz o9en xa69 mix3 jtoo oaL1 abgr bvuh gm6h sk==SK_MAGIC und academy == 510 nach der while Schleife Die letzte Einheit, gm6h, ist eine 3-Personen Einheit, die LERNE MAGIE 600 als Befehl hat, aber natürlich keine Magie kann. Sie gehört der Partei Iarn-doriath (1483035). Beide Parteien haben FFL_CURSED gesetzt. |
|
|
Habe jetzt einen Test, der das reproduziert. |
|
|
Test zu schreiben, die die korrekte Funktion der Akademie prüfen, ist nicht so einfach. Ich will schon länger gerne learn_skill inijzieren können, weil man schwer inspizieren kann, ob das aufgerufen wurde, und das oft braucht. Warum ist das in unit.c? Ein Refactoring machen, und nach study.c verschieben? A propos refactoring: Der gesamte Akademie-Code könnte gut in ein eigenes Modul, der verkompliziert das Lesen von teach_cmd (und wahrscheinlich learn_cmd auch). |
|
|
Jetzt habe ich gerade LERNE/LEHRE kaputt gemacht, glaube ich. test_study_with_bad_teacher geht in meinem lokalen Code nicht mehr :-( |
|
|
Auch nach dem Refactoring ist das noch kaputt. Es triggert aber nur, wenn der Lehrer einen erfolgreichen Lernversuch hat, deshalb ist das Testen mit dem 967er Datenfile unzuverlässig. Hier muss ein richtiger Unit-Test geschrieben werden, der learn_skill inijziert und schaut, dass in der Situation nicht Magie gelernt wird. |
|
|
Es gabe einen (deaktivierten) Test, der hat aber die neue Injektion nicht benutzt, sondern das assert getriggert :-( Habe ich repariert, und einen Hack gemacht, der verhindert dass Akademie-Lehrer einen Skill lernen, den sie nicht gelehrt haben. |
|
|
Wird in Version 3.9 gefixt sein. Ich hoffe mal, dass der Bug nicht vorher schon zuschlägt. |
- anonym
