Beiträge von Xanos

@brunna: First the Patch, then the original exe.

//edit: too late

Japs, mein Talent ist (ohne Mittelwaggon) soweit fertig modelliert und gemapped, es fehlt quasi nur noch die Textur und die Feinarbeit. Leider komme ich im Moment sehr selten zum modden.

ModManager nutzen, für die Reparatur:
Steam - Rechtsklick auf Train Fever - Eigenschaften - Lokale Dateien - Dateien auf Fehler überprüfen.
Niemand wird dir hier Originaldateien illegal zur Verfügung stellen! Geschlossen.

@chrigulix: Paradox ist vielleicht ein Nischenpublisher - aber immerhin ein bekannter Publisher, der seine Spiele evtl an die Grafikkartenhersteller schickt damit diese in die Liste aufgenommen werden. Außerdem nutzt CiM2 mit Unity eine bekannte und sehr verbreitete Engine, die entweder von den Grafikkarten erkannt wird oder aber selbst Mechanismen nutzt, um "erkannt zu werden".

Theoretisch ja, praktisch nicht ratsam, da das mit verschiedenen Systemen wieder starke Fehlerquellen aufwirft.

@eis_os: Meine Antwort dazu per PN, ich will ja nicht das es hier ausartet.

Genau wie die ganzen Tools, die auf Android den RAM angeblich frei halten. Ich persönlich bin da auch absolut kein Fan von - aber wenn es einigen individuellen Leuten wirklich helfen sollte, dann bitte

Ja, in einem älteren Build wurde das eingeführt und das konnte ich auch bemerken/bestätigen. Da für die 50xx Builds aber davon nichts in den Patchnotes stand fragt @Tom ja nach, ob jemand anderes die selben Beobachtungen gemacht hat

Zitat von chrigulix

Hat man nun noch eine leistungsfähigere Grafikkarte wird von TF jeweils die Intel-GPU benutzt.

Eher erkennt die "richtige" Grafikkarte nicht, dass sie gebraucht wird und springt nicht an. Es ist nämlich mitnichten so, dass große Spielehersteller ihr Spiel auf eine Grafikkarte anpassen, sondern der Grafikkartentreiber wird auf das Spiel angepasst. Deswegen gibt es bei jeder Veröffentlichung eines größeren Spiels (oder eines Spiels eines großen Publishers) immer auch ein Grafikkartentreiberupdate mit tollen Patchnotes wie "20% mehr Leistung bei Battelfield 4" o.ä.
Spiele, die "normale", "bekannte" Engines benutzen werden dabei oft auch von alten Treibern als "Spiel" erkannt und die Grafikkarte übernimmt die Berechnung. Aber gerade bei kleinen Publishern ignorieren die Karten das Spiel einfach.

Zu guter letzt bleibt die Frage: Warum optimieren Grafikkartenhersteller die Treiber auf bestimmte Spiele? Nun ja, die angeblich aussagekräftigsten "Benchmarks" von Grafikkarten werden von allen großen Zeitschriften und Onlinemagazinen nun ein mal auf Basis eines Spiels veröffentlicht. Und wenn dann eine Karte X im neuesten Crysis auf ein mal 5 unsichtbare Frames mehr hat als die Karte Y, zeigt sich das oft sehr deutlich in den Verkaufszahlen

Zum Vorschlag @Tom: Ja, das korrespondiert zu meinem Vorschlag, "unwichtige" oder zumindest "unbemerkte" Berechnungen seltener auszuführen, und sich dadurch ganz einfach Rechenzeit zu sparen, ohne die Algorithmen selbst ändern zu müssen.

Zum "Verhalten": Bei meiner großen, stark bebauten Testkarte habe ich kurz vor dem Patch zufällig gesehen, wie eine Autobahn zwischen Zwei Städten zu einem großen, zweispurigen Parkplatz geworden ist. Seit dem Patch konnte ich dieses Phänomen nicht mehr entdecken. Ob das nun mit dem Patch zusammenhängt, habe ich bisher nicht weiter analysiert. Da ich noch eine alte .exe im Backup habe, könnte ich das bei Zeiten mal näher Untersuchen.

Directly change the game settings file which is found here: \Steam\userdata\<Steam_User_ID>\304730\local with a normal text editor.
Alternatively, use 'Alt'+'Enter' keys to go to windowed mode and change the resolution back to a correct one.

Du hast am Ende bereits selber gesagt: die 20 Minuten sind Realzeit… nicht Spielzeit
Es geht darum, nur den Monat langsamer laufen zu lassen, als andere dabei so zu lassen, wie es ist. 20 Minuten bleiben 20 Minuten und die Züge legen im 20 Minuten die gleiche Strecke zurück. Ob nach diesen 20 Minuten auf den Kalender dann 20.01. oder 9.2. oder was auch immer steht kann den Leuten in TF und der Wegfingung ja egal sein. Wenn die 20-min Regel nicht an die Realzeit, sondern intern an die angezeigten Tage und Monate gekoppelt ist, müsste man die Zahl auch nur entsprechend skalieren.

Das gesamte Spiel mit einer Zeitlupe verstehen bringt nichts. Wenn die Züge nur noch umher schleichen beschleunige ich als Spieler natürlich mehr. Die Züge müssen schon genau so schnell bleiben wie die sind. Also auf 1-facher Geschwindigkeit in 20 Real-Minuten die selbe Strecke fahren wie bisher.

\res\config\multiple_unit
Dort befinden sich .lua-Dateien mit folgendem Inhalt:

function data()
return {
    vehicles = {
        { name = "vehicle/train/a.mdl", forward = true },
        { name = "vehicle/train/b.mdl", forward = true },
        { name = "vehicle/train/c.mdl", forward = true },
    },
    name = "Zug",
}
end

[ironie]Das muss ein Hinweis auf ein Schwebebahn (wörtlich genommen) - DLC sein [/ironie]

@0815san, Kommt auf die Art der Berechnungen an. Wenn zum Beispiel nur alle zwei Monate jeder Person auf der Karte eine neue "Arbeitsstätte, Freizeit, Einkaufsmöglichkeit" zugewiesen wird, dauert es zwar länger bis neue Linien genutzt werden, aber die Berechnung wird effektiv wirklich halbiert. Wenn man zum Beispiel aber halb so oft die Leute "auf ihren Weg" schickt, hat man natürlich deutlich weniger Verkehr auf den Straßen und weniger Andrang im ÖPNV - das wäre ein so starker Eingriff in das Balancing, dass man entweder die Einwohnerzahl verdoppeln müsste (Damit hätte man nichts gewonnen) oder aber man müsste das ganze Spiel neu balanzieren -> So etwas wird also sicherlich nicht gemacht.

Trotzdem gibt es sicherlich einige Berechnungen, die man seltener ausführen könnte, auch wenn man eventuell einen geringen Grad an Realsimus oder Reaktionsfreudigkeit einbüsen würde.

Der erste Anhaltspunkt sollte aber immer die Frage sein: Wie kann ich die Algorithmen verschnellern, effektiver machen oder allgemein austauschen?
Einfaches Beispiel zur Wegfindung: Muss man für jede Person einzeln den Weg berechnen oder berechnet man nicht lieber die Wege nur dann, wenn sich etwas am Verkehrsnetz ändert, und die Personen greifen dann auf einen viel schnellen Algorithmus zurück, der auf Basis der vorberechneten Daten einen Weg aussucht. Auch dann: muss ich alles neu berechnen oder eventuell nur einen lokalen Teil?
Ich will Urban Games sicherlich nicht vorwerfen Ineffiziente Algorithmen zu nutzen, allein schon aus dem Grund das ich nicht weiß, wie sie die Berechnungen durchführen. Aber eventuell (hoffentlich) lässt sich da ja an einigen Stellen noch etwas verbessern. Natürlich nur solange es "im Rahmen" bleibt, UG soll sicherlich nicht ganze Teile des Spiels neu schreiben müssen.

@Angry_CJ: Die Probleme "verschwinden" dadurch nicht, sondern man "versteckt" sie natürlich nur. Und spätestens wenn man auf einer ausreichend großen Karte mit 4-facher Geschwindigkeit spielt tauchen sie auch irgendwann wieder auf

Die Veränderung der Monatsdauer hat ja zum Glück auf die 20-Minuten-Regel (sofern diese nicht an die Monate gebunden ist) keine Auswirkung. Man braucht einfach nur länger bis neue Fahrzeuge erscheinen. Was angepasst werden müsste sind die Unterhaltskosten und Preise: Wenn ein Monat doppelt so lange dauert, ansonsten alles aber gleich schnell bleibt (das wäre ja der Sinn, sonst würden alle nur noch auf 2-facher Geschwindigkeit spielen) verdient man natürlich doppelt so viel während alle kosten gleich bleiben. Also entweder die Fahrkartenpreise halbieren (einfacherer Weg) oder die restlichen Preise steigern. Theoretisch sollte es also Möglich sein, die Frage bleibt: ist da intern eventuell noch etwas verstrickt / zusammenhängend und: Will UG die Monatsdauer überhaupt ändern? Im Hinterkopf behalten sollte man auch noch den Fakt, dass man dann natürlich auch doppelt so lange braucht um von 1850 bis in das Jahr 1950 ( oder gar 2000) zu kommen. Und für Neulinge sind die anderen Startjahre noch gesperrt!

Natürlich müsste das restliche Spiel (Balancing) auf die geänderte Monatszeit angepasst werden aber ja, das wäre eine Möglichkeit, die Monats-Ende Lags zu umgehen.
Alternativ könnte man auch den Weg wählen, nur alle 2 (oder alle 3) Monate die Berechnungen neu zu machen.

Beide Optionen lassen sich aber nicht modden, sondern können nur von den Entwicklern umgesetzt werden.

Definitiv DLC-würdig, was man so bisher sieht
Ich hätte auch sehr gerne am DLC mitgewirkt, aber ich finde ja nicht ein mal Zeit mein eigenes Model fertigzustellen, geschweigenden ein neues anzufangen. Mit Texturierung habe ich auch noch überhaupt gar keine Erfahrung, ich hoffe aber Du findest einen guten "Maler"

[Blockierte Grafik: http://ftp.train-fever.net/flaggen/gb.png] in A short overview regarding calculations, multi core usage and end-of-the-month waiting times in Train Fever, Build 5080:
Die Deutsche Version gibt es hier.

First of all, the obvious: Train Fever uses multiple threads. In the following text, I will refer to the "main game", respectively, the stuff that is presented to us on the screen as "main thread". In this main thread, the more calculations have to be done, the lower the frame rate (fps) will be. The more calculations can be outsourced to different threads, the more fluent the game will run.

Currently, Urban Games has achieved to swap out some of the calculations from the main thread to different other threads. These other threads run in parallel to and the operating system schedules the threads to the cores of the processor. Important to note: one thread may be executed on multiple cores, but the execution will be sequential, thus showing only a low percentage of usage on each core when e.g. using windows task manager. Mutliple threads can also be executed on only one core. In this case, they have to share the computation power of this core and each thread will be throttled down. In the best case, each thread can run on its "own" core and all threads are executed in parallel.

With increasing complexity of a save game, respectively the number of persons / vehicles, the calculation gets more and more complex and time consuming. In older builds, this was noticeable by dropping frame rates. With build 5068, Urban Games swapped the path-finding to a separate thread and the fps should in general increase. However, some players experience longer lags / waiting times at the end of each month. This can be explained as follows:

In Train Fever, the "overlaying" time unit is a "month". At the end of each ingame month, all calculations have to be finished before starting the new month. By swapping out calculations to different threads, the main thread may run faster but at the end of the month, all calculations have to be finished nonetheless. If for example the path-finding takes 2 minutes to complete its calculations but the month is over after only 1 minute and 30 seconds, the player has to wait the remaining 30 seconds until the path-finding algorithm is finished. If the game is paused - or even speed up - during the month, the duration of a month varies, while the duration for the calculations stays about the same, only increasing with increasing complexity of the save game. When playing with 4-times the speed all month, it is more likely, that the player will experience a long lag at the end of the month. Pausing the game during a month will more likely lead to shorter - or no waiting times.

Please note: parallelization of algorithmsdo not speed up the calculation itself. If the path-finding slowed down the main thread by two additional minutes (resulting in much longer months, resp. lower fps), the calculation will still take two minutes when calculated in a separate thread. Of course, If one month also takes about two minutes, the game was speed up due to parallelization and no lags are present. However, if the calculations take up more time than the main game thread, lags will be experienced. The only options of speeding up the algorithms, would be choosing a different, faster implementation of the algorithm or to parallelize the algorithm itself (which is not always possible).

This thread should not be considered a instruction of "how to play" to not get lags. I only try to explain the background information for you guys to hopefully understand the "problem".

One last information: If you have a fairly modern PC, and still have low fps, consider choosing the "low texture" option. The graphics still look good and the fps can increase quite much. Most modern graphics cards are "bored" by the calculations for Train Fever but do not have sufficient memory, due to the tremendous amount of graphical ram needed by Train Fever is many objects are on the map.

Update regarding Build 5112:

Zitat von Urban Games

Most important, players reported freezes at the end of each game month. We have identified the problem and it is fixed now. Because since the last update, the game runs faster during the months, on certain systems (parallel) simulation calculations which need to be finished at the end of each month were still in progress and caused these freezes.

I can confirm this on my machine with lags not exceeding more than 2 seconds even on large maps on full speed.

[line][/line]

[Blockierte Grafik: http://ftp.train-fever.net/flaggen/de.png] Ein kurzer Überblick über Berechnung, Mehrkernnutzung (Multicore) und Wartezeit am Monatsende, Stand Build 5080
English Version can be found here.

Zuerst ein mal das offensichtliche: Train Fever nutzt mehrere Threads. Das eigentliche Spiel, beziehungsweise das, was uns auf dem Monitor angezeigt wird nenne ich im folgenden ein mal "Hauptthread". Je mehr Berechnungen der Hauptthread parallel zum eigentlichen Spielgeschehen berechnen muss, desto geringer wird die Framerate (FPS).

Mittlerweile hat es Urban Games geschafft, einige Berechnungen aus dem Hauptthread auszukoppeln, und in anderen Threads unterzubringen, die parallel laufen, und vom Betriebssystem auf andere Prozessorkerne verteilt werden können. Wichtig hierbei im allgemeinen: Ein Thread kann auch auf mehreren Kernen ausgeführt werden, aber die Ausführung bleibt sequentiell, das heißt, es gibt keinen Geschwindigkeitsvorteil, sondern nur einen Last-Ausgleich für den Prozessor. Mehrere Threads können auch auf einem Kern laufen, teilen sich dann aber die Berechnungszeit. Im Idealfall werden alle Threads parallel ausgeführt.

Mit steigender Komplexität des Spielstandes, sprich der Anzahl der Personen bzw Fahrzeuge, steigt natürlich auch der Berechnungsaufand des Spiels. Früher hat sich der größere Berechnungsaufwand vor allem durch geringere FPS bemerkbar gemacht. Seit dem mit Build 5068 nun auch die Wegfindung in einen eigenen Thread verschoben wurde, sollte die FPS Zahl im allgemeinen gestiegen sein, dafür klagen nun einige Spieler über längere "Wartezeiten" / "Lags" am Monatsende. Dies lässt sich wie folgt erklären:

In Train Fever gibt es die Besonderheit, dass der "Monat" als Zeiteinheit gewählt wurde. Am Ende jedes Monats (im Spiel) müssen alle Berechnungen abgeschlossen sein, ansonsten kann der nächste Monat nicht beginnen. Dadurch, dass die Berechnungen ausgelagert werden, läuft das Spiel selbst zwar wieder flüssiger und dadurch auch schneller, die Berechnungen selbst müssen aber natürlich immer noch durchgeführt werden. Wenn der Berechnungsaufwand zum Beispiel für die Wegfindung nun ca zwei Minuten beansprucht, der Monat aber bereits nach 1 Minute 30 Sekunden vorbei ist, muss der Hauptthread noch 30 Sekunden auf die Fertigstellung der Wegfindungsberechnung warten - ein 30-sekündiger Lag tritt auf. Pausiert man das Spiel nun, oder beschleunigt man es, verändert man zwar die Dauer des "Monats", die Berechnungen brauchen aber in Echtzeit immer ungefähr gleich lang. D.h. wenn man dauerhaft auf 4-facher Geschwindigkeit spielt, wird man im Schnitt deutlich längere Wartezeiten zum Ende des Monats erhalten. Pausiert man innerhalb des Monats das Spiel hingegen, ist es sehr wahrscheinlich, dass die Berechnungsthreads bereits vor Ende des Monats ihre Arbeit vollendet haben, und das Spiel ohne Wartezeit weiter läuft.

Zu beachten ist: Parallelisierung von Aufgaben beschleunigt die Aufgabe an sich nicht. Wenn die Wegfindung früher den Hauptthread um 2 Minuten mehr pro Monat ausgebremst hat, wird die Berechnung in einem eigenen Thread auch immer noch (mindestens) 2 Minuten dauern. Solange die Berechnungsdauer kürzer ist als ein Monat, führt das Auslagern natürlich nur dazu, dass die FPS besser ist, sobald die Berechnung aber länger dauert hat man leider die Wartezeit. Oder noch ein mal anders gesagt: Wenn euer Spiel vor Build 5068 so stark geruckelt hat, dass die Monate deutlich langsamer vergingen, ist damit zu rechnen, dass der Monat jetzt zwar wieder schneller umgeht, der Berechnungsaufwand aber immer noch der selbe ist, und die Zeit dann am Ende des Monats abgewartet werden muss. Natürlich hat die Wegfindung nun einen "eigenen" Thread für sich, aber durch Abhängigkeiten zwischen Threads und den allgemein großen Aufwand, können diese Berechnungen vor allem auf großen Karten mit vielen Personen und vielen Möglichkeiten (durch ein großes Verkehrsnetz) ziemlich lange dauern.

Dieser Beitrag soll euch hierbei nicht zu einer gewissen Spielweise bringen (z.B. innerhalb der Monate öfter zu pausieren oder allgemein nicht vorzuspulen), sondern nur versuchen, die Hintergründe verständlich zu erläutern.

Zum Abschluss noch ein kleiner Hinweis: Wer trotz neuestem Patch immer noch geringe FPS hat, sollte - falls noch nicht geschehen - die Texturqualität auf "niedrig" schalten. Zwar langweilen sich moderne Grafikkarten bei Train Fever, haben aber auf großen Karten mit vielen Objekten aufgrund des unglaublichen Speicherhungers von Train Fever nicht genügend Grafikspeicher.

Update zum Build 5112:

Zitat von Urban Games

Most important, players reported freezes at the end of each game month. We have identified the problem and it is fixed now. Because since the last update, the game runs faster during the months, on certain systems (parallel) simulation calculations which need to be finished at the end of each month were still in progress and caused these freezes.

Auf Deutsch heißt das: Die von mir Beschriebenen Auswirkungen wurden von Urban Games gefixt - es wurde also versucht (auf welche Art auch immer) die Lags am Monatsende zu unterdrücken. Nach einem kurzen Testlauf auf meiner großen, vollen Karte im Jahr 2055 kann ich das durchaus bestätigen. Selbst auf maximaler Geschwindikeit bleiben die Ruckler unter maximal 1-2 Sekunden und sind somit quasi Behoben. Vielen Dank an Urban Games an dieser Stelle, für die schnelle und gute Arbeit.
Zusätzlich wurde angekündigt, das "Hauptstraßen-Feature" in zukünftigen Versionen zugunsten eines "Sandkastenmodus" ausschaltbar zu machen, dazu aber in anderen Themen mehr.

[line][/line]

Zitat von Duscha

Scheinbar haben sie nun Berechnungen, die sonst waehrend des Monats nebenher liefen, an das Monatsende gelegt.

Ich verweise gerne hier drauf.