Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002456EresseaBEWACHEöffentlich2018-08-19 13:40
ReporterEONBearbeitung durchEnno 
PrioritätniedrigAuswirkungkleinerer FehlerReproduzierbarnicht getestet
Status erledigtLösungkeine Änderung notwendig 
Produktversion 
ZielversionBehoben in Version 
Zusammenfassung0002456: Reiter wird von bewachender Einheit (Monster) aufgehalten, die die Region verlässt
Beschreibung

Diese Woche wurde eine meiner Einheiten die sich eigentlich zwei Regionen bewegen sollte von Monstern aufgehalten, die die mittlere Region bewacht haben. Das wäre an sich normal, wenn die Monster nicht diese Woche in eine andere Region gezogen wären - ich bin mir nicht sicher, ob das so sein sollte.

  • Einheit Steintransport (5h7v) kann reiten und hat Pferde, ist nicht überlastet
  • Regionen: Glutstein (Lh6er5) - Hagelsturm (6t1m4c) - Tivun (L8t1mL)

Meldungen:
Steintransport (5h7v) reitet von Glutstein nach Hagelsturm
Steintransport (5h7v) wurde in Hagelsturm von Fürchterliche Kreaturen (bm67) aufgehalten.
Regionsmeldung:
Durchreise: Fürchterliche Kreaturen (bm67)

ParteigLod
SpielE2
Report1083

Notizen / Dateien

Xolgrim

Xolgrim

2018-07-02 21:30

Entwickler   ~0007939

Zuletzt bearbeitet: 2018-07-02 21:31

2 Überarbeitungen anzeigen

Wenn ich mir die Befehlsreihenfolge so anschaue, gehe ich schwer davon aus, dass das so gewollt ist.
BEWACHE NICHT (3) also wenn ich bewache selber aufheben will
NACH (29)
BEWACHE AN (30)

Bewache nicht erfolg also seh früh, das lässt vermuten, dass es für die darauf folgenden Befehle relevanz hat. NACH erfolgt unmittelbar vor dem neuen Bewache (was man jedoch nur setzen kann, wenn man sich nicht bewegt hat, sont würe man die betretene Region ja sofort bewachen)

EON

EON

2018-07-02 21:43

Reporter   ~0007940

Die Frage die sich mir stellt ist, wann BEWACHE aufgrund von NACH gelöscht wird. Schließlich passiert mein NACH bzw. ROUTE theoretisch gleichzeitig mit dem NACH der Monster, technisch gesehen muss aber natürlich eines vor dem anderen ausgewertet werden.
Wenn das BEWACHE NICHT im Rahmen von NACH ausgeführt wird, dann hängt es davon ab, welche Einheit zuerst ausgewertet wird.
Wenn sich NACH in zwei Phasen teilt (erst alle Einheiten bewegen, dann das BEWACHE aller bewegten Einheiten löschen) bin ich zufrieden. Das wäre vermutlich sogar die beste Variante, da Einheiten, die sich wegen Überlast etc. nicht bewegen könnten dann weiter bewachen.
Erst Bewache löschen wäre für mich auch in Ordnung, ist hier aber offensichtlich nicht passiert.
Wichtig ist mir eigentlich nur, dass es deterministisch ist ;-)

Xolgrim

Xolgrim

2018-07-03 20:07

Entwickler   ~0007941

Das Bewache wird vermutlich einfach gar nicht gelöscht, sofern man nicht bewache nicht oder kämpfe flieh beflieht, die Einheit entwaffnet oder sterben lässt. Am Anfang der nächsten Runde ist eine einheit die NACH befohlen hat nicht mehr in der Region, bewacht dort also nicht. In der Nachbarragion bewacht sie nicht, da bewache und bewegen sich ausschliesst. Also im endeffekt "bauglich" mit deiner Variante 2.

Enno

Enno

2018-08-19 12:16

Administrator   ~0008035

Ich bin mir fast sicher, dass das von der Reihenfolge in der Region abhängt. Wenn das NACH deiner Einheit bearbeitet wird, ehe dass das NACH des Monsters ausgeführt wurde (weil das Monster weiter "unten" in der Region steht, dann bewacht es halt noch. Das kann man nicht einfach ändern, und halte ich auch nicht für dringend nötig.

Vermute ich das richtig? Habe ich deine Beschreibung verstanden?

EON

EON

2018-08-19 12:31

Reporter   ~0008037

Fast. Meine Einheit war ja nicht in der selben Region wie die bewachenden Monster, also standen die Monster nicht weiter unten in der selben Region, sondern die Region in der die Monster standen kam später dran, vermute ich. Ein großes Problem ist das nicht, es war nur überraschend für mich, da mein Transporter nicht dort ankam wo er sollte.

Enno

Enno

2018-08-19 13:40

Administrator   ~0008038

Hier liegt kein Fehler vor, das ist einfach ein Artefakt der Befehlsverarbeitung im Server. Davon gibt es einige, und solange man das nicht als Exploit ausnutzen kann, sehe ich keinen Bedarf, daran etwas zu ändern.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2018-07-02 21:16 EON Neuer Eintrag
2018-07-02 21:30 Xolgrim Notiz hinzugefügt: 0007939
2018-07-02 21:31 Xolgrim Notiz bearbeitet: 0007939 Überarbeitungen anzeigen
2018-07-02 21:43 EON Notiz hinzugefügt: 0007940
2018-07-03 20:07 Xolgrim Notiz hinzugefügt: 0007941
2018-08-19 12:16 Enno Notiz hinzugefügt: 0008035
2018-08-19 12:31 EON Notiz hinzugefügt: 0008037
2018-08-19 13:40 Enno Bearbeitung durch => Enno
2018-08-19 13:40 Enno Status neu => erledigt
2018-08-19 13:40 Enno Lösung offen => keine Änderung notwendig
2018-08-19 13:40 Enno Notiz hinzugefügt: 0008038