Beiträge von VacuumTube

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


    Dass es NICHT an Optimierungen der CPU liegt sieht man, wenn das Spiel paust. Hier werden ja keine Wege berechnet, weshalb die FPS hochschießen müssten. Tun sie aber nicht. D.h. es ist ein reines Grafikperformance-Problem des Spiels. Und meiner Meinung liegt es an den zu hohen Entfernung der LOD-Modelle. D.h. es werden viel zu viele Fahrzeuge auf ein mal angezeigt, von denen ein großer Teil ausgeblendet werden könnte.

    Stimmt grundsätzlich. Die FPS sind sogar unabhängig von der Simulation: Wenn man zu viele Einwohner hat oder vorspult, gibt es zwar Simulationsruckeln, aber die FPS bleiben konstant. Simulation und Grafik laufen in TPF2 in getrennten Threads und haben dabei prinzipiell andere Limits. Daher muss man Grafik- und Simulationsperformance immer getrennt bewerten.

    Mehr Infos in meinem Lexikonbeitrag: FPS Anzeige/Messung/Analyse (den ich mal aktualisieren müsste, aber grundsätzlich noch stimmt)


    Lods sind für eine gute Grafikperformance essentiell. Einerseits muss es genug geben (i.d.R. mind. 3, für Fahrzeuge eher 4), andererseits müssen die Abstufungen (Tris und Einblendedistanzen) sinnvoll sein. Daher kommt es immer drauf an! Im Idealfall will man ja entfernte Autos gerade noch so sehen und für eine gleichzeitig gute Performance müssen sie bei hoher Entfernung minimal wenig Tris haben. Das ist möglich. In TPF2 sind aber viele Vanilla Modelle nicht so gut optimiert. Das kann bei Mods ebenso und noch viel schlimmer sein.


    Wer schnell mehr Performance durch weniger Gesamt Tris haben will, kann natürlich einfach den globalen lodDistanceScaling Faktor verringern. Das Ergebnis sieht aber nicht schön aus. Ebenso gibt es eine Lod Balancing Mod von homieforever, wo man sogar für jeden Objekttyp den Lod Faktor anpassen kann. Das ist aber auch keine Superlösung, da Objekte mit vielen Tris ohne gute Lods am Ende ja nur ausgeblendet werden können.

    Es gibt auch: CargoLODs

    Laden von require "serialize" dauert bei mir 20ms. Also hält sich die Optimierung in Grenzen. Außerdem wird es ja gebraucht, spätestens beim Speichern.


    Joa eine Doku Übersicht von allen globalen Funktionen, die verwendet werden können, wäre sicherlich eine nette Sache.

    Wie kommst du drauf das Emiliocat nicht die Steamversion nutzt?

    Na mir geht es um die Mod. Und da nutzt er laut stdout die Forumsversion: Build_with_collision/1 (1) (Build with Collision)

    Daher ist das in dem Kontext verwirrend.

    Ob Steam oder Gog ist ja egal. Höchstens auf die Build Nr kommt es an, aber auch nur in Sonderfällen und aktuell gibt es eh keine Updates.


    Damit auch ein lua Laie wie ich das mal versteht, wenn das so wäre und es so sein muss, wieso hat dann nur ein Nutzer von 1000 einen Absturz? Er wird ja wohl kaum der einzige sein der Windows benutzt.

    Gerne erkläre ich den Fehler, da ich auch gestern lange nachforschen musste, was eigentlich das Problem ist.

    Wie es in solchen Fällen eben passieren kann, ist die Ursache eine Verkettung von seltenen Umständen.


    Zunächst zu der Aussage, es wäre ein Groß/Kleinschreibung Problem mit Windows/Linux: Das gilt nur für Dateinamen. Nicht für Lua Variablen.


    Ein Fehler in einer Fehlerbehandlungsroutine wird sich tatsächlich sehr selten bemerkbar machen.

    Das stimmt grundsätzlich und ist der 1. Grund, warum der Fehler selten auftritt. Die Stelle wo der Fehler passiert, wird nur ausgeführt, wenn das "Build Anyway" Proposal schiefgeht und nicht ausgeführt werden kann (critical=true). Das passiert anscheinend nur bei Straßen Upgrades und auch da nur selten. Warum weiß ich auch nicht. Man könnte das einfach ignorieren, ich schreibe aber noch etwas in die stdout in dem Fall.


    Ich habe diesen Fall jedoch bei mir natürlich getestet und es hat alles ordnungsgemäß funktioniert.


    Das sehe ich wohl auch so, tostring ist ja eher von .net

    tostring ist eine Standard Lua Funktion und immer verfügbar. Sie ist leider nicht besonders brauchbar, da man damit keine tables darstellen kann.


    In TPF2 gibt es auch noch toString, diese Funktion wird in serialize.lua definiert (als globale Variable).

    Die habe ich in der Vergangenheit öfter ohne Probleme genutzt. toString ist etwas flexibler als debugPrint, da man damit auch einfach mehrere Sachen gleichzeitig printen kann.


    toString() ist hier tatsächlich nicht definiert.

    Warum gab es jetzt bei mir toString und bei ihm nicht?

    Ich habe meinen Testspielstand nur mit BWC geladen und konnte den Fehler direkt reproduzieren. Dann habe ich nach und nach Mods dazugeladen und getestet. Tatsächlich ergibt sich ein sehr verwunderliches Verhalten wenn man zum Testen in die Konsolte debugPrint(toString) eingibt: Zuerst ist es false aber wenn man es nochmal eingibt ist es <function>.


    Warum??

    Dazu werfen wir einen Blick in die init.lua. Diese wird von TPF Seite aus zum Initialisierung eines Lua Threads ausgeführt. Dabei werden jede Menge globale Variablen und Funktionen, die in TPF verwendet werden definiert, die über die Standard Library von Lua hinausgehen. Zb table.copy, string.starts, math.round oder die Übersetzungsfunktion. (Übrigens: jeder Modder kann diese Funktionen guten Gewissens verwenden, da sie ja immer vorhanden sind). Und eben auch debugPrint:


    Warum UG hier das require "serialize" innerhalb der debugPrint funktion hat: keine Ahnung. Jedenfalls erklärt das auch das seltsame Verhalten.

    D.h. Erst falls irgendeine andere Mod erstmalig debugPrint aufgerufen hat, ist toString definiert!


    Der Fix ist also recht einfach: https://github.com/Vacuum-Tube…0102f56d7c82011ece685ff5a

    ...sind kostenlos? Ernsthaft?


    Das heißt leider, dass parameterabhängige Kosten nicht wirklich im Spiel umgesetzt werden können.

    Beim ersten Bauen verändert sich der Preis zwar korrekt. Aber danach kann man die Konstruktion bzw. Parameter verändern wie man will, ohne Einfluss auf den Kontostand.


    Und wenn, könnte das kritisch werden, da hohe Kosten nicht abgefragt würden. Daher meine wiederholte Bitte an das Redesign des Konstruktion Upgrade Menü. Das war in TPF1 viel besser! Man konnte zB sehen, ob und wo es Kollisionen gab. In TPF2 klickt man nur die Parameter und wenn es Probleme gibt, passiert einfach gar nichts. Und Fehler werden nicht abgefangen...

    Was ist 7554181 ?


    Laut stdout benutzt du nicht die Steam Version.


    Das Bauen mit Kollision war in dem Fall nicht erfolgreich. Das kann bei Straßen Upgrades hin und wieder vorkommen. Das sollte eigentlich auch nur zu einer stdout Meldung kommen. In deinem Fall ist komischerweise eine Standardfunktion nicht aufrufbar.

    Das dachte ich auch. Passt ja alles in meine 32gb Ram und hatte deswegen die Auslagerungsdatei abgeschaltet...

    Pustekuchen. Dies Auslagerungsdatei wird trotzdem benötigt.

    Sprich, im Taskmanager im laufenden Spiel schauen, ist der RAM voll? Wenn ja, dann ist halt essig. Nur mehr RAM hilft und alles andere nicht laufen lassen.

    Der Taskmanger ist doch da eher suboptimal, da Windows die reale RAM Auslastung eher verschleiert. Man denkt, es wären noch einige GB frei, aber wenn TPF2 mehr RAM kriegt, nimmt es ihn auch. Eigentlich muss man den Ressourcenmonitor nehmen. 32 GB reichen wahrscheinlich für große Karten nicht mehr aus.


    Natürlich wäre es schön, wenn ein Spiel die CPU vollständig ausfüllt. Ich kenn aber keines, das mit Verkehr genau dies kann. Auch ein Cities Skylines ist lediglich gut optimiert, hat aber ein hartes Limit auf 16k Fahrzeuge weil die (Verkehrs)Engine nicht (oder kaum) parallelisiert ist.

    Das würde ja heißen, dass das Optimierungspotential bei TPF2 gar nicht mal soo hoch ist.

    Aber was irgendwie bisher keiner erklären konnte: Warum das Limit bei TPF2 bei etwa 25k Agenten liegt, während TPF deutlich mehr simulieren konnte. (Und das obwohl TPF weniger multithreading fähig war).


    Und Flüssig heißt im Falle von Cities Skylines durch aus auch, das es in Zeitlupe ablaufen kann. Die Echtzeitberechnung passt sich der Leistungsmöglichkeiten und der Komplexität der Geschehnisse an.

    Interessant, denn genau das wurde bei TPF2 ja auch gemacht. Was ja auch von vielen kritisiert wurde - weil es eben das Problem nicht wirklich löst, sondern verschleiert. Und sich dann Spieler fragen, warum ihr Zug anscheinend 100 fährt, obwohl es aussieht wie 50.

    dass ich reichlich Geld für das Spiel bezahle

    Naja in deinem Fall vernachlässigbar im Vergleich zur Hardware... ^^


    Man kann nicht vom Endkunden erwarten sich eine NVME kaufen zu müssen aufgrund irgendeiner Auslagerungsdatei -> die eine SSD in meinem Fall eine handelsübliche um das 12 fache übertrifft. 7000MB Read/5000 MB Write)

    Noch besser als SSD wäre für TPF2 (noch) mehr RAM ... dann wird die Auslagerungsdatei gar nicht gebraucht.

    Hast du nach den Windows Einstellungen zur Auslagerungsdatei geschaut?


    Was mir jedoch aufgefallen ist das ein Kern durchgehend auf nahe zu 100 % läuft. MultiThreading wird wohl nicht so wirklich unterstützt von TF2 ?

    Das ist im Hauptmenü, wo es keine Performance Probleme gibt und daher die Info nutzlos.


    Konntest Du etwas erkennen an den Screenshots?

    Also es handelt sich schonmal nicht um ein Mod Problem. In den Draw Calls stechen zwar die Hecke sowie Stadtgebäude Lod1 hervor, was aber bekannt ist und im Grundspiel nicht optimiert wurde. Somit ergeben sich 3,7 Mio Vertices, was für diese einache Szene verhältnismäßig viel ist, aber für deine Grafikkarte kein Problem sein sollte.

    Sie berechnet das in etwa 3 ms, bei den anderen Timings ist auch nichts auffälliges. Intern sollten die FPS bei 87 sein, wobei das am Ende immer ein Stück weniger ist. Ich sag mal 40 wäre noch normal, 24 wäre in der Tat ungewöhnlich wenig. Das kommt dann drauf an was außerhalb von TPF passiert, also wird irgendein Problem im Zusammenspiel mit GPU, CPU und RAM sein.

    also du solltest schon mal schauen was ich den Performance-Tips genau geschrieben habe, das geht mir jetzt arg Richtung Rechthaberei. Der Konverter sollte nicht aktiv sein, aber da es Leute gab die mit aktiviertem Konverter gespielt haben und sich dann über Mikroruckler gewundert haben, ist dieser Tip mit eingeflossen.

    Die Aussage, dass der Konverter Mikroruckler verursacht, ist so nicht haltbar. Der Konverter läuft ausschließlich über die runFn function welche im laufenden Spiel nicht aktiv ist.

    Nenn es Rechthaberei, ich wollte es einfach nur klarstellen.


    Natürlich kann ein Bechmark neue Erkenntnisse bringen. OP hat sich doch grad erst neue Hardware gekauft? Er hat uns außerdem nicht gesagt, ob es bei anderen Spielen einwandfrei läuft.


    Nur weil du die internen TPF Diagramme nicht hilfreich oder irreführend findest... Man muss sie halt richtig interpretieren. Natürlich geht es nicht darum einzelne Bären zu messen. Neben den % sind ja auch die Gesamt Vertices relevant. Wenn die abartig hoch sind, können die FPS natürlich nicht gut sein und darüber kann man die verantwortlichen Meshes finden. Sie sind die einzige Möglichkeit genauer in die Performance des Spiels zu schauen.



    Debug Log Ausgaben während des Spiels (Ich hab trotz 300000 Logeinträgen bezüglich Animationsstest immer noch 20 Frames, aber man merkt es dennoch)

    Okay, das sollte ja während dem normalen Spielen nicht der Fall sein


    Verhinderung der Städte KI sich auszubreiten. -> Wer meint via Kollisionsobjekt die Ausbreitung der Stadt zu verhindern braucht sich nicht wundern.

    Interessanter Punkt... wobei das ja im Engine Thread ablaufen müsste und somit nicht zu FPS Einbrüchen, sondern alle 20 Sekunden (townDevelopInterval in der config ist übrigens kaputt) zu Simulationsruckeln führen könnte. Jedenfalls noch ein Grund ohne "KI" zu spielen...

    Hauptursachen würde ich jetzt nicht sagen.

    Der Konverter ist im laufenden Spiel nicht aktiv und kann daher auch keine Performance Auswirkung haben. (Natürlich sollte er nicht aktiviert sein)

    Ein regelmäßiges Löschen des texture_cache ist nicht nötig und erhöht gerade die Ladezeiten, da die Texturen ja dann neu gecached werden müssen.


    Zur Auslagerungsdatei:

    Ich habe das geschrieben, weil es hier wirklich mehrere Fälle gab in denen das wie oben beschrieben vorkam und nach Anpassung die Performance verbesserte. Er hat ja 2 HDDs. Im Normalfall hat man die Auslagerungsdatei natürlich auf "automatisch verwalten" stehen. Was in den allermeisten Fällen dann auch ausschließlich die SSD ist.


    Der Benchmarktest soll klären, ob es sich um ein reines TPF Problem handelt.


    Wenn ja, sind die TPF Diagramme mMn der beste Weg, die internen Performance zu analysieren. ZB ob Performance Fresser Mods die Ursache sein könnten.


    Am Ende hängt es auch viel davon ab, wie man spielt, dadurch kann man auch viel steuern. Ob man sich zig 4K Mods installiert (und verwendet) oder ob man nur wenige unterschiedliche Fahrzeuge nimmt, ob man es mit den Einwohnern und Städten übertreibt oder Einwohner-mindernde Mods nimmt, ob man sich einen Bereich vollbaut oder in der Fläche verteilt usw. Und davon hängt auch ab, welche Hardware am ehesten hilft, wenn ich voll auf Simulation gehe wird mir keine 3090 helfen.

    Der Lexikon Eintrag "Performance Tips" sollte nicht zu ernst genommen werden.... die punkte sind sehr selektiv und haben teilweise gar keinen Einfluss auf die Performance.


    Das Thema Performance ist sehr umfassend und man könnte ein Buch drüber schreiben, wenn man die Zeit hätte...


    Ja, das Spiel nutzt anscheinend kaum mehr als 4 Kerne.

    Ja, es gibt Hardwaretechnische Grenzen.

    Trotzdem ist ein solches Verhalten bei dieser Hardware ungewöhnlich.


    Ja, es gibt Spiele, die zeigen, dass es viel besser geht.

    Ja, UG ist ein kleines Studio.

    Ja, man gewöhnt sich an TPF2 und seine Performance.

    Ja, ich bin auch süchtig nach dem Spiel.

    Trotzdem darf man auf diese Probleme hinweisen und sich ärgern.


    IntrepidKlasse

    Um ein Hardwareproblem auszuschließen:

    Läuft ein Benchmarktest ohne (Hitze) Probleme mit 100% durch?


    Du möchtest bitte folgendes überprüfen:

    Wird die Auslagerungsdatei nur auf deiner SSD verwendet oder kam Windows auf die Idee eine HDD zu nutzen? Das kam hier hin und wieder vor und war eine Ursache.


    Dann kann man die Performance inerhalb TPF2 testen:

    Einmal mit AltGr+i die Frame Times. Hier wäre ein Diagramm bei hohen Ausschlägen interessant.

    Außerdem die Draw Calls (AltGr+D). Den Tab auswählen und dann nach % sortieren. Auch hier bitte ein Screenshot, wo die FPS besonders hängen.

    Der Takt ist tatsächlich nicht direkt wichtig fürs spielen. Die Anzeige ist natürlich trotzdem sinnvoll und dient zur Abschätzung. Wenn man viele Fahrzeuge kauft, sieht man wie hoch der Takt sein wird, wenn sie gleichmäßig verteilt sind. Bei hoch getakteten Linien kann man bei Taktzeit<Wartezeit (~10-15s) schon den Stau voraussehen.

    Ist es möglich, ein Upgrade einer Konstruktion, zB Industry Up/Downgrade erfassen?

    Mein gamescript würde das gerne mitbekommen, um darauf zu reagieren und nicht kontinuierlich die entsprechenden Daten abfragen zu müssen.


    Bisher habe ich kein Gui oder Script Event dazu gefunden.

    Außerdem hat man in der updateFn keinen Zugriff auf die Api, sodass man dort auch kein Event senden kann.