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
Sowohl im Hauptmenü als auch weiterhin während des Spielens, hab den Beitrag entsprechend editiert.
Auf dem 2. Gerät, von welchem tcpdump & der Screenshot sind, ist kein einziger Mod abboniert, alles rausgefiltert. Verhalten genau gleich zu meinem Desktop mit vielen Mods.
Steam Offline-Modus ändert auch nix.
Warum sollte man Wine / Proton noch dazwischenschalten?
Das ist doch durchgeknallt, gerade wenn man Ressourcen sparen will, startet man doch nicht auch noch einen Wine/Proton Server im Hintergrund..
Bei einer Menge spielen ist die Performance der Windows-Version unter Proton deutlich besser als die Native Linux-Version, z.B. Arma 3, Cities:Skylines, Civ 5 & 6
Bei Tpf2 habe ich es nie getestet.
Die WINE-Entwickler betonen den geringen Overhead von Wine auch. Es hängt viel mehr davon ab, ob & wie oft ein Windows Programm syscalls verwendet, die sich nicht direkt mappen lassen.
Ebenso kann ein Linux-Port eines Spiels viel Performance liegen lassen, wenn es an Stellen wo moderne APIs verwendet werden könnten, steinalte benutzt. UG hat bei Tpf2 von Steam extra ein launch-skript, welches bei Verfügbarkeit statt der mitgelieferten liburing-Version die auf dem System bzw. dem Steam Runtime Environment installierte Version nutzt.
Mich wundert eher warum die Auswirkung nur bei TPF zu spüren war und der Rechner nicht direkt abgestürzt ist.
Tpf2 hat bei mir als 1. Rechnerabstürze getriggert , als die DRAM Spannung nicht für das XMP Profil ausgereicht hatte. Allerdings hat mein Mainboard auch nen Designfehler in der Elektrik. Tpf2 scheint wohl ein guter Stresstest zu sein.
Kannst du die *.dmp Datei komprimiert hochladen? Das was du gepostet hast, ist nur der Log. Zwischen dem Ladestart der Mod und dem Hänger könnte noch was anderes passieren werden. Oder selbst in den Dump reinschauen und den call trace posten.
Hallo,
ich habe festgestellt, dass während Tpf2 läuft bei mir ~50GiB Netzwerktraffic die Stunde durch das loopback interface gehen. Hauptmenü oder Spielstand machen keinen Unterschied. Da Steam darüber IPC macht, bin ich mir ziemlich sicher, dass es IPC zwischen Steam & Tpf2 ist. Warum das bei TpF2 so Berserker geht und bei anderen Linux-nativen spielen nicht, kann ich allerdings nicht erklären. Da aber ständig TCP-Verbindungen geöffnet & wieder geschlossen werden (siehe tcpdump & perf report screnshot), gehe ich davon aus, dass es ein Bug ist. Habe Tpf2 nochmal auf einem anderen Gerät ohne Mods oder irgendwelche Sondereinstellungen installiert, selbes Problem. Hoher Traffic nur im Hauptmenü, nicht im geladenen Spiel & um den soll es hier erstmal nicht gehen.
Ist das Problem bekannt bzw. falls ihr auf Linux via Steam spielt, könntet ihr bitte überprüfen ob dies bei euch auch so ist? Einfach mit b(py)top schauen ob der Netzwerktraffic auf dem lo Netzwerkinterface nach dem Spielstart massiv nach oben schießt.
Unten links im Screenshot kann der Netzwerktraffic gesehen werden.
tcpdump von lo interface (20s Tpf2 und schon so viel Pakete, dass das Logfile zstd komprimiet zu groß für hier ist, entpackt sinds 270MiB)
Übersicht vom perf tool:
Samples: 207K of event 'cpu/cycles/P', Event count (approx.): 208665074754
Children Self Command Shared Object Symbol
+ 72,33% 0,00% TransportFever2 libc.so.6 [.] 00007fb27d7292bc ◆
+ 72,33% 0,00% TransportFever2 libc.so.6 [.] 0x00007fb27d6a597a ▒
+ 72,33% 0,00% TransportFever2 libstdc++.so.6.0.34 [.] 0x00007fb27d8e55a4 ▒
+ 70,81% 0,00% TransportFever2 TransportFever2 [.] 0x0000563b802df407 ▒
+ 70,69% 0,00% TransportFever2 libc.so.6 [.] pthread_once ▒
+ 70,69% 0,00% TransportFever2 TransportFever2 [.] 0x0000563b7daf1172 ▒
+ 70,58% 0,00% TransportFever2 libc.so.6 [.] 0x00007fb27d6aada4 ▒
+ 70,57% 0,00% TransportFever2 TransportFever2 [.] 0x0000563b7daf0e22 ▒
+ 31,79% 0,00% TransportFever2 TransportFever2 [.] 0x0000563b7dd580b5 ▒
+ 18,77% 0,00% TransportFever2 TransportFever2 [.] 0x0000563b7dd6177d Reingezoomt auf syscalls beim obersten call:
Samples: 207K of event 'cpu/cycles/P', Event count (approx.): 208665074754, DSO: [kernel.kallsyms]
Children Self Command Symbol
+ 2,67% 0,06% TransportFever2 [k] do_syscall_64 ◆
+ 2,65% 0,01% TransportFever2 [k] entry_SYSCALL_64_after_hwframe ▒
+ 0,75% 0,02% TransportFever2 [k] __tcp_transmit_skb ▒
+ 0,71% 0,02% TransportFever2 [k] __ip_queue_xmit ▒
+ 0,68% 0,01% TransportFever2 [k] __x64_sys_sendto ▒
+ 0,65% 0,01% TransportFever2 [k] tcp_sendmsg ▒
+ 0,64% 0,02% TransportFever2 [k] tcp_sendmsg_locked ▒
+ 0,62% 0,01% TransportFever2 [k] ip_output ▒
+ 0,58% 0,01% TransportFever2 [k] ip_finish_output2 ▒
+ 0,57% 0,01% TransportFever2 [k] handle_softirqs ▒
+ 0,56% 0,01% TransportFever2 [k] __dev_queue_xmit ▒
+ 0,55% 0,02% TransportFever2 [k] __x64_sys_futex ▒
+ 0,55% 0,02% TransportFever2 [k] tcp_write_xmit ▒
+ 0,54% 0,00% TransportFever2 [k] __tcp_push_pending_frames ▒
+ 0,53% 0,01% TransportFever2 [k] asm_sysvec_apic_timer_interrupt ▒
+ 0,52% 0,02% TransportFever2 [k] __local_bh_enable_ip Grüße
Oskar
Wenn einfach nur die Distanzen größer werden und die Städte-Dichte (und damit Daten-Dichte) sich reduziert (sprich gleichbleibende Städtezahl bzw auch Industriezahl auf mehr Platz), dann sollte die Rechenleistungssteigerung moderat ausfallen. Klar hat man dann mehr Gelände zum Darstellen, aber das wird nicht so sehr ins Gewicht fallen
Die TransportFever Reihe regelt die Gütermenge auf einer Linie dynamisch mit Betrachtung des aktuellen Angebots & der Nachfrage. Wenn die Umlaufzeiten in einer Linie sehr groß werden, ist die Regelstrecke sehr groß und fängt an stark zu schwanken. Das kannst du jetzt schon auf Mega-maps mit Zügen mit nordamerikanischer Länge, bei der Güter die ganze Map fast 2x überqueren können, feststellen. Die Regelungstechnik in Tpf2 kann da nicht mehr eine gute Spielerfahrung bereitstellen.
Dazu kommt noch das Problem mit sinkender Fließkommazahlengenauigkeit, ob das bei aktuellem Megal. schon Auswirkungen hat, konnte ich bisher nicht feststellen.
Wenn das Wetter einen echten Einfluss auf den Verkehr haben soll, dann bitte nur optional. Als Beispiel mal wieder Anno, diesmal das alte 1404. Da konnte man nach dem Venedig-Addon auf Vulkaninseln siedeln. Ab und zu sind diese Vulkane auch ausgebrochen und haben alles rundum verwüstet, oft auch mit Lavabrocken Schiffe versenkt. Zumindest mich hat das recht bald genervt, war aber nur vermeidbar, wenn man die Vulkane ganz weggelassen hat.
Die Vulkanausbrüche in Anno 1404 würde ich eher mit Erdbeben in Workers & Resources vergleichen. Auch wenn die alles extrem auf den Kopf stellen können, ist die Wiederaufbaumechanik jedoch gut genug, um die spielbar zu machen. Großes Problem bei TpF könnte das Despawnen von Gebäuden sein, sobald die Warenkette einbricht. Imho muss die Rückbau-/Vernachlässigungsmechanik überarbeitet werden. Natur-/Unwetter-Katastrophen würden nur die Probleme aufzeigen.
Am Ende wird ein solches Feature ja konfigurierbar sein.
Ich hoffe, dass man - im Gegensatz zu einem finnischen Entwicklerstudio -
Du kannst Colossal Order ruhig benennen. Es gibt wirklich keinen Grund für so eine Nonmention.
mittlerweile vieles versucht aber immernoch keine Drehgestelle an den RES
Was sagt denn der Model Validator im Editor ?
habe mir genau aus dem Grund eine rx 7900xt zu gelegt auch wen der Ryzen 5 5600 daneben etwas traurig wirkt
das sieht wirklich merkwürdig aus
Da sieht rein gar nix merkwürdig aus. Rendering auf nahezu 100% ist zu erwarten wenn VSync oder ein anderes FPS Limit nicht eingestellt sind. Bei GPUs sind permanent 100% Renderauslastung auch kein Problem, da die selbst keine Interrupts handeln müssen (nur welche zur CPU senden) und task scheduling dadurch deutlich simpler ist.
In den VRAM kommen Texturen nur bei Benutzung.
Für speicherplatzeffiziente Vielfalt lassen sich ja Texturen anderer Mods mitbenutzen. Hier wäre theoretisch sicherlich noch mehr Synergie schaffbar, wäre allerdings zusätzlicher Aufwand in der Freizeit für Modder.
Unter "melken" verstehe ich, jemand finanziell aus zu nutzen. Das ist hier nicht der Fall.
Also selbst auf Reddit empfehlen Leute das Spiel weiter, die höchstwahrscheinlich oder definitiv einige mods installiert haben, welche für sie langfristigen Spielspaß erzeugen. Seit dem C:S II Debakel finden sich in entsprechenden subreddits öfters Empfehlungen für Tpf2. Und auch auf Steam habe ich gelesen, dass Leute sich Tpf2 anstatt C:S II geholt haben. Die allermeisten Tpf2 Youtuber haben tonnenweise Mods installiert. Deren Werbung ist sicherlich auch nicht unerheblich. Der Tpf2 subreddit ist voll mit posts, die sich über die Abwesenheit von Mods auf Konsolen beschwert haben, mittlerweile hat sich das ganze zu Modwünschen für Fahrzeuge die für C:S I bereits gemoddet sind. aber nicht für Tpf2, verschoben.
Aufgrund dieser Beobachtungen bin ich zur Überzeugung gekommen, dass UG viele der aktuellen Käufe von Tpf2 nur wegen der Arbeit der Modder & Modverfügbarkeit auf Konsolen macht. Ich sehe bei der Praxis starke Parallelen zum Verhalten des größten Schweizer Entwicklungsstudio.
Edit: Nach meinem Verständnis bedeutet melken nicht zwingend Leuten das Geld aus der Tasche zu ziehen, sondern sie gezielt zu benutzen.
2. Manchmal, wenn man Schienen über die Straßen zieht, wölbt sich eine Schiene hoch und es entsteht ein unrealistisches Bild.
Kannst du mit den Werkzeugen von WernerK lösen: Gleis-/Straßen-Modifizierer Diese Funktionen sollte imho Teil von Tpf3 sein.
Bei der WiSim/Tycoon Geschichte: Dieses Forum ist eine Echokammer. Auf Steam & Reddit ist es ganz klar, dass die Meisten den Wirtschaftsaspekt bespielen & mehr Realismus von diesem erwarten. Und solange UG nur 1 oder kein DLC rausbringt, kann es ihnen egal sein, ob die Leute dranbleiben oder nach 1-3 Monaten das Spiel zur Seite legen.
Persönlich wünsche ich mir wie einige Modder hier schon geschrieben haben eine deutlich bessere Dokumentation der Modding-Schnittstellen & eine einfachere Benutzung derer. Bei fast allem was ich mal angefangen habe, habe ich mich so lange mit Unklarheiten rumgeplagt, bis ich wieder das Interesse verloren hatte. Wenn ich in meiner Freizeit programmiere bzw. was mit Open Source mache, dann habe ich wenigstens den Code as Doku und lese den halt bei allem was mir wirklich wichtig ist. Aber auch dieser Weg ist hier aktuell nicht möglich. UG sollte hier unbedingt mehr liefern, statt nur die existierende Modding community mit Sachen wie mod.io möglichst viel zu melken.
Der Code ist ja über die (offizielle) API "geöffnet". Da könnte aber noch mehr passieren. Aber die schönste Schnittstelle ist nichts wert, wenn die Dokumentation so unvollständig und teilweise unverständlich ist, dass nur ca. 10 Personen weltweit sich einigermaßen damit auskennen.
Und warum muss ich mich z.B. mit höherer Mathematik befassen, wenn ich ein Stück gebogenes Gleis modden will? Das ginge einfacher: Radius, Länge oder Winkel, Startwinkel, Startposition, Startsteigung - oder einfach das Segment, wo es angeschlossen werden soll. Ich wünsche mir auch frei benutzbare Markierungsfunktionen (außer der "Zone")? Ich hätte gerne die Möglichkeit, Animationen von Gebäuden, Fahrzeugen etc. über Kontakte/Wegpunkte zu steuern. Das muss alles nicht ingame, aber zumindest modbar sein, und zwar ohne Mathe-Diplom.
Kannst du etwa nicht mit Quaternionen Kopfrechnen ? 
Moin,
ich versuche gerade bei Majuen's Monorail Mod (Steam workshop) die Bahnsteiglänge zu fixen. Das Spiel sagt 20m, allerdings passen die 34m Doppeltraktionen perfekt in den Bahnhof. Allerdings ist mir auch nach einige rumprobieren & lesen des offiziellen Modding Wikis nicht klar geworden, wie die Bahnsteiglänge ermittelt wird. Hängt die Bahnsteiglänge von der Länge der Edges der Bahnhofgleise ab? Oder vom Mesh/Model des Bahnsteigs? Oder von den Lanes auf dem Bahnsteig?
Oder sind die in den Bahnhof integrierten Signal eventuell die Ursache?
VG
bionade24
wo es Fließkomma-Probleme gibt.
Die Akkuratheit bzw die Rechenfehler von Fließkommamatritzenberechnungen lässt sich ja mit anderen Berechnungswegen und nachträglicher Reorthonmalisierung verbessern bzw. vermindern. Auch gibt es ja genügend FP-Bibliotheken die nicht IEEE754 implementieren sondern variable Größe von Exponent und Mantisse zulassen. Der Flaschenhals ist imho eher Performance, gibt ja ein Grund warum die großen Maps hinter einer Config-Datei versteckt sind.
Es geht mir hier nicht um die Mindestanforderungen.
Ich habe auch empfohlene Hardware und nicht Mindestanforderungen geschrieben. Die liegen normalerweise unter den Leistungswerten der aktuellen Konsolengenerationen, irgendwelche Leute werden sicher auch Tpf2 auf einer iGPU eines Laptops spielen und Spaß daran finden.
So sehen die beiden Anforderungen für Tpf2 aus:
Achso nett wäre noch die zukünftigen Hardwareanforderungen vielleicht zu veröffentlichen.
Die Empfohlene Hardware auf der Steam-Seite wird ziemlich sicher im Bereich von PS5 & Xbox Series X, also RDNA2 Gpu 16GB RAM, 2020 CPU liegen, das ist ziemlich offensichtlich.
Ich muss dann auch erst noch sehen ob es auch mit Linux läuft, bzw. mit dem Proton-Layer.
Wenn sie nur auf gute Wine/Proton - Unterstützung setzen, reicht mir das völlig.
Was jetzt besser ist zu nutzen hängt wohl auch sehr stark von der Anwendung ab.
Jupp, deswegen habe ich es ja auch getestet ob es was bringt (auf Linux) bevor ich es öffentlich empfohlen habe. Und das sind bei meinem aktuellen Spielstand signifikante Verbesserung (schon 10min nach Laden 12-13GB statt 15-16GB, keine längeren Hänger mehr), da einige Mods halt leider Speicherleks haben oder es mit der API irgendwie schaffen viel Speicherfragmentierung zu erzeugen. Da du ja scheinbar dich für die Details interessierst, bei den meisten Spielen wird es kaum was bringen, da die selbst einen Memory Pool oder eine Memory Arena einprogrammiert haben. Kann natürlich nicht ausschließen, dass Tpf2 sowas auch hat, aber meine positiven Erfahrungen mit jemalloc sprechen dafür, dass es entweder nicht vorhanden ist oder nicht existiert. Mit den Optionen von jemalloc habe ich bisher auch noch nicht rumgespielt.
Falls du Interesse, Zeit und einen Speicherhungrigen Schönbau-Spielstand unter Windows hast, wäre es toll, wenn du einmal probieren könntest, Tpf2 mit jemalloc unter Windows probieren.
Edit: Das Paper benchmarked die verschiedenen mallocs bei Datenbankmanagementsystemen. Deren Workload ist nun wirklich in keinster Weise mit dem von Tpf2 vergleichbar.
