Simutrans 86.01

[prissi]

Diese Version hat nur eine große Änderung: Balancierte Passagierströme für Fabriken und Ausflugsziele. Das Level eines Ausflugsziel bezeichnet jetzt nur noch die Gewichtung bei den Passagieren, nicht mehr die absolute Zahl. Bei einer Fabrik ist es übrigens wie bei Waren: Es reicht, wenn die Arbeiter ein Feld erreichen können.

Fabriken wachsen jetzt nur noch bei einer Zunahme um 2^x * faktor Einwohner. Ist Faktor 2000, dann also bei 2000, 4000, 8000, 16000, ...

Durch die ganzen Optimierungen sollte der Aufwand bei der Passagiererzeugung und -verteilung nur noch halb so hoch sein. Und natürlich diverse Fehler gefixt.

Simuwin 86-01
Simulinux 86-01

Release of 86.01

19-Apr-2005 (prissi)
CHANGE: passenger to attraction/factory is equal to returning number; mail is 1/8 of returning. This comes for free and reduces the load considerably.
CHANGE: when a ware was added to a station, the route was calculated again in case of pax
CHANGE: passenger generation/routing cleaned up and reworked => much faster
FIX: now really closing all windows before loading
CHANGE: Building do not step anymore, if not neccessary => much faster
CHANGE: simloop/FPS system complete reworked to allow more time for other applications resp. a smoother scheduling all other times. But now no time strech <1.0 possible
CHANGE: factories are now built every 2^x*industry_increase_every

14-Apr-2005 (prissi)
FIX: no more adding cities after loading corrected; also now in priciple an unlimited number of cities should be possible (but something still breaks at 64 ... )
FIX/CHANGE: traffic to an attraction is now proportional to the level of this attraction
FIX: ships could only unload under the harbour ...
CHANGE: random now c instead of C++ => a little faster
CHANGE: line in fillbox a little higher
FIX: new GB citylist
FIX: CMOCxx cause pre PentiumPro to crash => exchanged

10-Apr-2005 (prissi)
CHANGE: trees have now also an distribution weight (default=3)
FIX: transportation revenue also calculated, when vehicle was stopped for new schedule
FIX: dirty_rect for vehicles was to small => traces were left!

[Gotthardlok]

Dann einmal Danke für das neue Release, wird natürlich wieder nach allen Regeln der Kunst auf Fehler überprüft

Es reicht, wenn die Arbeiter ein Feler erreichen können.

Müsste richtig wohl heissen:
Es reicht, wenn die Arbeiter ein Feld erreichen können.
(Ich musste doch eine Weile studieren, bis ich das enträtslen konnte)

[Gotthardlok]

Das mit dem Hafenumbau hat leider nicht so richtig geklappt:
Jetzt wird jeder Punkt im Einzugsbereich als Haltepunkt zum Beladen des Schiffs akzeptiert, aber zum Abladen nur das Feld, auf dem der Hafen selbst steht (man muss also wieder unter den Steg fahren).

[prissi]

Interessante Variante. Gibt es ein Boot, das unter dem Hafen hält, dann brauchen die anderen dort nicht zu halten.

EDIT:
Den Fehler habe ich. Nächster bitte.

[Gotthardlok]

Beim Stadtfenster: lässt man dies übers Jahresende offen, werden unten die Jahreszahlen nicht nachgerutscht (so als temporäre Beschäftigung).

[blackbox]

UNDO
Die Funktion ist nicht mehr möglich.


Deine neuesten Performance-Optimierungen rufen bei mir schon wieder Stirnrunzeln hervor. Meine CPU fährt jetzt ständig unter Dauervollast in ST, was vorher ja nur vereinzelt der Fall war. Dafür reagieren die Sim-loops anscheinend eher so wie ursprünglich mal gedacht.

Komisch ist nur, daß ich im 128er Sim-loops zwischen 30-35 durchschnittlich erreiche. Im 64er dagegen nur 10-20. <- Sollten die hier nicht wesentlich höher sein als im 128er? Vermutlich ein Zeichen dafür, daß sie wohl doch noch nicht so gut bei mir berechnet werden, wie ich zuerst vermutet habe. Oder was sagt der Fachmann?

Die Idle Zeiten spielen dafür bei mir jetzt komplett verrückt. Die konnte ich vorher immer noch als zuverlässigen Indikator nehmen, wann die CPU ordentlich zu tun hat. Alles unter 1200 brachte meine CPU ins Schwitzen, über 1200 hatte ich ca 30% Reserve. Jetzt habe ich hier ständig Werte, die zwischen 0 und 18000 (oder 33000) hin- und herspringen.

Jetzt ist die Frage, was ist besser: richtige(?) Anzeige der Sim-loops oder weniger CPU-Auslastung (Anzeige: Windows-Taskmanager)? Wie soll ich jetzt rausbekommen, wann ST mit dem Berechnen der ganzen Routinen nicht mehr nachkommt?

Gilt jetzt die Regel: Solange die Sim-loops bei mir nicht unter 2 fallen, ist alles in Ordnung?

[Dirk]

Danke für die neue Version! Komme schon gar nicht mehr hinterher mit dem Testen...

[prissi]

Simloops >=2 ist ok. Ansonsten kann das durchaus sehr Betriebssystemabhängig sein. Vorher hat Simutrans max. 2ms pausiert, d-h- unter XP gar nicht. Jetzt ist die Quantelung 10ms, damit auch mal wer anderes in Leerlaufphasen rankommt. Die Idle-Zeit ist eigentlich ohne Bedeutung.

[blackbox]

Prissi, würdest du bitte in ener der nächsten Versionen mit einbauen, daß in den Spielständen die Größe des SEBs mit abgespeichert wird. Sonst würde das in Zukunft viel zu viel Verwirrung stiften, wenn man z.B. fremde Spielstände lädt, aber mit einer völlig anderen Konfiguration diesbezüglich. Danke.

gruß
blackbox

P.S.: Gute Besserung!

[blackbox]

"Jetzt ist die Quantelung 10ms, damit auch mal wer anderes in Leerlaufphasen rankommt. Die Idle-Zeit ist eigentlich ohne Bedeutung."
Also bei mir (W2K) gibt's jetzt gar keine Leerlaufphasen mehr, zumindest laut Taskmanager. Darum wundere ich mich ja so. Oder ist es das, was du mit "Betriebssystemabhängig" meinst?