Eintragsdetails ansehen
ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
---|---|---|---|---|---|
0002706 | Eressea | Schiffe | öffentlich | 2020-09-21 21:32 | 2022-01-31 21:50 |
Reporter | EON | Bearbeitung durch | Enno | ||
Priorität | normal | Schweregrad | kleinerer Fehler | Reproduzierbar | nicht getestet |
Status | erledigt | Lösung | erledigt | ||
Behoben in Version | 3.26 | ||||
Zusammenfassung | 0002706: Schiff treibt trotz Leuchturm ab | ||||
Beschreibung | Karavelle w7b0 (w7b0) ist diese Woche abgetrieben "Die Karavelle w7b0 (w7b0) wird in Ozean (-17, -8) von Stürmen abgetrieben." Allerdings hätte das nicht passieren sollen - in "Auch noch nah" (-18, -6) (i7eanu) steht "Alter, verlassener Leuchtturm" (avLt), ein Leuchtturm Größe 10, von dem aus dieses Ozeanfeld gesehen werden kann. Betroffene Einheiten: Zwalrik (f7mb) und Zwalrik (hxp6) | ||||
Tags | Keine Tags zugeordnet. | ||||
Partei | gLod | ||||
Spiel | E2 | ||||
Report | 1187 | ||||
Ich kann bestätigen, dass da ein Problem ist. Eigentlich zwei: update_lighthouse sollte einmal für alle Leuchttürme aufgerufen werden und außerdem wird abtreiben nur durch NACH ausgelöst, nicht bei Route. Ich hatte echt schon lange kein Abtreiben mehr, wenn ich drüber nachdenke. Patchvorschlag:
|
|
Das mit dem |
|
Oh nein. Die commit message (von 2016) sagt:
Da ist ROUTE wohl wirklich nur vergessen worden. |
|
Aha! Kommentar für update_lighthouse sagt: "call this function whenever the size of a lighthouse changes". Entsprechend wird es zum ersten Mal aufgerufen, wenn der Leuchtturm aus dem Datenfile gelesen wird, in read_regions ganz am Schluß ist eine Schleife genau wie die, die du in deinem Patch hast. Haken an der Sache: Das update benutzt lighthouse_range, und das ist 0, weil zu diesem Zeitpunkt der Unterhalt für den Leuchttum noch nicht gezahlt wurde. Ouch. Richtig wäre wohl, die Regionsmarkierungen für "kann von Leuchtturm bewacht sein" so zu setzen, als sei das Gebäude bezahlt, und dann erst wenn sie gbraucht werden (beim Abtreiben-Check) zu schauen, ob der Turm auch unterhalten wurde. |
|
Schau mal, wie ich das gelöst habe: |
|
Wie Solthar auf github sagt: Der Code ist viel zu kompliziert, dafür dass der Schutz quasi nur für Bewegung berechnet werden muss. Es ist einfach, das Update zu vergessen, wenn der LT seine Größe ändert, es muss ein eigenes Attribut dafür implementiert werde, das dann auch noch allen Code verlangsamt, der die Liste der Regionsattribute scannt, usw. Es wäre einfacher, wenn die Sache lokal innerhalb von movement bleibt. Ich gucke mal, dass ich das reduziert kriege. |
|
Ganz stimmt das aber auch wieder nicht. Es gibt zwei Stellen im Code.
Beides wird derzeit zusammen von update_lighhouse gesetzt. |
|
Kann sich nach der Bewegung die Größe des Leuchtturms noch ändern?Soweit ich sehe nicht, es könnte maximal evtl. jemand die Region und damit den Leuchtturm verlassen, so dass er unbesetzt ist, wenn der Report geschrieben wird, aber die Reichweite muss dort ja eh neu berechnet werden. |
|
Aber: Es kann sein, dass ein Skript Reporte generiert, ohne vorher die Bewegung ausgeführt zu haben. Wenn dann die Leuchttürme nicht initialisiert sind, haben sie keine Wirkung im Report. Sie sollten dann aber auch nicht bezahlt sein, wie kann das also je funktioniert haben? Update: Der Test setzt den Leuchtturm auf "ist bezahlt worden", aber das macht natürlich für ein Skript, das nur Reporte schreibt, keinen Unterschied. So ein Skript funktioniert nicht, Punkt. |
|
Was man machen könnte: Statt an einem Gebäude ein "ist bezahlt worden" Flag zu haben, das jede Woche gesetzt werden muss, ein umgekehrtes "ist nicht bezahlt worden" Flag, das gesetzt wird, wenn der Unterhalt berechnet und nicht bezahlt worden ist. Dann sind alle Gebäude aktiv by default (statt wie bisher inaktiv), was ja hier auch das ursprüngliche Problem verursacht hat, wo update_lighthouse auf einem Gebäude aufgerufen wurde, ehe die Bezahlungen verarbeitet wurden. Klingt mir insgesamt stabiler, und erleichtert das Schreiben von Gebäude-Tests, wo ich schon oft vergessen habe, dass die nicht funktioinieren, wenn man nicht explizit b.working = true schreibt. |
|
Das ging halbwegs schmerzlos, ist aber ein ziemlicher Eingriff (weil Gebäudeunterhalt ja noch alle anderen Gebäude betrifft). Besser eine Weile lang testen, bis zum nächsten Release ist es ja zum Glück noch lange hin. |
|
Damit reicht es jetzt aber auch. |
|
Änderungsdatum | Benutzername | Feld | Änderung |
---|---|---|---|
2020-09-21 21:32 | EON | Neuer Eintrag | |
2020-09-21 23:03 | Enno | Bearbeitung durch | => Enno |
2020-09-21 23:03 | Enno | Status | neu => zugewiesen |
2020-09-22 01:23 | Solthar | Notiz hinzugefügt: 0009077 | |
2020-09-22 01:24 | Solthar | Notiz bearbeitet: 0009077 | |
2020-09-24 19:34 | Enno | Notiz hinzugefügt: 0009078 | |
2020-09-24 19:36 | Enno | Notiz hinzugefügt: 0009079 | |
2020-09-24 19:43 | Enno | Notiz hinzugefügt: 0009080 | |
2020-09-24 20:14 | Enno | Notiz hinzugefügt: 0009081 | |
2020-09-25 18:13 | Enno | Status | zugewiesen => erledigt |
2020-09-25 18:13 | Enno | Lösung | offen => erledigt |
2020-09-25 18:13 | Enno | Behoben in Version | => 3.26 |
2020-09-26 15:05 | Enno | Status | erledigt => Rückmeldung |
2020-09-26 15:05 | Enno | Lösung | erledigt => wiedereröffnet |
2020-09-26 15:05 | Enno | Notiz hinzugefügt: 0009083 | |
2020-09-26 17:43 | Enno | Notiz hinzugefügt: 0009084 | |
2020-09-26 17:46 | Enno | Notiz hinzugefügt: 0009085 | |
2020-09-26 18:01 | Enno | Notiz hinzugefügt: 0009086 | |
2020-09-26 18:03 | Enno | Notiz bearbeitet: 0009086 | |
2020-09-26 18:03 | Enno | Notiz bearbeitet: 0009086 | |
2020-09-26 18:22 | Enno | Notiz hinzugefügt: 0009087 | |
2020-09-27 15:53 | Enno | Notiz hinzugefügt: 0009088 | |
2020-09-27 15:54 | Enno | Status | Rückmeldung => erledigt |
2020-09-27 15:54 | Enno | Lösung | wiedereröffnet => erledigt |
2020-09-27 15:54 | Enno | Notiz hinzugefügt: 0009089 | |
2022-01-31 21:50 | Enno | Beziehung hinzugefügt | verwandt mit 0002802 |