Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002196EresseaLERNE/LEHREöffentlich2017-12-05 19:43
ReporterEnnoBearbeitung durchEnno 
PrioritätnormalSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status bestätigtLösungoffen 
Produktversion3.8.4 
ZielversionBehoben in Version 
Zusammenfassung0002196: Akademie: "race condition" in teach_cmd and study_cmd payment calculation
Beschreibung

In teach_cmd werden die Kosten des Lernens in der Akademie berechnet, und geschaut, ob die Zieleinheit genug Geld im Pool hat. Das wird für jede Einheit gemacht, aber da dort das Silber nicht verbraucht wird, können die in der Theorie alle das selbe Silber deklarieren (danke Pool). Verbraucht wird das Silber dann erst in study_cmd.

Da die Menge der Lerntage in teach_cmd gesetzt wird (teaching_info.value), ist es in study_cmd dann zu spät, um auf Geldmangel zu reagieren.

Schritte zur Reproduktion

Dafür einen Test zu schreiben, ist leider schwer, denn teach_cmd und study_cmd sind ziemlich uneinsichtig und miteinander durch die teaching_info Struktur verhakelt.

Zusätzliche Informationen

Es wäre gut, die einzelnen Schritte (lernen, lehren, bezahlen) besser zu ordnen. Die Bezahlung von Akademien schon in teach_cmd machen. Das Lernen des Akademie-Lehrers evtl. erst in study_cmd machen?

Die Repräsentation der Lern-Chance als double ist extrem blöd, weil intern immer noch technisch mit Lerntagen (Bruchteile von 30) gearbeitet wird.

learn_skill wird z.Z. mehrfach aufgerufen, wenn die Chance > 100% ist, das sollte evtl. einfach nach learn_skill intern verlegt werden, und so auch die Umrechnung von Tagen in Chancen.

Wir haben drei Mechanismen zur Inspektion:

  • random_source_inject_constant(0.0)
  • inject_learn(fun)
  • config_set("study.random_progress", "0")

Das sollte evtl. zuerst einmal auf einen einzigen Mechanismus reduziert werden (ein eigenes Modul fuer das logging von inject_learn ueber eine Art expect-Pattern koennte klappen).

Partei0
SpielE2
Report0

Notizen / Dateien

Zu diesem Eintrag gibt es keine Notizen.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2016-03-11 21:47 Enno Neuer Eintrag
2016-03-11 22:11 Enno Bearbeitung durch => Enno
2016-03-11 22:11 Enno Status neu => zugewiesen
2017-12-05 19:43 Enno Status zugewiesen => bestätigt