Sudden death -Stillstand

» Settlers Map Source Forums » Mapdiskussionen - Mapdiscussions » Sudden death -Stillstand

Pages: 1

fighty
#1
13-01-2015 18:03
Posts: 3296

Sudden death -Stillstand

Beim 2. Maptest habe ich auf einer beim 1.Mal funktionierenden Map folgendes Problem:
Nach erfolgtem Aufbau kommt mein Angriff. Ich erobere Türme des Gegners aber wenn ich abreißen will bleibt das Spiel schlagartig stehen. Der CPU-Core für S3 geht auf volle Leistung und der S3-Thread ist gestorben. Abbruch geht nur über den Taskmanager.
Das ist ein äußerst ärgerlicher Bug. Weshalb triggert Turmabriss so einen Fehler?

Sascha
#2
14-01-2015 00:22
Posts: 574

Ein einziges mal ist mir dieser Bug bisher aufgefallen.
Bei einer PerSaldo-Map blieb die Map nach einer gewissen Spielzeit (ca. 1 Stunde) einfach stehen. Nichts ging mehr. Auch das war kurz nach einem Kampf, jedoch nicht unmittelbar nach dem Turmabriss.
Erst nach einem Neustart der Map konnte ich die Map beenden!

Den Grund weiß ich leider nicht dafür!

Play4FuN
#3
03-02-2015 09:07
Posts: 488

Die map schmierte aus nicht erkennenbarem Grund ab, obwohl im Skript kein Fehler an dieser Stelle zu finden ist!? Das gleiche ist mir auch schon passiert, der Absturz erfolgte immer nach der selben Spielzeit. Eine Lösung habe ich leider auch nicht gefunden :/

____________________
LG Play4FuN

merkel
Moderator Siedler 3/Siedler 4
#4
03-02-2015 10:12
Posts: 2324

Versuch Problembeschreibung

Auch ich habe solche Zustände schon erlebt und dann mal nachgeschaut, was da im Hintergrund abgeht. Fast immer ist es ein Problem mit dem Stack (= ein Speicherbereich, wo Zwischenergebnisse gestapelt zur Weiterverwendung abgelegt werden).
Erläuterung: Jede CPU kann zum Rechnen nur 2 Register verwenden. Beispiel: 3*(1+2)*(3+4)=? Wegen der Regel Punkt vor Strich muss erst der Klammerinhalt gerechnet werden. Also 1 in Register 1 und 2 in Register 2 - Addition - Ergebnis liegt normal in Register 1.
Multiplikation mit 3 - Register 1 hat den 1. Wert schon, in Register 2 wird 3 geladen - Multiplikation - Ergebnis kommt in Register 1.
Bis hierher alles normal.
Für die 2. Klammer (3+4) müssen Register 1 und 2 neue Werte bekommen, das aktuelle Zwischenergebnis ist im Weg und wird in den Stack geschoben zur späteren Verwendung.

Nach Berechnung von Klammer 2 wird der Stack in das freie Register geholt und das Endergebnis berechnet.
Beim Stack gilt üblich "last in - first out"; also neue Werte werden oben drauf gestapelt und von dort auch wieder abgeholt.

Der Stack hat eine bestimmte Länge, die nicht überschritten werden darf. Die CPU muss penibel aufpassen, dass die Reihenfolge nicht durcheinander kommt. Bleibt z.B. bei einer komplexen Verschachtelung ein Wert im Stack übrig, wird der Stack nach vielen Rechnungsschitten zu gross (er läuft über) ==> Stacküberlauf-Error.

Gleichzeitig wird ja ein falscher Wert vom Stack geholt. Es können so weitere Fehler passieren. Beispiel: ursprünglich soll 2*10 gerechnet werden, es wird aber ein unzutreffender Stackwert von 100000 geholt, also 2*100000 gerechnet. Dann kann das Ergebnis zu gross für das Register werden (Register-Überlauf oder "Carry-Bit" gesetzt); als Folge sind zusätzliche Berechnungen nötig, die wieder den Stack benutzen. Dann entsteht Chaos.

Die CPU meldet dann Stacküberlauf, das Betriebssystem reagiert und sperrt weiteres Zwischenspeichern auf den Stack - nichts geht mehr. Der Threat oder Prozess wird gestoppt, damit das Betriebssystem nicht auch noch "überläuft" und abstürzt.

Unter DOS stürzte der Rechner komplett ab, weil DOS nur 1 Threat hatte bzw. bearbeiten konnte.

Offenbar nutzt S3 mehrere Stacks für verschiedene Belange. Z.B die max. Siedlerzahl. Mappt man sehr viele Träger ohne Sprenkeln, "freezed" der PC. Warum? Die Träger sollen sich Platz verschaffen, können aber nicht, weil der Nachbarplatz noch besetzt ist. Platz gibt es nur für die randlichen Träger, und nur langsam bessert sich die Lage - solange herrscht Freeze!

S3 hat für solche Probleme Routinen eingebaut, damit es weiter laufen kann. Ein Beispiel: 2 Holzfäller wollen den gleichen Baum fällen. Das wird gelöst, indem der 1 Holzfäller einen Balken produziert, der zweite dann hinläuft, keinen Baum mehr sieht und ohne Balken zurückläuft. Gleiches gilt für Steinis und Farmer, aber auch für Diebe oder Träger, die Waren abstellen. Der Stack bleibt in Ordnung.

Beim Holzfäller kann man das gut beobachten. Neue Bauplätze werden plötzlich angezeigt, wenn der Holzfäller seinen Balken ein Stück weit weggetragen hat.

Beim Waldbrand haben die S3-Programmierer einen Trick verwendet: auf verbrannter Erde gibt es keine Bauplätze. Das haben sie wohl gemacht, weil sonst zu viele neue Bauplätze gleichzeitig frei werden würden und man das per Stack nicht in den Griff bekommen kann. "Gleichzeitig" gibt es in der CPU nicht, sondern nur nacheinander oder Schritt für Schritt.

Nach einem Save wird wohl ein komplettes Abbild vom aktuellen Map-Zustand gespeichert. Stacks werden neu angelegt, als Ausgangspunkt dafür wird der Save-Zustand genommen. Ursprünglich defekte Stacks können so repariert werden, das Spiel läuft ohne die Probleme vor dem Abspeichern ganz normal weiter.

fighty
#5
23-02-2015 23:45
Posts: 3296

Zum Mäuse melken!!!
Jetzt habe ich den Sudden Death schon wieder. Die Map lief ursprünglich. Dann habe ich an etlichen Stellen nachgebessert - nur kleine Änderungen. Nach ca. 2 Std Spielzeit: Freeze
Mir schwant so etwas wie "Gebäudeüberlauf". Einmal trat der Freeze jedesmal auf sobald ich eine 2. Fischerhütte baute. Fast egal wo.

Dann habe ich die Karte komplett neubevölkert. Wieder Freeze.
Hatte Merkel da nicht mal mit dem Process Monitor die Subroutinen von S3 belauscht ?

fighty
#6
26-02-2015 21:28
Posts: 3296

Lösung gefunden !!!!

Beschriebene Map habe ich nun in 4 Versionen. Davon ist die Letzte komplett NEU d.h. mit leerem - nur Meer - Inhalt begonnen.
Und jedesmal nach ca. 2 Std. sudden death.
Da die 1. Version ja lief habe ich nochmal verglichen.
Die 2.,3.,4. Version der Map hat eine LV im Sumpf der nur 1Pixel breit ist. Am Anschluss zum Meer ebenfalls nur 1 Pixel breit.
Ich habe in einem Pixel Abstand zum Meer hin nun eine 2. Absperrung eingezogen. In diesem Design 4 mal also eine Absperrung zum Meer verdoppelt. Jetzt läuft alles tadellos.

Conclusio:
Ist eine Absperrung zum Meer hin mit hauchdünnem Sumpfring (1 Pixel) ebenfalls nur 1 Pixel scheint S3 irgendwann für die feindlichen Solis doch einen Weg zu suchen. Diese Suche ist endlos d.h. das Spiel hängt!

Pages: 1

SiteEngine v1.5.0 by nevermind, ©2005-2007
Design by SpiderFive (www.siedler-games.de) - English translation by juja

Impressum