Zeitlauf

[Uranor]

Jetzt habe ich den Zeitlauf geändert, obwohl ich wissentlich gar nichts verstellt habe. Nach dem Wiki zur simuconf.tab scheint das gar nicht möglich zu sein. Meine Hoffnung auf die Suche.... naa, negativ, sowas komisches fabriziere nur ich. 8o

T = 1.0, das ist unverändert. ( ',' und '.' nutze ich bei Bedarf).

Vorher waren die Minuten noch erkennbar gerast. So gehen die Jahre etwas schnell rum. Ich mag gar nicht so mühelos an die Power-Technologien gelangen.

Die Minuten mag ich ansich nicht in Echtzeit anzeigen, noch nicht mal den Stunden-Lauf.

Komisch, genau so ist es jetzt. Dafür jagen nun aber 4 Tage/sec durch. Also was in Echtzeit angezeigt wird, gefällt jetzt. Nur soll ich jetzt den Zeitlauf drastisch drosseln. Was muss ich tun?


Noch ein Gesichtspunkt: Der Tag-Nacht-Zyclus läuft in der Grundeinstellung imho viel zu schnell. Damit der Modus seinen Reiz bekommt (vielleicht auch nur ab und zu aus Spaß am Schauspiel), soll man den Zeitlauf deutlich verlangsamen können.

[michelstadt]

Da du nichts von hektisch rasenden Fahrzeugen berichtest, könnte es sein, dass du – falls du ein neues Spiel begonnen hast – in den Settings (als Button zu finden auf der Startseite "Eine neue Welt", dort im Singular) die „bits_per_month“ verstellt hast. Der Wert kann zwischen 16 und 24 liegen, wobei meines Wissens 19 Standard ist. Bei 16 rast die Zeit, bei 24 fließt sie gemächlich dahin.

Ich selbst bevorzuge (auch wegen eines angenehmeren Tag-Nacht-Wechsels) die 24, bei der ein Simutrans-Tag etwa 9 Minuten lang ist. Bei 19 ist in der gleichen Echtzeit ein ganzer Monat vergangen.

[Uranor]

Also soll das doch funktionieren? bits_per_month = 24 hatte ich in der simuconf.tab eingestellt. Aber das dann neu gestartete Simutrans wertete es nicht aus, zeigte mir eben die 16. Habe den Wert nun auch im Spiel auf 24 hochgesetzt, kein Unterschied im Zeitlauf. Auch nach Spiel-Neustart wieder kein Unterschied. Etwa 4 Tage/sec ist unverändert.

Jetzt sehe ich doch ratlos aus. Will mich mein Maschinchen ärgern. Das Spiel ist ja sicherlich nicht korrupt. Das wüssten alle. (Noch fahre ich keine Nightly sondern brav die 102.22).

[michelstadt]

4 Tage pro Sekunde, das ist schon komisch. Habe gerade einmal die 16 ausprobiert, selbst da dauert ein Simu-Tag bei mir etwa zwei Sekunden.

[Uranor]

Gut. Habe jetzt das Spiel außer paks und saves gelöscht, frisch entpackt. Beim frischen Spiel und nach jedem Wet Korrigieren + Spiel-Neustart steht bits_per_month = 16. Was mag gestört sein?

Als es mir auffiel, hatte ich gerade eine .ppm geladen... Aber ich bin dabei doch an keinen falschen Knopf gekommen. Das Optionen-Fenster war geschlassen, Relieffkarten standen auf dem Speiseplan.




Nachtrag: Mit der aktuellen Nightly das gleiche. Nun habe ich eine neue Welt gestartet, der Zeitlauf stimmt. Also ist meine Karte korrupt.

Gut, ich mag die Karte aber. Besteht eine Möglichkeit, die KartenNr. rauszubekommen? Das wäre *giga*.

Jetzt versuche ich mich mal an .ppm. Die bisherigen Versuche waren nicht gut. Mal weiter expirimentieren. Ich hatte sicher den Wiki noch nicht wirklich vertsanden.

[Cruzer]

Bei bestehenden Spielständen, bewirken die Änderungen an den Zeitinstellungen der simuconf.tab nichts!

[Uranor]

Das bedeutet, dass man sich vorher entscheiden muss. So wie man sich einstellt, so rast man. :evil: station_coverage in den Spielstand aufzunehmen, macht voll Sinn. Eine Welt muss so weitergeführt werden, wie sie begonen war. bits_per_month hätte ich allerdings variabel erwartet. Das ist wie "gute alte Zeit", "moderne Hektik", immer in der gleichen Welt... in unserer. Hab dank, Cruzer.



Der Trost. Der Wiki ist beim Thema .ppm offenbar noch nicht wirklich präzise. Habe jetzt eine Map aus der großen Sammlung als Muster genommen. Die Referenzwerte sind prima. Ich konnte meine Welt aus dem Screenshot von der Minimap rekonstruieren und gezielt variieren. Ich werde mal die Farbpalette daraus anlegen. Das bringt zügiges Arbeiten.

[wernieman]

Es ist insofern wichtig, da der Wert auch in das Balancing des PAKs mit einfliest.

Der Unterhalt (Straße, Schiene etc.) Wird immer am Monatsende (oder Anfang?) abgerechnet. Wenn Du also "längere" Monate hast ....

[jonasbb]

Original von wernieman
Der Unterhalt (Straße, Schiene etc.) Wird immer am Monatsende (oder Anfang?) abgerechnet. Wenn Du also "längere" Monate hast ....

Wird da nicht der Unterhalt proportional erhöht, wenn man längere Monate hat?

[Uranor]

Original von jonasbb

Original von wernieman
Der Unterhalt (Straße, Schiene etc.) Wird immer am Monatsende (oder Anfang?) abgerechnet. Wenn Du also "längere" Monate hast ....

Wird da nicht der Unterhalt proportional erhöht, wenn man längere Monate hat?

Jau, so verstehe ich die Beschreibung. So ein Modus ist norwendig. Das Verhältnis zwischen Einnahmen und Unkosten muss in Relation bleiben. Das lässt sich allerdings völlig auto-synchron über einen Zähler für Tics, Realsekunden oder ähnliches erreichen. Die Zähleinheit hat dann abhängig von den vorhandeenen Unkosten-Trägern ihren Preis. Man muss also durchaus nix blanko vorgeben. Die Umsetzung bleibt flexibel und korrekt.

Mit der fixen Umrechnung spart man allerdings einen dauerhaft brummenden Zähler. Ob das relevant ist, wissen die Coder. Verwaltungsdaten, die CPU-Leistung, das dürfte insgesamt nicht ohne sein.