Beiträge von eis_os

Nochmals. Ich wüsste keine Konstellation, die deinen beschriebenen Effekt verursachen kann. Sonst starte mal dein System neu, vielleicht den Texturcache leeren...

Die Datendatei ist nur für die jeweilige Version von TF gültig (Binärdiff) und der Patcher ist sowieso eine Webseite, es gäbe da also nicht wirklich etwas zum Hochladen...
"Gameplay-Mods" war annähernd passend. Meistens sind meine Themen nie wirklich in eine Kategorie - wie die Analyse des Threadings - einzuordnen.

Die sich am meisten darüber ärgern werden schon darüber Stolpern...

Es werden nur Bytes des Programmcodes geändert um den Fehler zu umgehen, und alte Spielstände funktionieren bei mir auch noch. Da muss schon vorher ein Fehler gewesen sein...

Es ist keine Lösung, es schaltet das Feature einfach wieder ab...

Wer es nicht mag und mit der Windows 64Bit Version spielt:
TFPatchPlus

Ich hab gestern 2 Stunden gespielt und keine Fehler gefunden

Hallo

Ich kann es nicht lassen, mein erster Binärpatch für Trainfever

Entfernt die Hauptstrassen Verbindungsbeschränkung für TrainFever.exe 64Bit 4831 so das es wie in den älteren Versionen funktioniert.

Zip Datei herunterladen und entpacken, Link im Readme folgen.
1. Die patch.bz2 Datei aus der Zip Datei auswählen
2. Die TF exe Datei auswählen.
3. Die gepatchte Datei aus eurem Browser "herunterlanden"

Windows 64bit Link:
http://www.bytetransfer.de/pro…hplus/TFPatchPlus_v01.zip
Build 5080:
http://www.bytetransfer.de/pro…chPlus_v02_win64_5080.zip
Build 5112:
http://www.bytetransfer.de/pro…chPlus_v03_win64_5112.zip

Linux 64bit
Build 4831:
http://www.bytetransfer.de/pro…Plus_v01_Linux64_rev2.zip
Build 5112:
http://www.bytetransfer.de/pro…Plus_v03_Linux64_5112.zip

OSX 64bit
Version 4831
http://www.bytetransfer.de/pro…chPlus_v01_osx64_rev2.zip
Build 5112:
http://www.bytetransfer.de/pro…chPlus_v03_osx64_5112.zip

(in /Users/<username>/Library/Application Support/Steam/SteamApps/common/Train Fever,
siehe auch: TFPatchPlus OSX Installation)

---
I simply can't resist, my first binary patch for TrainFever.exe 64Bit 4831

It will simply remove the main street connection bypass error, so TF pretty much works like earlier game versions.

Instructions:
Download and unzip the file, go to the link in the readme.txt
1. Select patch.bz2 from the extracted zip file.
2. Select the TrainFever.exe
3. "Download" the patched TrainFever.exe

Please use the download links above.

OSX:
(see /Users/<username>/Library/Application Support/Steam/SteamApps/common/Train Fever
and TFPatchPlus OSX Installation)

----
Beachtet: Ich verteile nur die Byteänderung und das eigentliche Patch wird in eurem Browser lokal erledigt.
Please note: I only distribute the difference and the actually patching is done locally in your browser.

Hmm?

Split jeden String bei Punkt. Nehme das längste als Basis, nehme jedes Array Element von A B und vergleiche es.

Pseudo Code:

maxlenarray = lenarray1 > lenarray2 ? lenarray1 : lenarray2;
for i = 0; i < maxlenarray ; i++ {
a = exist a[i] ? a[i] : 0;
b = exist b[i] ? b[i] : 0;
if (! (numeric (a) && numeric (b) ) ) {
return dontknow;
}

if (b < a) return false;
}
return true;

Funktioniert auch mit 0.9.5.1.2.3.4 und 1.0 oder 1.0.0.0.0.0.0.0.0 oder 1

Meine Tester haben sich leider noch nicht zu Wort gemeldet noch wie ich sehe heruntergeladen. Ich hätte da wohl eine Lösung aber ohne Testen...

Ja, für eine besagte Komplexität X ist der Rechnungsaufwand Konstant. Du musst aber die Daten im Main Thread zusammenführen. Sind die Daten verhältnismäßig Groß, kann Thread 1 das nicht innerhalb eines Frames zusammenführen wenn es mit zu vielen GPU Kommandos beschäftigt ist und TF bleibt dann trotzdem stehen. (kleiner Ruckler am Ende, dieser Fall ist selten aber könnte auch passieren)

Das Problem ist aber, X ist ist nicht konstant. Wenn deine Sims aus dem Zug steigen, müssen diese einen Weg finden und Kollisionen vermeiden.
Wenn ein Sim zu Arbeit will muss TF eine Route per Auto / Zug / Tram und Linien + Umsteigen errechnen

Einfach im Fenstermodus noch den ProcessExplorer (Sysinternals Suite) -> TrainFever auswählen und die Threads anzeigen, dann kann man TF schön beobachten. Der MSVCP Thread ist der hier genannte zweite Thread, der als Eingabe Daten Linienberechnung und die Gebäudesimulation annimmt. Man kann das auch ganz gut selber Testen in einem Savegame, einfach alle Fahrzeuge in der Fahrzeugübersicht verkaufen, dann sollte Thread 2 schneller fertig werden und man hat keine Probleme beim Jahresabschluss.

Thread 1 ruft Join auf und wartet auf Thread 2 sollte dieser noch nicht fertig sein.

Thread 2 CPU gebunden, zu langsam, Tag im Monat:

Thread 1: --1------------------15-------30Join                M-1------------------->
Thread 2:    \------------------------------------------------/ \------------------->

GPU zu langsam, stottern:

Thread 1: --1- - - - - - - - - - - - - - - - - - 15- - - - - - -30Join Merge - - - - - - - - - - - - - -1- - - - - - - - - - - - - - - - - - 15 ->
Thread 2:    \---------------------                               /                                      \--------------------------/

Und das Monatsende mit Frames dargestellt:

Frame X:  0                                       1                                       2    
Thread 1: --UI-SOUND-GPUGPUGPU- Join- DataMerge --------------------------------------------->
Thread 2: -----                /                    \---------------------------------------->

Wenn beides zu langsam ist, habe wir diesen Fall:

Frame X:  0                                       1                                       2    
Thread 1: --UI-SOUND-GPUGPUGPUGPUGPUGPUGPUGPUGPU-Join      DataMerge --------------------------->
Thread 2: ------------------------------------------------/           \------------------------->

Legende:
- CPU Arbeitet
\ Thread Start
/ Thread Ende

Testaufbau:
Spiel mit Monats-Abschlussproblemen im Jahr 2228, Volle Geschwindigkeit, 3 Monate gewartet nach Änderungen. ProcessExplorer um die Thread 2 Erstellung und Mergen zu sehen.

Test
Zum Testen in einem Spiel alle Fahrzeuge verkauft, danach läuft der Monatsabschluss, da Thread 2 schneller fertig wird.
Thread 2 braucht dann im Test nur ca. 24 Ingame Tage für seine Berechnung.

Alle Linen entfernen (waren mehr als 60) resultiert in ca. 22 Tage, also innerhalb der Messtoleranzen...

Entfernen von ca. 50% aller gebauten Teile wie Schienen Brücken Tunnel und Haltestellen hat nichts geändert.
Straßen-Schnellverbindung zwischen den Städten hat auch keinen Signifikanten Einfluss, entfernen von Busspuren auch nicht.

Probleme mit Signalen, Zügen oder Stationen und oder Schienen die das Wachstum beeinflussen kann man auch eher ausschließen, zumindest gab es an den Stellen keine mehr neuen Häuser.

Für die Stadtberechnung, Einwohner Berechnung braucht TF würde ich sagen zu viel Zeit.

Das Transportnetzwerk muss berechnet werden, das macht TF ja schon im Hintergrund, siehe meine Analyse.
Steam lässt leider keinen Debugger zu, DRM sei dank *grumel*. Daher ist es mir leider nicht möglich irgendwelche Code Pfade zu analysieren.

Erschlagen kann man das Problem mit sehr viel CPU Geschwindigkeit pro Kern, wenn es ein wenig ruckelt kann man es durch reduzieren der Grafikeinstellungen reduzieren, dann hat man mehr Zeit für nicht GPU relevante Berechnungen.

Die meisten Mods sind Grafiklastig, dh. wenn dein Geschwindigkeitsproblem am Grafikspeicher liegt, dann hilft die Reduzierung der Mods.
Industrie Mods fügen noch mehr eigene Netzwerke hinzu, das sollte man wohl vermeiden.

Die Einwohner Zahl scheint hierbei wohl die Hauptgröße zu sein. Im ersten Monat nach dem Laden sollte das Problem weniger schwer liegen, da hat TF es schon beim Laden vor-berechnet, dafür müssen die Texturen erst mal in den Grafikspeicher geladen werden...

Nein das mit den Häusern war ein Beispiel, warum man zwar vieles parallel berechnen könnte, es aber eben doch nicht so einfach ist. Es gibt Abhängigkeiten.
TF macht keine doppelten Berechnungen.

Thread 2 berechnet vor sich hin.
Thread 1, der Hauptthread wartet am Monatsende bis Thread 2 fertig ist um die Daten dann zu verarbeiten bzw, anzuwenden. (Status B)

Von denn Eingabe Daten zu Thread 2 gehe ich davon aus. das die Personen / Häuser Beziehungen, bzw. deren Verkehrsverbindungen berechnet werden.

TF macht diesen Thread jeden Monat neu auf. (Kann man mit ProcessExplorer ganz gut verfolgen und deckt sich mit Code und Beobachtungen).
Wie weit das parallelisiert werden kann ist die Frage. Ob die Aufteilung in Städte Sinn macht, ich würde sagen das es keinen Nutzen bringt. Da die Passagiere/Güter eben nicht auf Städte begrenzt sind, kann eine naive Variante - einfach in x Teile aufbrechen - trotzdem die schnellere sein.

Besseren Malloc Code um die Cache-Lokalität zu erhöhen bzw. ein paar unkonventionelle Ideen könnten bestimmt besser sein und man sollte da mehrgleisig fahren.

Wenn ich denn Quellcode hätte. würde ich da ein mal ein paar Ideen durchspielen, so kann ich nur etwas an der Schale kratzen.

Wie gesagt, die Texturqualität reduzieren hilft, dann komprimiert TF die Daten vorher im Textur cache. Herauszoomen = anderes LOD Level der Meshes = Weniger Details = Weniger Daten.

Wirtschafts / Städte Simulationen sind Big Data. Es hat schon Gründe warum Maxis die Städte klein gemacht hat, das kommt nicht von ungefähr.

Nunja, nur höchstens 33% deines CPU werden genutzt und Takt ist nicht alles. Ich würde auf zu wenig Video Speicher tippen, das ist nicht zufällig nur ne 1GB Karte oder schon einige Mods installiert?
Was macht TF Intern und warum es ruckelt

Und definiere mal schwächere Hardware? Und wie groß/kompliziert ist dein Transportnetzwerk?

PS: Um es Vorweg zu nehmen ich kann gefühlt ne Tasse Kaffee trinken am Monatsabschluss im Jahr 2228 mit nem Phenom X6

Urban Games wird dieses wohl mit Patches verbessern....

Bitte bedenkt, nicht jede Berechnung ist gut zu parallelisieren. In der Kryptographie wird gerade dieses Umstand genutzt, damit die Daten relativ sicher sind.

Ein einfach Beispiel:
Zwei Threads berechnen, das Ergebnis ist ein Haus auf der Karte zu ersetzen.
Thread 1: Eine neue Industrie
Thread 2: Ein neues Geschäftsgebäude

Erstmal kann man nicht beides machen, also gibt es ein Lock, damit es keinen Fehler gibt bzw. die Berechnung eines Threads hätte man sich direkt sparen können.
Das Erstellen der Verwaltungsdaten bedeutet vielleicht mehr Arbeit (Threads aufbauen / Daten synchronisieren) als einfach nur einen Thread anzusetzen.

Jetzt stell dir mal vor, du errechnest welches Signal Grün zeigen soll. Zwei Züge auf die selbe Strecke zu schicken ist keine gute Idee...

Hallo

Kurz und knapp:

• Deine Grafikkarte hat zu wenig Grafiksspeicher. -> Versuche es mit weniger Texturqualität. TF fängt an zu Swapen und lädt die Texturen von der Festplatte.
• TF benutzt zur Hauptberechnung höchstens zwei Threads (zwei CPU Kerne, Version 4831), ein Kern kann einfach überfordert sein.

Eine Analyse zu dem CPU Kern Problem
Eine Teil-Code Analyse mit Linux Debug Daten, Windows Version 4831 und Beobachtung

TF macht im Endeffekt bei einem DayChange:

BuildingSimulator hat mehrere Felder mit Informationen, diese sind mir unbekannt.
Die Informationen in den Feldern ergibt einen Gesamt-Status A, B, C des Train Fever Haupt-Threads.

Im Programcode von BuildingSimulator::DayChange

Ist der Gesamt-Status A:

BuildingSimulator::PrepareThreadData
Mache einen Clone der Engine Teile, vom Transport Netzwerk, Stationen, Linien usw.

Starte einen neuen Thread für die Berechnung (mit den Clone Daten)
-> TF nutzt nun 2 Kerne für das Spiel und berechnet die Häuser im Hintergrund (wohl auch die Einwohner)

Ist der Gesamt-Status B (Monatsende?):
Benutze std::thread::join -> Warte bis Thread 2 fertig mit der Ausführung (Berechnung) ist.
BuildingSimulation::ProcessResult -> Verarbeite die errechneten Daten
TownDeveloper::Run(BuildingSimulation const*)
IndustryDeveloper::Run(BuildingSimulation const*)
und dann werden die Daten wohl weggeworfen.

Gesamt-Status C:
Mach hier gar nichts, der zweite Thread kann gerade im Hintergrund am laufen sein.

Zusammenfassung:
BuildingSimulation::ProcessResult in "Gesamt-Status B" scheint die Berechnung des Thread2 zu nutzen um die Daten im Hauptthread zu ändern.
Umso größer das Transport Netzwerk wird, um so langsamer wird Thread2 da es mehr Daten berechnen muss.

Wenn es gut läuft ist Thread2 schneller fertig in einem Monat als Thread 1. Thread 1 kann die Daten schnell genug im Status B verarbeiten.
Resultat: Spiel läuft flüssig.

Dann gibt es da noch Varianten wenn es hängt:
a) Thread 2 ist zu langsam auf dem CPU Kern, Thread 1 muss warten.
b) Thread 2 ist schnell genug (zwei Kerne werden genutzt, wenn Thread 2 fertig ist, nur noch ein CPU Kern von Thread 1)
Das Zusammenfassen der Daten in Thread 1(Nur ein CPU) braucht zu lange.
c) Thread 2 ist zu langsam (zwei Kerne werden aber genutzt) dann ist das Zusammenfassen der Daten zu langsam (ein CPU Kern wird genutzt)

d) GPU / OpenGL Limitierung. Thread 1 hat schon zu viel Zeit verbraten im Frame um Daten zu Grafikkarte zu schicken. Das Mergen im Thread 1 hat keine Rest-Zeit mehr übrig.
Hier hilft die GPU Einstellungen runter zu schrauben.

Vielleicht versteht Ihr nun warum es keine einfache Lösung gibt und es mehrere Probleme bzw. Lösungsansätze gibt:
- CPU Leistung bei einem Thread ist zu wenig.
- GPU Leistung zu wenig, schaltet die Grafikeinstellungen runter, zum Beispiel Texturqualität.

PS: Da TF sehr viel mit Hashes/Malloc und Locks arbeitet, gibt es da noch CPU cache misses, mutex/lock congestion, memory fragmentation (sehr schönes Beispiel alte Firefox Versionen). Also nicht gerade ein einfache Thema.

Ja. TF hat mehr als zwei Threads offen. Dies kann man zum Beispiel mit Sysinternals ProcessExplorer sehen. Unter anderem für Steam, Soundausgabe, Grafikkartentreiber, ist hierbei um das Thema einfacher zu halten nicht berücksichtigt.

Ich benutzte zur Analyse die erste öffentliche Linux Version für Funktionsnamen (Debugdaten) + Windows Version 4831

Nunja, ich kann nicht behaupten das mein Spiel noch flüssig läuft eher das Gegenteil ... , bin im Jahr 2228. (4. Mods, ne Lok, und zwei org. Fahrzeuge erweitert, und Gleismagnete, Texturen kann man ausschließen )

Steam mag keinen Debugger und lässt TF immer crashen, von außen kann man aber trotzdem etwas sehen.
TF hat eigentlich zwei Threads, 1. TF selber und 2. OpenAL. (Sound) (Die auch Arbeiten und nicht warten)

Am Monatsende wird ein neuer Thread erstellt.

Zwei Möglichkeiten:
a) Thread läuft, Spiel läuft weiter, Thread beendet. (Perfomance wird geringer)
b) TF bleibt mit einer harten Denkpause stehen, wenn der Thread fertig ist/geschlossen wird, geht auch TF weiter.

Wenn ich die Glaskugel nehme, würde ich auf den internen BuildingSimulator tippen, der als neuer Thread gestartet wird.
Es gibt einen Debug String in der Exe, BuildingSimulation::PrepareThreadData und nach dem hängen werden in einer Stadt meistens neue Häuser gebaut.

Zum Thema Threads. Sie sind kein Allheilmittel. Es scheint so das TF erstmal im Hauptthread Arbeitsdaten erschaffen muss. Der Hauptthread scheint nicht immer weiter arbeiten zu können, warum auch immer.
Das kann darin liegen, das ein Lock gehalten wird, es einen allgemeines Locking Problem besteht oder das Locking zu viel Zeit verbrät.

Bei meinem Test war der Thread gerade irgendwo in eine Listenfunktion und die Liste scheint mit "Ist Voll" Fehlern laut Stack beschäftigt zu sein, aber ohne Debugger der auch bei mehreren Threads Probleme bereiten kann ist das immer schwierig.

-edit-
Man kann vieles mit höhere Verarbeitungsgeschwindigkeit per CPU Kern erschlagen. Und ja, Intel Core iX CPUs haben eine höhere Single Thread Performance.

Das war genau anders gemeint, das die derzeitigen Waypoints nicht für Straßen funktionieren und somit nichts bringen. Und wie gesagt, geht es um Strassen bzw. Gleise die eben noch verlegt werden müssen. Eine Option, die anstatt einen Hügel aufschüttet/einen Hang kreiert und eben dann Stützwende nutzt. Oder Objekte die mir ermöglichen eine Rampe/Trog zu bauen auf deren ich dann die Straße/Gleise bauen kann.

Nur für Strassen bringen Waypoints gar nicht und ich möchte Strecken bauen (Strasse/Schiene) wo ja normale Gleise erst gar nicht gehen. Der Häusercode macht ja aus meiner Innenstadt Strecke schon ungewollt Stützwände, nur man kann die Strecke nicht mehr umbauen, da man keine neue Schiene mehr am alten Abschnitt bauen kann. Der Tunnel Portal Code macht mich auch immer wahnsinnig.

Hier nochmals die Zitate, bitte beachtet das es ein beiläufige Anfrage zu einem anderen Thema war, und es nur eine Richtung angibt und keine festen Fakten sind!

Zitat von eis_os

PS: Eine Option um Stützwände zu bauen wäre schön, damit man auch einen Bahndamm durch eine Stadt bauen kann

Zitat von Mikael

Nein Stützwände werden nicht kommen, wir konzentrieren uns auf Bug/Crash-fixing und notwendige Features.

Marcin Grzegorczyk hat das damals für TTDPatch umgesetzt (buildonslopes, so 2004), ich hab das dann auch für unter eine Brücke ermöglicht mit higherbridges. Das hat dem Spiel eine ganz neue Dimension eröffnet...
Leider kann man TF in der Spielmechanik überhaupt nicht in verändern. Optimierter compilierter C++ Code ist kaum zur einer Mitarbeit zu bewegen, auch die Updates werfen eine Analyse immer zurück.

-edit-
PS: Für einen Programmierer ist es etwas anderes ob man nur den Anstrich oder eine Datendatei importiert (sprich Model) oder sagen wir mal den Brückencode ändert. TF zum Beispiel reserviert für Brückenpfeiler Kollisionsdaten und dies unabhängig vom Modell.
Wenn man an dem Code rehen könnte, wären Brücke über vieles mehr möglich. Die Lua Schnittstelle wird nur zum einlesen von Daten genutzt und hat auf die interne Spielmechanik gar keinen Einfluss. Oder Urban Games baut explizit einen Parameter für etwas ein, das ist aber nicht im Sinne neue Problemlösungen ohne Urban Games zu schaffen...