Eine Fahrpreiserhöhung führt das Spiel ins Absurdum.
Geht man vom Spiel aus – beträgt das Monatsgehalt eines Arbeiters 16,00 (Z.B. eines Busfahrers 
)
Nun fährt dieser Arbeiter mit dem Bus an 26 Arbeitstagen auf die Arbeit:
26 x 4,00 x 2 (hin und zurück) = 208,00 pro Monat. Tja und wie macht er das?
1920 gab es keine Minijobs und kein Hartz IV und Rothschild ist sicher mit seinem Privatfahrzeug herumgefahren.
DAS ist doch die eigentliche Frage – was müsste man modden, damit dieses Defizit am wenigsten auffällt.
Damit der Fahrpreis „optisch und zahlenmäßig“ ins Spiel passt – müsste er so in etwa 0,50 bis max. 1,00 sein.
Das ließe sich nur mit Kapazitätserhöhung meistern.
Ob man 1920 8 Fahrgäste x 4,00 = 32,00
oder aber 80 Fahrgäste x 0,40 = 32,00 befördert – ergibt dasselbe.
Die Frage ist – was „optisch“ besser passt.
Mit 8 ist so ein Bus eher leer, mit 80 eher „schwanger“ .
Würde man die Fahrzeuge ein wenig beschleunigen und die Aufenthalte in den Stationen verkürzen,
könnte man eventuell erreichen, dass ein Bus 1920 40 Fahrgäste x 0,40 x 2 (beide Beschleunigungen) auch die 32,00 bringt.
Das Spiel wird durch den Fahrpreis so wie so gecheatet – versteckt man dies wo anders, könnte es der Optik zuträglich werden.
ja ... das könnte auch so sein ... habe es nicht so ganz konkret gemeint - eher erst grob die Richtung, ob das Problem in den script-Dateien zu finden wäre.
Die "richtige Stelle" zu finden dauert schon länger....
werde demnächst vorm Schlafengehen die scripts anstatt Märchenbücher lesen 
Es mag sein – dass es mit den Kosten etc. so OK ist – aber was total aus der Reihe tanzt ist der Fahrpreis:
Egal wie viele Augen man zudrückt, aber wenn ich nur 1x pro Monat 4 Passagiere von A nach B zu bringen brauche um das Monatsgehalt des Busfahrers zu erwirtschaften – dann stimmt da etwas nicht es sei denn - die fahren in der Firstclass³
Das dürfte das hier sein:
C:\Programme\Cities In Motion Beta\metro\objects\misc
function createFireEmitter($pos, $dir) {
with (new_particleEmitter(this)) {
.position = $pos;
.direction = $dir;
.minParticleSpeed = 3.0;
.maxParticleSpeed = 4.0;
.minParticleAngle = 0.0;
.maxParticleAngle = 0.5;
.minParticleLife = 2.0;
.maxParticleLife = 2.5;
.maxDistance = 2000.0;
.particleSize = 0.5;
.setParticleScale(1.0, 0.1, 6.0);
.particleAirResist = 0.2;
.gravitation = vector(0.0, 4.0, 0.0);
.density = 40.0;
.particleBlend = BLEND_ADDITIVE_ALPHA;
.addColorRange(0x30FFFF00, 0x00FF0000);
.setTexture("effects/particles/lightsmoke.dds");
.minOnTime = 0.1;
.maxOnTime = 5.0;
.minOffTime = 0.1;
.maxOffTime = 3.0;
.sortParticles = true;
.autoemit = true;
.visible = true;
}
Man könnte mal probieren dies auf false zu setzen : .autoemit = true;
Schaut man sich die Grund-Daten an (Fahrpreis, Anschaffungskosten, Gehälter etc.) - hat dies mit einer Wirtschaft Simulation eher wenig zu tun.
Ein Beispiel BUS 01 1920:
Ich als Fahrgast würde lieber 54 Tage zu Fuß laufen und dann mir einen Bus kaufen. 
(54 x 4,00 = 216,00)
Als Busfahrer mit einem Monatsgehalt von 16,00 könnte ich gerade mal vier Mal fahren,
mich unter der Brücke niederlassen und als Sammler und Jäger die Freizeit verbringen. 
Damit ein Hauch von Realität ins Spiel käme – müsste man die Grund-Daten z.B. so multiplizieren, wie oben angegeben. Das würde bedeuten, dass beim bleibenden Fahrpreis durch die erhöhte Kapazität (x50) auch noch die Beförderungszahlen ansteigen müssten. Ob das änderbar wäre ist noch offen.
Was jedenfalls änderbar ist - die Belegung der Wohnhäuser. Anzahl und Bewohnerschicht läßt sich ändern.
Das Startkapital müsste auch entsprechen höher sein – was kein Problem wäre. 
So wächst z.B. Wien:
hi!
sehr ähnlich die Fehlermeldungen
Auf dem anderen Wege - über die entpackte Metro mit der editierten build.script habe ich leider Abstürze bzw. die Spielstände lassen sich nicht mehr laden....
es sind "nur" noch 12 Tage Warterei...
Bei mir klappt es so leider nicht:
die original-metro.gs hat 18.348 KB
die neue nur 18.333
und es gibt folgene Fehlermeldung:
