Instandhaltung an Bits/month angleichen?

[Beder]

Allgemeines Problem oder Wunsch. Jenachdem

Also wenn man die Bits per Month runter oder hochstellt hat man immer ein Problem
Wenn sie runtergestellt werden, ist die Instandhaltung extrem hoch und man kriegt nie genügend Geld (da die Zeit doppelt so schnell vergeht zahlt man das vierfache ;-))
Wenn man sie hochstellt, zahlt man eigentlich kaum mehr was für die Instandhaltung. (vierfacher Gewinn, selbe Instandhaltung)

Gäbe es eine Möglichkeit, diesem abzuhelfen? Also dass die Instandhaltung noch mit den Bits/monat multipliziert werden oder so?
Sonst wird eine extreme Verzerrung des Spiels bei unterschiedlichen Bitzahlen erreicht.

Ich weis nicht inwieweit man das noch verändern könnte

[Wurzelgnom]

Bits_per _month wird sehr wol berücksichtigt.

Bei Wert 18 entspricht die Instandhaltung den in der Dat und in der simuconf.tab angegebenen Werten.

Bei Wert 20 werden die Kosten x 4 gerechnet.

[Beder]

Also pak 128 ist auf 19 bit/monat festgelegt
sobald man dann 18 bits hat erschlagen einen die instandhaltungskosten
ich weis auch nicht warum ;-)

PS: von 20 auf 18 is 16fache geschwindigkeit ^^

[Wurzelgnom]

Original von Beder
Also pak 128 ist auf 19 bit/monat festgelegt
sobald man dann 18 bits hat erschlagen einen die instandhaltungskosten
ich weis auch nicht warum ;-)
...

Kann ich nicht nachvollziehen.

Die Instandhaltungskosten werden halbiert.

Also die Gebäudeinstandhaltung ist in der simuconf.tab mit 18 Cr angegeben.

Bei bits_..=19 beträgt diese im Spiel 36 Cr.
Bei bits_..=18 beträgt diese im Spiel 18 Cr.
Bei bits_..=20 beträgt diese im Spiel 72 Cr.

Das ist auch bei den Straßen so. Wobei der 'Feldweg' scheinbar gar keine Instandhaltung hat. Und die 'Schotterpiste' 0,30 Cr (oder so) bei bits_..=18 hat.

Bezieht sich alles auf Release 1455 mit pak128 1.4.2.2.

Ich habs jeweils mit der leeren Startkarte geprüft.

Bei gespeicherten Spielen bleibt die Instandhaltung gleich.
Vermutlich wird bits_.. im Spielstand mit gespeichert. Die Monatslaufzeit bzw. die Instandhaltungslosten werden aber nicht angepasst.

Würde ich also als Bug bewerten.

[DirrrtyDirk]

Original von Beder
PS: von 20 auf 18 is 16fache geschwindigkeit ^^

Nach meiner Rechnung nicht...

[Anonymissimus]

Original von FrankP
Vermutlich wird bits_.. im Spielstand mit gespeichert.

zumindest bei pak.german und basispak...ja
laden mit verändertem bits_... ändert geschwindigkeit nicht, oder spiel stürzt sogar ab (das war meistens der fall, wobei ich das nicht nen "bug" nenne)

ein bit mehr ist schon halbe geschwindigkeit, ich habs mit der realzeit verglichen
steht auch so in der simuconf.tab, nur da steht was von microseconds das muss offensichtlich milliseconds heißen
war immer zu faul das mal zu posten^^

[Wurzelgnom]

Original von Anonymissimus
...
ein bit mehr ist schon halbe geschwindigkeit,
...

In diesem Zusammenhang bitte den Begriff Monatslaufzeit verwenden und nicht Geschwindigkeit.

Grundlage ist die Monatslaufzeit von bits_..=18. Das entspricht also Monatslaufzeit=1.

Also müsste es sich wie folgt verhalten

18 = Monatslaufzeit
19 = 2x so lange Monatslaufzeit
20 = 4x so lange Monatslaufzeit
21 = 8x so lange Monatslaufzeit

[Beder]

Oh Entschuldigung dann hat sich das wohl erledigt.
Ich hatte erstens einen Rechenfehler (4 fach so lang, nicht 16 fach) und irgendwie hatte ich das Gefühl als ob man von den Kosten erschlagen wird. Kann mir auch blos so vorgekommen sein, da es bei pak 128 sehr schwer ist am Anfang nicht erschlagen zu werden

[Gotthardlok]

Archiv