Eintragsdetails ansehen
ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
---|---|---|---|---|---|
0002196 | Eressea | LERNE/LEHRE | öffentlich | 2016-03-11 21:47 | 2020-09-16 20:31 |
Reporter | Enno | Bearbeitung durch | Enno | ||
Priorität | normal | Schweregrad | kleinerer Fehler | Reproduzierbar | nicht getestet |
Status | erledigt | Lösung | wird nicht behoben | ||
Produktversion | 3.8.4 | ||||
Behoben in Version | 3.26 | ||||
Zusammenfassung | 0002196: 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:
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). | ||||
Tags | Keine Tags zugeordnet. | ||||
Partei | 0 | ||||
Spiel | E2 | ||||
Report | 0 | ||||
Ä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 |
2020-09-16 20:31 | Enno | Status | bestätigt => erledigt |
2020-09-16 20:31 | Enno | Lösung | offen => wird nicht behoben |
2020-09-16 20:31 | Enno | Behoben in Version | => 3.26 |
2020-09-16 20:31 | Enno | Notiz hinzugefügt: 0009069 |