@mila1978 : Bitte die richtige Kategorie/Forum für den Beitrag wählen...
Es gibt auch genügend Beiträge hier im Forum über Geschwindigkeit.
Außerdem, je besser das System so mehr baut man...
Beiträge von eis_os
Willkommen in der Transport Fever Community
Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
-
-
Zu den Städtenamen, diese sind in der Mitte der Städtestruktur.
Das ist dann wie immer: <dword count> <stadtDaten> * count
Aber damit hast Du immer noch keinen Offset dorthin.
Man wird Sie wohl per Hex Editor ändern können. (die Länge muss dann eventuell auch angepasst werden)Wie gesagt das ist alles fieser C++ Code in mehrere Lagen. Die eigentlichen Teile haben keinen Header um die Größe anzugeben, man muss das also wirklich alles lesen um die Struktur zu erhalten...
Eine Lösung, die ich aus Zeitmangel aber nicht umsetzen kann:
Dem Linux Binary eine eigene libstdc++.so.6 per LD_LIBRARY_PATH unterjubeln.
libstdc++.so.6 dann bei jedem Read Call eine Debugausgabe machen lassen mit der (Stream/File)Position, TF starten, Debugger dran klemmen und dann bei jedem Subcall einen Breakpoint, dann hat man erst mal die groben Größen -
Hallo
Theoretisch ja, praktisch nein. Da ein TrainFever Savegame keinen Index hat, - man stellt sich das einfach mal als Buch ohne Seitenzahlen vor -, dann wird das heraussuchen von Daten recht schwer. Wer mag kann ja einfach mal versuchen die Rest Daten zu Entschlüssen. TFSavegamePart.txt (siehe oben) sind das Ergebnis einer Analyse der Debugdaten der ersten Linux Version, genauer gesagt die Calls zu den Subroutinen der Savegame Ladefunktion. Damit hat man aber leider noch keine Größe der Datenblöcke.
Tipp: Die nächsten Daten sind vermutlich die Größe der Heightmap bzw. Kartendaten.
Ob sich die Arbeit lohnt ist dann noch eine andere Frage, zwar ist Urban Games recht offen, aber ich werde Sie wohl nicht dazu bewegen können den Quellcode zu veröffentlichen. Dann wäre das gar kein Problem.
-edit-
Das Interesse scheint außerdem sowieso nicht sehr hoch -
Hallo
Wer mag kann sich ein Build meines Savegame Codec herunterladen, es entpackt, zerlegt und kann auch wieder Savegames komprimieren.
Zurzeit leider nur die ersten Headerdaten....CodeUsage: tfsavcodec <options> file -x extract file -c directory compress directory -v verbose -vv extra verbose --forcedir force reusage of dirVORSICHT: ES IST UNGETESTETE SOFTWARE, NUTZUNG AUF EIGENE GEFAHR!
www.bytetransfer.de/projects/tf/tfsavcodec_2016_03_06.zip
Wer ein Nordic Savegame reparieren möchte bezüglich FileFilter muss die settings.json auswechseln, d.h. von einem funktionierenden sprich neuem Savegame nutzen und das alte wieder mit -c komprimieren...
PS: Ich hab das Posting mit der Struktur geändert (sprich es wird nun als std::vector definiert)
-
C
Alles anzeigen#if 0 Savegame Aufbau: TFHeader TFMods TFSettingsConfig TFAfterSettings => vielleicht CGameTime? TFModelRep #endif #define MAGICNUMBER_TFUNCOMPRESSED 0x2A2A6674 #define TFSAVEGAMEVERSION 0x12 #define struct_TFModDisplayString(_) \ _(field)(tfstring, name) \ _(field)(u32, severity) STRUCT_DEFINE(TFModDisplayString, struct_TFModDisplayString) #define struct_TFHeader(_) \ _(array)(u8, signature, 4) /* 'tf**' */ \ _(field)(s32, savegameversion) \ _(field)(s32, difficulty) \ _(field)(s32, startYear) \ _(field)(s32, numTiles) \ _(field)(u32, date) \ _(field)(s64, money) \ _(vector)(s32, num_mods, TFModDisplayString, mods) \ _(field)(u8, achievementsEarnable) STRUCT_DEFINE(TFHeader, struct_TFHeader) #define struct_TFModEntry(_) \ _(field)(tfstring, name) \ _(field)(u32, unknown) STRUCT_DEFINE(TFModEntry, struct_TFModEntry) #define struct_TFMods(_) \ _(vector)(s32, num_mods, TFModEntry, mods) STRUCT_DEFINE(TFMods, struct_TFMods) #define struct_TFKeyValueString(_) \ _(field)(tfstring, key) \ _(field)(tfstring, value) STRUCT_DEFINE(TFKeyValueString, struct_TFKeyValueString) #define struct_TFSettingsConfig(_) \ _(filepos)(filepos, _filepos) \ _(vector)(u32, numentries, TFKeyValueString, entries) STRUCT_DEFINE(TFSettingsConfig, struct_TFSettingsConfig) #define struct_TFAfterSettings(_) \ _(filepos)(filepos, _filepos) \ _(field)(u8, unknownA1) \ _(field)(u16, unknownA2) \ _(field)(u32, unknownA3) \ _(field)(u32, unknownA4) \ _(field)(u32, unknownA5) \ _(field)(u32, unknownA6) \ _(field)(s32, startYear) \ _(field)(u32, unknownY1) \ _(field)(u32, unknownY2) \ _(field)(u32, unknownY3) \ _(field)(u32, unknownY4) \ _(field)(u32, unknownY5) \ _(field)(u32, unknownY6) \ _(field)(u32, date) STRUCT_DEFINE(TFAfterSettings, struct_TFAfterSettings) #define struct_TFModelRepEntry(_) \ _(field)(tfstring, key) \ _(field)(u32, unknown) STRUCT_DEFINE(TFModelRepEntry, struct_TFModelRepEntry) #define struct_TFModelRep(_) \ _(filepos)(filepos, _filepos) \ _(vector)(u32, numentries, TFModelRepEntry, entries) \ _(filepos)(filepos, _fileposEnd) STRUCT_DEFINE(TFModelRep, struct_TFModelRep) -
Fehler String der Exe: '<parts> size must be 6, 8 or 10'
6 = Bahnsteiglänge 160m
8 = 240m
10 = 320mIch rede hier von parts, nicht von minPlatforms, maxPlatforms, die End Teile für eine Platform sind ja recht kurz.
Das führt aber jetzt zu weit und geht in OT. Also zurück zum Thema.
-
Zur UI und Länge:
Habe einfach in der config eines Testbahnhofs den Eintrag maxPlatforms reduziert.Wenn ich nicht komplett falsch liege, die Plattformen werden aus der "parts"-Liste gebaut. 10 Teile = 320m. Für 80m müsste es dann die richtigen Parts nehmen und auch die Anschlussstücke an die richtige Position setzen.
TF1 funktioniert eigentlich in den meisten fällen nur in einer Richtung, d.h. Game->Lua Daten.
Für ein TF2 wäre mir es lieber wenn die LUA Dateien wirklich auch etwas entscheiden könnten und nicht nur als Datengrab fungieren.
Als Beispiel, bei Schienen wäre es schön die technischen Daten selber anzugeben und einen neuen Schienentyp anlegen zu können, oder eben bei Stationen die Länge, Breite & Co. Erweiterungen von Gebäuden wären auch nicht schlecht...
-
Nee, optimierter C++ Code in Assembler ist nicht so einfach (und auch keine Debug Daten vorhanden) und ein User Interface würde ja dann auch noch fehlen. Da gibt es leider nicht einfach so eine Variable mit Länge, die das dann magisch macht...
-
Hallo
Wegen des Nordic DLCs musste ich mal wieder in der EXE Datei herum wühlen da man die FileFilter nicht ändern kann.
TF Savegames sind "heute" zwei mal mit LZ4 komprimiert.
http://code.google.com/p/lz4/ (Ist mittlerweile auf Github, ich nutze noch eine alte Version, lz4.exe sollte die Daten verarbeiten können)Um ein Savegame zu laden müssen diese auch wieder doppelt komprimiert werden!
Die Header Daten+Config Dict scheinen keine Checksumme zu haben, das restlichen Daten wohl aber!Header 4 Bytes: tf**, danach Savegame Version.
Strings werden als Dword Länge + Char*länge ohne terminierende Null gespeichert = <tfstring>
Beispiel: 0x04 0x00 0x00 0x00 TestHeader Daten
- ?
- Mod Strings <dword> <tfstring>
- Mod Liste <dword Einträge>
- <dword ?> <tfstring>
Config Dict: <dword Einträge>
- Eintrag: <tfstring key> <tfstring value>
- fileFilters: werden an LUA setActiveFileFilter weitergereicht beim Laden
Modell Liste:
- Einträge der Modelle, die Array Position eines Eintrags darf sich nicht ändern, neue Einträge werden hinzugefügt.
- Es wird kein Alt-Eintrag gelöscht, dies würde das Savegame unbrauchbar machen! TF referenziert sehr viel mit einen einfachen Array Index
- <dword refCount?> <tfstring>
Eine Grobe (und sehr alte Übersicht der Daten der Release Version)
http://www.bytetransfer.de/projects/tf/TFSavegameParts.txt -
Das Problem liegt wohl eher in der Erklärung der Signale.
Für die ersten Strecken in Transport Tycoon brauchte man keine Signale, bis man eben mehr bauen will.Die Kunst & Kür ist es ja ein Einsteiger freundliches Spiel zu schaffen, aber dann immer noch genügend Möglichkeiten zu bieten.
TF hatte da echt ein Problem, ohne vernünftige Anleitung ist es Spiel nicht so tolle. Und das UI und die Rückmeldungen bringen einen schon mal zum verzweifeln. Wenn man eine Brücke, Tunnel im dritten Anlauf immer noch nicht bauen kann, stimmt was mit dem Spiel nicht...Transport Tycoon hatte schon eine Art Video Anleitung im Spiel. Auch wenn die KI doof war, es hat den Spieler auch ein paar grundlegende Sachen gezeigt. Und ich verstehe es nicht warum in letzter Zeit so viele Spiele mit so schlechten UserInterface raus kommen.
Zu TF2:
Mehr Gewichtung auf UI. (und wenn man es nicht selber machen kann, jemanden für den Feinschliff anheuern oder ein Interface bieten)
Sinnvolle Einsteiger Informationen. ** Das ist nicht für mich selber, aber es hilft echt wenn man jemanden anderes das Spiel erklären will.
-
Es ist eben die falsche Antwort, wenn Windows den nutzbaren RAM + die Auslagerungsdatei voll hat, einfach die Auslagerungsdatei zu vergrößern.
Eine Auslagerungsdatei ist zu Auslagern da, Du willst bei einem Spiel nie Auslagern! Auslagern ist langsam und für den "Notfall".
Also: Warum ist der RAM voll?
a) Zu viel im Hintergrund => Räume auf. Installiere keine Optimierungssoftware die im Hintergrund läuft, jede zusätzliche Software im Hintergrund braucht CPU Zeit und RAM!
b) Ich hab eine Große Karte und/oder komplexe Karte => brauchst mehr RAM wenn es nicht mehr passt.
c) Ich nutze eine 32Bit Applikation, dann ist 2GB (bis auf spezial Ausnahmen) das Limit für die Applikation. (Train Fever gibt es in 64Bit und 32Bit, letztere lässt schon Beispiel keine großen Karten zu)
d) Ich nutze nur ein 32Bit Betriebssystem => Hat dein Rechner mehr als 3GB Ram, brauchst Du ein 64Bit Betriebssystem...
e) Software ist "kaputt". Software kann ein Speicherleck haben und immer mehr Speicher nutzen... (dazu zählen auch Grafikkarten Treiber bzw. Treiber im Allgemeinen)
f) Ich hab ganz viele Mods installiert => Tja, Antwort ist wohl naheliegend. Mehr RAM oder weniger Mods.
g) Grafikkarte hat zu wenig Speicher => Der Grafikkarten Treiber betreibt swapping, weniger Texturen, Texturqualität reduzieren (TF komprimiert die Texturen dann)z) Extrem seltener Fall: Speicherfehler, Anwendungen arbeiten inkorrekt und brauchen viel Speicher... (Das merkt man aber sowieso das das System sehr unrund läuft und vieles stützt ohne Grund ab) => Service Fall
-
Mal Popcorn holen...
Große Anwendungshersteller :o) ... damit hab ich immer meinen Spaß und mit der Hardware Industrie auch...
Kleine Kostprobe?
Aussage: Intel x86_64 ist "viel besser und kompatibler" als AMD x86_64. Dumm nur das ich Ihn dann auf das ganze *AMD64* Windows Zeugs auf seiner Intel Maschine hingewiesen habe.
Anwendungssoftware Entwickler und deren Software hab ich wirklich gefressen.
Man soll X bei Kaufmännischer Software machen um Problem Y zu lösen, mein Einwand das denn die Daten weg wären, "ach wirklich, aber danach funktioniert es wieder!"
Auch nett, mal solle bitte die Soundkarte ausbauen, o-ton Mainboard Hersteller, dumm nur das es schon so ein neu modisches Teil mit "onboard" Soundadapter war, und dieser leider den Fehler verursachte...Also bitte fangt nicht an Wild eurer Windows/Bios/Linux Einstellungen zu verändern nur weil Anwendung X nicht funktioniert, auch gibt es nicht ein Patent-Rezept X.
Und bei Lösungen des Supports von Herstellern von Anwendungssoftware zweimal hinterfragen was die da sagen.PS: Die "10 wichtigsten Tipps" für Linux bzw. Ubuntu gibt es leider mittlerweile auch, inkl. deren folgen...
-
Hätten wir besseren RAM Durchsatz, alles wäre gut.
Fakt ist das TF beim Sync der Threads bzw. der Daten (und wir reden hier von Gigabyte an Daten) einfach irgendwann nicht mehr fertig wird in einem Monat.
TF macht diese Berechnungen nicht (mehr) im MainThread...Das hatte ich ja schon mal hier aufgeführt. (Es ist zwar besser geworden, das Grundprinzip in TF blieb aber bestehen)
Was macht TF Intern und warum es ruckeltBei TF ist das Problem eines Feedback-Loops. Am Ende eines Monats muss alles wieder zusammen kommen, da der nächste Monat auf die Vormonats Berechnung basiert.
Der ganze C++ STL Container "Müll" macht die Sache nicht einfacher. Vielleicht würde ein -Os Kompilat für alte/große Spielstände wunder bewirken, wenn der Compiler mehr in den CPU Cacheline bekommen könnte. -
Hello
It would be nice if you could tell us the specification of your Notebook.
Tom send you a link if you have a Nvidia Error Code 3 Problem, I don't think that will help.Technical Windows should restart your VGA Driver (you never mentioned if you use Intel, NVIDIA or AMD/ATI Graphics) or at least restart the whole system.
Does the system keeps playing music?When it's a hardware fault, the most common problems are: overheating, bad memory and hard disk errors.
Software side: Bad VGA Drivers, Anti Virus.Btw, I replaced your topic tag to unresolved.
-
Deutsch 
Das ist nur ein kleiner Test
English 
Only a small test
Dette er blot en lille test
Français 
Ceci est juste un petit test
Scheint halbwegs zu funktionieren
-
Imho, den Rauch abstellen ist eine "Lösung".
Aber wenn Ihr anfängt die Statistiken des Spiels zu ändern ist es keine Lösung. Wenn Ihr im Gameplay weniger Berechnungen verursacht dann führt das natürlich zu einer Perfomance Steigerung.
Auch wenn Ihr das Spiel pausiert, und nichts ändert, haben Hintergrund Berechnungen mehr Zeit.Bedeutet also:
Testen nur mit der selben Hardware, Software und mit einem langsamen Savegame unter kontrollierten Bedingungen. Kein Steam Overlay oder andere Software u.s.w.Ganz einfach:
Umso mehr mögliche Verbindungen es gibt um so mehr muss berechnet werden.
Umso mehr Einwohner es gibt um so mehr Verbindungen müssen für diese auch berechnet werden.
Da der Individualverkehr ansteigt, wird ein Spiel um 1940 natürlich immer schneller laufen als im Jahr 2000.
Und es ist natürlich auch etwas anderes ob man 100 Cargo Verbindungen betreibt oder Passagier Verbindungen hat.
Darüber hinaus wird die Sache komplexer je mehr mögliche Verbindungsvarianten man betreibt oder es gibt.So sind Zahlen wie Jahr, Passagiere und Anzahl der Verbindungen keine Grundlage als Messgrößen her zuhalten ohne Kontext und können niemals als Vergleich herhalten
-
Also wenn das Heranzoomen zu Performance Problemen führt ist eher ein Indiz für Grafik Render Problemen. HDR, Schatten runter stellen.
Die späteren Gebäude haben ja Spiegellungen, die brauchen mehr Grafikpower...Für alle anderen auch als Tipp:
TF hat ein sehr eigenwilliges Textur verhalten während des Spiels und greift sehr oft auf Texturdateien zu, zumindest in früheren Versionen. (Das hab ich damals auch mal bei UG angemerkt)
Am besten beim Virenscanner die TF Textur Ordner als Ausnahme hinzufügen, oder eben alle Datenverzeichnisse. -
Achtet mal wenn es mehr Zeit am Monatsende als Normal verbracht hat,
ob eine Stadt expandiert hat bzw. neue Gebäude erstellt werden.
(Es sind ja auch irgendwann neuere moderne Häuser verfügbar)Technisch sah ich da ein mögliches Problem in der Stadtentwicklung als ich die Thread Routinen untersucht habe, wenn ich mich recht erinnere lief da ein Teil nach dem Thread Join ab, das kann sich aber mittlerweile geändert haben. Zumindest hat TF riesige Listen erstellt und das auch nicht sehr performant.
Das wäre so viel einfacher wenn man den Quellcode hätte
-
Warum, passt doch zur Realität - macht die Bahn/Bund auch so...
Einfach ein paar Strecken abbauen. Solange UG nicht auf die Expertise von Mehdorn vertraut wird alles gut... -
Ich versuch mal ein paar Fragen abzuarbeiten.
Performance: HDR und Schatten abschalten hilft bei GPU Leistungsproblemen.
Nicht zu viele Linien bauen, ich kann jedes Spiel mit Monatsende Probleme verbessern indem man alle Linien und Züge entfernt
Debugdaten:
Ich hab mir die erste Linux Version gespeichert, und auch die ersten Mac Versionen per Steam Client besorgt. (Da waren sie gerade Aktuell)
Dann kann man in die Trickkiste greifen, da Urban Exception nutzt, kann man über die Fehlermeldungen auf die Funktionsnamen schließen.Die generelle Performance ändert aber nichts an den internen Strukturen.
Thread Join, dies ist ein Beispiel zu Veranschaulichung:
Sagen wir haben den Status der Industrielieferketten:Haupt-Thread bewegt die Züge und macht das "Tagesgeschäft"
Nebenthread errechnet neue Lieferketten.Am Ende des Monats, der Haupt-Thread benutzt noch die alten Daten.
Was passiert nun?Thread-Join, die Nebenthread Daten werden genutzt um die neuen Lieferketten zu bestimmen.
Unterschied zu deinen Pixel Beispiel. Dein Pixel hat nur bedingte Auswirkung auf die Nachbar-Pixel, meist stellt man einen Radius ein, bzw. intern gibt es einen.
Das ist aber bei einer Wirtschaftssimulation nicht möglich. Das ist so ähnlich Fall zwischen Datenbanken, man kann bei bestimmten Sachen mit eventuell Konsistenz leben. Du möchtest aber auch nicht ein Bankkonto haben, das eventuell Konsistent ist, also der Guthaben-Betrag mal da ist und mal nicht, oder deine Bank einen Dauerauftrag nicht ausführt weil die letzte Abfrage ein eventuell falsches Ergebnis hat.Alle Algorithmen sind viel einfacher wenn man kein Feedback Loop hat.