Deutsches Simutransforum

Siehe

ST: 88.08 Ist der Ruf erst ruiniert...

Simutrans-Version:
88.08.01 SDL
PAK-Set (+zusätzliche PAK-Dateien):
64er
Betriebssystem:
w2k3

Fehler (möglichst genaue Beschreibung):

Verhalten (Absturz, Einfrieren, ...):


Zusätzlich:
Ich habe ST (88.08 ) lange laufen lasse.
Dabei kam ich aus den roten Zahlen wie erwartet raus, aber aus den schwarzen 92...... wurden rote 92....

Es drehte sich also um.

Nach dem Beenden von ST fand ich noch eine "ST-Leiche" im Taskmanager.

Ähm ... sorry, ich bin blond,
aber was ist denn ST bzw. eine ST-Leiche ???

LG catfan

ich denk mal ST ist Simutrans und eine ST-Leiche ist eine Simutrans leiche sprich ein programm, dass net reagiert etc...

martin

Unter Windows dauerts manchmal etwas, bis ein Task/Programm kommplett beendet ist.

Zum Beispiel, wenn der Task/Programm auf Befehle des Betriebssystems nicht gleich reagiert oder reagieren (Absturz) kann.

Der Task kann auch noch von einem vorherigen Absturz stammen. Bei Verwendung des Ruhezustandes kann der Absturz auch schon bei Sitzungen davor gewesen sein.

Falls du in deinem Einnahmen 92233720368547758 cr. überschreitest, gibt es einen Überlauf und die Zahl wird negative. Das ist zwar ein Bug aber nicht wirklich zu ändern, das Fließkommazahlen zu ungenau für solche Rechnungen sind.

Das ist auch bei TransportTycoon von 1990 der Fall. Dort erfolgt der Überlauf bei 8,5 Millionen. Dann hat man 8,5 Millionen Minus und ist praktisch gescheitert. Hab dann immer mit Britischen Pfund gespielt, da Waren die Zahlenwerte nur 1/4 von DM.

Kann man das "überlaufen" nicht durch eine Funktion vorher abfangen?

Zum Beispiel wenn ich weiß das bei x von + in - gewechelst wird, das bei ( x - 1.000.000 ) der Kontostand um z.B. 100.000.000 vermindert wird.

Natürlich mit entprechender Meldung um neue Postings in Bugs und Probleme zu vermeiden.

Die dumme Frage muss schon lauten, wie du je auf diese Summe in einem normalen Spiel kommst. Das sind einfach irrwizige Dimensionen. Selbst wenn es dir gelänge, jeden Monat eine Milliarde zu verdienen, bräuchtest du noch 100000 Jahre für diese Summe.

Die kritische Summe sind 92 Billiarden credits. Diese Summe entspricht der zehnfachen Verschuldung aller Länder des Erdballs oder einer Billiarde Schnellzüge, da dürfte der Rechner vorher schlapp machen.

Daher vermute ich mal, dass diese Summe nur erreicht wird, wenn ein Programmfehler vorliegt oder mit manipulierten Pak-Dateien gespielt wird.

Schik mir doch dein Überlaufspiel mal an markus()pristovsk.de

Das ist ja richtig übel, dass die Datentypen nicht typsicher sind.

Das Ganze sieht in der Tat nach einem Überlauf aus, der,
nachdem man sein Konto überzogen hat, ausgelöst wird
und zudem noch anfängt zu oszilieren.

Das Oszilieren findet im Monatsrythmus zum jewiligen 1. statt.

Sobald der negative Betrag wieder ausgeglichen wurde,
sind die 92... negativ.
Anscheinend immer zu Null.

Beispiel:
-92.... + 20 000 = 0
oder
-20 000 + 92.... = 0

@sojo
Da eine Typsicherung einzubauen ist nicht ganz trivial.

Nehmen wir ein unsigned Byte als Beispiel. Der Zahlenraum geht von
0-255. Was passiert, wenn ich 255+1 rechne?
Natürlich sollte 256 als Ergebnis rauskommen. Das ist aber größer als 8 Bit
und das Ergebnis wird 0 sein (Überlauf). Verhält sich der Datentyp wie gerade beschrieben, so gilt er nicht als typsicher.
Erhält man dagegen als Ergebnis 255 + Fehlermeldung, so wird das als typsicher gewertet.

Jetzt rechne ich aber nicht immer mit + und - und müsste bei jeder Rechnung prüfen, ob ich die Rechnung
a = b + c oder a = b * c etc. überhaupt ausführen darf.

Eine Prüfung könnte für eine Addition dann vereinfacht so aussehen:

if (( 255 - b) > c )
a = b + c;
else
ERROR();

(vorausgesetzt, b ist gültig und hat z.B. selbst keinen Überlauf erfahren)

Ähnliches müsste dann natürlich auch für die anderen Rechenoperationen
erstellt werden.

Eine Simulation strotzt natürlich von Berechnungen und wenn jede Operation vorher abgeprüft werden, leidet die Performance
erheblich.

Natürlich gibt es auch Tricks;
unsigned int a;
unsigned BYTE b, c;

....
a = b + c;

Damit umgeht man einen Überlauf.

Oder, bei einer Rechnung m / n kann n = 0 werden. m / 0 = Problem
Trick: m / ( n + 1) ....

Prissi und seine Leute werden den Fehler schon finden.

Ich konnte blos bei normalen Spiele nie in die Nähe der Summe kommen, weswegen ein Savegame recht hilfreich wäre ...