Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002706EresseaSchiffeöffentlich2020-09-27 15:54
ReporterEON Bearbeitung durchEnno  
PrioritätnormalSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status erledigtLösungerledigt 
Behoben in Version3.26 
Zusammenfassung0002706: 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)

ParteigLod
SpielE2
Report1187

Notizen / Dateien

Solthar

Solthar

2020-09-22 01:23

Entwickler   ~0009077

Zuletzt bearbeitet: 2020-09-22 01:24

2 Überarbeitungen anzeigen

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:
<code>
diff --git a/src/move.c b/src/move.c
index a9f0095bf..b5f0898fb 100644
--- a/src/move.c
+++ b/src/move.c
@@ -2192,7 +2192,7 @@ void move_cmd_ex(unit u, order ord, const char *directions)
init_order(ord, u->faction->locale);
}
if (u->ship && u == ship_owner(u->ship)) {

  • bool drifting = (getkeyword(ord) == K_MOVE);
  • bool drifting = (getkeyword(ord) == K_MOVE) || (getkeyword(ord) == K_ROUTE);
    sail(u, ord, drifting);
    }
    else {
    @@ -2408,6 +2408,16 @@ static void move_pirates(void)
    void movement(void)
    {
    int ships;
  • region *r;
  • building *b;
  • for (r = regions; r!=NULL; r = r->next){
  • for (b = r->buildings; b; b = b->next) {
  • if (is_lighthouse(b->type)) {
  • update_lighthouse(b);
  • }
  • }
  • }

    / Initialize the additional encumbrance by transported units /
    init_transportation();
    @@ -2417,7 +2427,7 @@ void movement(void)

    • in the same turn.
      */
      for (ships = 0; ships <= 1; ++ships) {
  • region *r = regions;
  • r = regions;
    while (r != NULL) {
    </code>
Enno

Enno

2020-09-24 19:34

Administrator   ~0009078

Das mit dem bool drifting sieht mir ja irgendwie verdammt nach Absicht aus. Warum sollte man den Check sonst machen? move_cmd (und damit move_cmd_ex) wird ja eh nur mit Bewegungsbefehlen aufgerufen. Da hat sich jemand etwas dabei gedacht, und ich weiß nicht, was.

Enno

Enno

2020-09-24 19:36

Administrator   ~0009079

Oh nein. Die commit message (von 2016) sagt:

Feature: ships that FOLLOW or use PIRACY are not affected by storms.

Da ist ROUTE wohl wirklich nur vergessen worden.

Enno

Enno

2020-09-24 19:43

Administrator   ~0009080

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.

Enno

Enno

2020-09-24 20:14

Administrator   ~0009081

Schau mal, wie ich das gelöst habe:

https://github.com/eressea/server/pull/923

Enno

Enno

2020-09-26 15:05

Administrator   ~0009083

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.

Enno

Enno

2020-09-26 17:43

Administrator   ~0009084

Ganz stimmt das aber auch wieder nicht. Es gibt zwei Stellen im Code.

  1. Die lighthouse_guarded Funktion wird nur für die Bewegung benutzt, und benutzt das at_lighthouse Attribut.
  2. Im Report wird das RF_LIGHTHOUSE Flag benutzt, um bei Bedarf für umliegende Regionen eine Leuchtturm-spezifische Reportansicht zu erzeugen.

Beides wird derzeit zusammen von update_lighhouse gesetzt.

Enno

Enno

2020-09-26 17:46

Administrator   ~0009085

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.

Enno

Enno

2020-09-26 18:01

Administrator   ~0009086

Zuletzt bearbeitet: 2020-09-26 18:03

3 Überarbeitungen anzeigen

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.

Enno

Enno

2020-09-26 18:22

Administrator   ~0009087

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.

Enno

Enno

2020-09-27 15:53

Administrator   ~0009088

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.

Enno

Enno

2020-09-27 15:54

Administrator   ~0009089

Damit reicht es jetzt aber auch.

Eintrags-Historie

Ä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 Überarbeitungen anzeigen
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 Überarbeitungen anzeigen
2020-09-26 18:03 Enno Notiz bearbeitet: 0009086 Überarbeitungen anzeigen
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