Transport Fever 2 Beta Version 35126 (19.01.2023): Diskussion

Zitat von KoA

Warum muss er jetzt jedesmal dieses "changing size" auswerfen

Fliegt mit dem nächsten Patch wieder raus.

Hab gerade mal den "Deferred Proposal"-Modus getestet. Das ist wohl nur unter Settings konfigurierbar, obwohl das Konstruktionsprozesse zu beschleunigen scheint. Beim Bauen von Straßen werden z.B. die Zwischenschritte des Preview als vereinfachte Grafik dargestellt. Ich hatte allerdings auch den Eindruck, dass auch meine Tools dadurch etwas schneller funktionieren. Die wüsten stdout-Meldungen sind aber geblieben. Es kommt sogar noch irgendwas mit "ping" hinzu. Schaut es euch mal an, eigentlich finde ich, das gehört ins Spielmenü mit rein statt irgendwo in der settings-Datei vor sich hin zu schimmeln.

Aber bitte regt euch nicht über dieses sinnlose Augenkrebs-Flacker-Infofeld auf, dass auch noch exakt unter dem meiner Mods liegt.

viele Merken an, dass das Update ja nicht so viel Performance bringt wie es versprochen wurde. Ich startete während dem spiel den taskmanage,r und man sieht schön dass (bei mir) der dritte Kern also CPU2 zwischen 80 und 90% ausgelastet ist, während dessen die anderen eher so bei 20 bis 30 rumdümpeln, (siehe anhang, wobei dies wieder leicht verfälscht ist, da ich den screenschot nach dem abspeichern des savegames, und beenden des spiel gemacht habe) wie schwer/einfach ist es das spiel von Single auf multicore, umzuprogrammieren ? weil so können mehrere kerne ja das spiel berechnen, wodurch (nach meiner Logik meines wissens nach) das spiel performanter läuft, da nicht der Eine Kern alles berechen muss und ggf. überlastet ist, sondern schön alle 12 kerne mitrechnen können. wäre vielleicht auch ne Idee die man mal in einem update rausbringen könnte. (so als kleiner ideen einwurf)

Wo es nichts zu parallelisieren gibt ist nichts zu parallelisieren. Das Spiel nutzt vier Kerne, es gibt aber Aufgaben die an einen Kern gebunden sind.

Ich gehe mal sehr stark aus das sowas durch die Engine beschränkt ist... Wenn du mehr CPU Auslastung möchtest solltest du auf OpenGl wechseln, jedoch kommt das mit einigen Nachteilen. Auch im allgemeinen täglichen Gebrauch von Programmen wird größtenteils nur ein Kern belastet:

(Hier sind nur Spotify, Edge, der Taskmanager, Discord auf und natürlich Hintergrund-Programme) Es ist deutlich die unterschiedliche Belastung der Kerne zu sehen .

Ausnahmen sind hier eindeutig Photo und Videobearbeitungsprogramme, sowie CAD/3D Programme. Aber auch hier findet die Aufspaltung in die unterschiedlichen Kerne erst am Ende beim Exportieren oder Rendern statt, wenn das Programm nicht von vornerein bei der Entwicklung dediziert einzelne Kerne für unterschiedliche Prozesse bestimmt. Weiterführend hat jeder Pc eine unterschiedliche Anzahl an Kernen welches das ganze denke ich vermutlich weitergehend erschwert.

Aber ja ich gebe dir Recht, eine Anwendung auf zumindest 2 oder gar 4 Kerne sollte mittlerweile ein möglicher Standard sein. Kaum Jemand wir heute nicht schon mindestens 2 oder eigentlich sogar 4 kerne haben (Selbst Handys haben ja mittlerweile immer einen Dualcore).

Amen 😂🤭

Und zu der Performance.... Doch bringt es schon sehr. Dies wirkt sich jedoch stark auf die GPU und nicht auf die CPU Nutzung aus.
wenn du also Gaming Performance willst kannst du eigentlich die größte schrott CPU reinschmeißen über 3 GHz und einfach nur in eine gute GPU investieren...
(Habe selber lange mit einem Budget-Pc auf Max settings Gezockt... Mein upgradet war größtenteils aufgrund von Videoschnitt und CAD Arbeit.

Zitat von Fabian88410

weil so können mehrere kerne ja das spiel berechnen, wodurch (nach meiner Logik meines wissens nach) das spiel performanter läuft, da nicht der Eine Kern alles berechen muss und ggf. überlastet ist, sondern schön alle 12 kerne mitrechnen können. wäre vielleicht auch ne Idee die man mal in einem update rausbringen könnte

Du bist nicht der erste mit der Idee. Aber Multithreading ist einfach gesagt aber alles andere als trivial und harte Programmierarbeit und manchmal auch von der Logik nicht möglich. Man muss sagen, dass hier seit TPF1 auch einiges gemacht wurde (früher lief das Spiel auf nur einem Kern). Seit TPF2 sind zB GUI und Simulation in verschiedenen Threads unabhängig. Das macht aber auch viele Sachen komplizierter (eis_os kann ein Lied davon singen). Es scheint dass UG hier schon viel versucht hat, aber es gibt allgemein kaum Games, die mehr als 4 Kerne ausnutzen.

MrOnic Mag für andere Spiele gelten, aber nicht für TPF2. Die Simulation kommt ja schnell an die Grenzen.

Ich komme mal mit einer Zwischenfrage um die Ecke:

Ich habe einige wenige hundert Beiträge zuvor gesehen, dass die BuildWithCollision Mod Probleme beim bauen macht (konkret: Man kann bei Kollisionen nicht mehr das blaue Fenster "trotzdem bauen" erreichen). Genau an einer solchen Stelle bin ich nun und komme nicht mehr an das blaue "trotzdem bauen" Fenster ran. Vor dem Update konnte man hier durch zoomen und drehen das Spiel etwas an der Nase herum führen, um doch an das blaue Fenster heranzukommen. Geht nun gar nicht mehr. Ich habe schon Knoten in den Fingern. Gibt es dazu bereits eine Lösung oder einen Trick?

RFSW: Lade Dir hier die Beta-Version herunter. Habe die auch gerade statt der Steam-Version Workshop installiert und funzt!

Bitte auch dazu sagen warum es eine Beta Version ist. Es kann crashen wenn du auf das X im Asset menü drückst. Kann mit ESC umgangen werden, aber vielleicht denkt man nicht immer dran.

Alternativ hast du die Wahl zu einer anderen Testversion: RE: Build with Collision

Auch nicht optimal, aber immerhin ohne crash.

Ein wirklicher Fix ist aktuell leider noch nicht möglich.

Ich hatte noch kurz überlegt, ob ich es dazu schreibe, aber dann dachte ich mir: "Wer lesen kann,...."

Gelobe Besserung

charly_o VacuumTube Danke für den Tipp. Ich habe es mit der neuen Version hin bekommen. Der blaue "trotzdem bauen" Button ist nun noch weiter weg vom Mauszeiger, aber mit Trick 17 (drehen des Bildschirms, usw.) kommt man nun dran. Danke!

Auf den Hinweis (Crashwarnung beim "X") werden ich versuchen zu achten. Ich kann zwar lesen, aber der zusätzlich Hinweis ist doch ganz gut.

Die Sache mit dem X ist gar nicht so unproblematisch. Ich wusste zunächst gar nicht, was gemeint war - aber mir ist es jetzt klar: das Schließen des Baumenüfensters mit dem Closer-Button oben rechts. Es kann nämlich auch passieren, dass auf dem Weg zu besagtem Button das noch oder wieder am Mauszeiger klebende Konstruktionsobjekt irgendwo eine zufällige Kollision auslöst, die gar nicht beabsichtigt ist und womöglich vom Menüfenster überdeckt wird. Wenn ich dann auf das X klicke, dann gibt's den Crash, übrigens ohne Fehlermeldung und Notsicherung. Ich habe lange gebraucht, bis ich BwC als Ursache ausgemacht hatte, zwischenzeitlich wurden auch Probleme bei starren Konstruktionen in meiner Gleisbauer-Mod gemeldet, auf die ich mir keinen Reim machen konnte. Dasselbe gilt übrigens nicht nur für das X, sondern für sämtliche Vorgänge, die während einer Kollision das Baumenüfenster schließen, z.B. auch Abspeichern.

Die Analyse des Problems und einen Lösungsvorschlag habe ich per Konversation an VacuumTube geschickt.

Ich muss sagen, dass ich immer versuche per Tabulatortaste das Menü zu schließen, um nicht das "X" nutzen zu müssen. Aber als Mausfetischist passiert es mir doch nahezu täglich und ab und zu schmiert mir das Spiel deswegen ab. Das ist schon nervig. Wenigstens habe ich alle meine Probleme dank Update nun im Griff und es läuft wieder.

Servus,

ist es seit dem Update nicht mehr vorgesehen Experimentelle Mapgrößen in der settings.lua zu aktivieren?

Starten kann ich eine zb. Größenwahnsinnige Map ohne die lua zu ändern. Wenn ich es denn doch tue dann hängt das Spiel extrem und selbst die kleinste Map läuft mehr Diashow als flüssig.

Grüße

Steven