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
So, you are in a game script, and which function? update? (this would mean script thread)
This is confusing because sendScriptEvent is intended for sending data from Gui thread to script thread. (Game Script)
The UG example (which I didn't understand completly) is used for sending the event from an gui element (which is the same thread).
Your example doesn't work because update and guiUpdate are in different threads.
Die Probleme müssen an mods liegen, die net aus dem Steamworkshop kommen
Woher weißt du das?
In deiner letzten stdout sieht man, welche Mod Schuld ist (aus dem Workshop):
File name: D:/Steam/steamapps/workshop/content/1066780/2038449819/res/construction/station/rail/modular_station/extended_addon_bridge_grounded_stairs.module
Mod: "extended NL overpass (addon)" (consider removing this mod and contacting the mod author)Für die Abstürze danach können wir ohne Infos auch nichts sagen
Where do you want to call this?
Does the command
api.cmd.sendCommand(api.cmd.make.sendScriptEvent("VZ_mod.lua",tostring(Status[i].id), "flash",0))
work in the console?
Beim Laden wird intern der Standardpfad fürs icon erstellt: track.icon="ui/tracks/meingleis.tga"
Daher sollte die if Bedingung immer erfüllt sein.
Das Ug script fügt einfach "_module"/"_catenary" daran und erwartet, dass da die icons liegen, also in res\textures\ui\tracks\.
Der Witz dabei ist, in dem Ordner liegen gar nicht die Vanilla-Module, die sind in ui\construction\station\rail\modular_station, warum auch immer.
Wenn man eine schnelle Lösung will, könnte man auch folgendes testen:
Die Zeilen in der funktion der base_mod einfach auskommentieren, sodass das icon gleich dem Gleisicon ist. Nachteil: catenary würde dann gleich aussehen.
Dass der Ladebildschirm nicht (oder nur sehr selten) reagiert, ist bekannt und schon immer so.
Wenn man dann zu oft rumklickt, sagt Windows halt, es reagiert nicht.
Man kann aber Tastenkombinationen für kurvig und gerade festlegen
Hat möglicherweise was mit dem Lidl Discounter zu tun
Ob die Güter("-agenten") einen relevanten Teil ausmachen, weiß nicht. Aber die Güterwege sind ja komplett unabhängig von den Personenwegen, könnten daher parallel berechnet werden.
Selbst bei einer Testkarte mit 3 Städten ohne Güterverkehr ist die Berechnung bei 4x schon fast am Limit. Aber das nervige ist ja die Unregelmäßigkeit. An den Balken sieht man, wie unterschiedlich lange die Berechnungen jeweils dauern. Und gelegentlich auch mal ein paar Sekunden, was zum Lag führt.
Immer genau gleich lang ist natürlich schwierig, aber das kann man schon besser machen.
Bei TPF1 hatte man die Wegberechnungen jeden Monatsanfang, das war natürlich nervig, aber wenigstens vorhersehbar.
Ein _ als Funktionsname ist erlaubt? Sowas ist auch nur in Lua möglich...
Aber wenn du das zum code ergänzt und "return str" machst, dürfte das Problem gelöst sein oder?
Realistic_Train_Brake: No param
Führt nicht zu einem Fehler, es wird dann der Standard genommen. Einmal den Slider bewegen, dann müsste es verschwinden.
Erklärung hier: Realistic Train Brake
Die CPU ist nicht das Problem, mein Ryzen 2600 wird nicht mal zu 25% ausgelastet. Die GPU hängt und...
Dann liegts wohl bei dir an der Grafik, aber hier war grad nur die Rede von Simulation. Bei zuviel Personen gibts zwangsläufig SimLags.
Reine % CPU Angabe ohne Anzahl Kerne und Einzelauslastung bringt nix.
Simulationen werden heutzutage nach wie vor auf einem CPU-Kern berechnet, nur weniges lässt sich auf weitere Kerne auslagern.
Trotzdem gibt es viele Dinge, die sich parallelisieren lassen. Sowas ohne Probleme auf viele Threads zu verteilen, ist natürlich harte Programmierarbeit.
Ich würde das ganze daher nicht zu sehr auf Hardware beziehen. Es gibt Möglichkeiten, man sollte einfach mal nach dem Hauptgrund suchen und sich was schlaues überlegen. Ansonsten an sinnvollen Stellen die Simulation vereinfachen.
Dass das nicht auf Druck in einem Monat fertig ist, weil da ein angekündigter Patch erscheinen muss, ist auch klar.
Geschaut schon, aber keine Ahnung
Laut wiki sollte man für eine bessere Performance Städte-Cluster vermeiden und der Abstand zwischen Städten sollte möglichst groß sein.
https://www.transportfever2.co…manual:simulationoverview
Wäre aber trotzdem schön, das Thema Simulations-Performance nicht als erledigt anzusehen und auf die CPU der Spieler zu schieben. Es kann doch nicht so schwer sein, das vernünftig umzusetzen.
Ja, die Gebäude Kapazitäten sind auch nicht mehr so abartig hoch (in TPF1 bis zu 500), was dazu führt, dass die Personendichte kleiner ist, aber aus Simulations/Performancegründen natürlich Sinn macht. Wer das ändern will -> Population Factor
Wenn man eine Gerade gezogen hat, aber eigentlich rund gebogen bauen wollte, muss man nochmal neu ansetzen.
Mit dem Blickwinkel, das kann ich mir nur erklären, dass Straßen von weiter weg kantiger aussehen, wegen den Lod-Stufen.
You could also use some of the game icons and connect them somehow
I don't know exactly from what you want an icon, but the model editor has a screenshot function.
In TPF2 gibt es das layer immernoch, allerdings ist es durch weniger Kontrast, keine Werte beim Anklicken der Gebäude und allgemein keine genauen Werte kaum mehr verwendbar.
Genau, aber es gibt nicht mehr die Optionen "Bauwert" und "Landwert" zum anklicken. Die Farbenstärke richtet sich anscheinend nur nach dem Level.
Den Bauwert kann man mit dem Bulldozer rausfinden.
Zudem gibt es nun die Emission, die besonders an Bahnhöfen hoch ist und damit diese Grundstücke unattraktiv werden. Es wäre daher unlogisch, wenn jetzt plötzlich hohe Wohnhäuser direkt an einem Bahnhof entstehen und somit ist die Gewichtung/ Einfluss eines Bahnhofs nicht mehr gegeben.
Die Emissionen werden der Hauptgrund sein, warum sich das Stadtbild geändert hat. Möglichweise wurde deshalb der Landwert rausgenommen, damit eben genau das nicht mehr passiert.
Ich glaube aber nicht, dass Emissionen beim Stadtausbau eine Rolle spielt, denn ich hatte Städte, die wollten unbedingt ihre Häuser an der lauten Bahnstrecke bauen, statt in ruhigen Gebieten. Die Auswirkung ist nur, dass die Gesamtemissionen bei Wohngebäuden hoch ist, damit die Bewertung schlecht und das Wachstum sinkt.
Die Folge: Städte breiten sich nur noch radial gleichmäßig aus, mit abfallendem Gebäudelevel. Hochhäuser sind damit nur noch im Stadtkern möglich, Subzentren gibt es nicht.
Bei mir leuchtet Steam auch manchmal grün und ich denke irgendwas updated jetzt, aber bei TPF steht immer noch "Fertiggestellt um 16:15" und das Änderungsdatum der TransportFever2.exe ist 25. Juni 2020, 16:15:34. Aber die Zeit ist evtl bei jedem anders.
Ich denke nicht, dass sie was updaten würden ohne ins Changelog zu schreiben.
Keine Ahnung, woher Du weißt, wie der Algorithmus in TPF1 funktioniert, wenn Du es noch nie gespielt hast. Im Übrigen verstehe ich Deine These auch nicht. Was aber fest steht: in TPF2 wird der Bahnhof, wenn er denn nah genug am Zentrum liegt, sehr schnell völlig eingeschlossen:
Ich habe 1000 Std TPF1 gespielt. Aber was Verkehrsplanung angeht, habe ich (zumindest mit KI) eher reaktiv gebaut, d.h. mich nach der Bebauung gerichtet. Daher ist mir das nicht so aufgefallen. Das Gegenteil ist dann proaktive Verkehrsplanung, also wie ihr beschrieben habt, Verbindungen ins Grüne schaffen.
In TPF1 gab es bei Bahnhöfen als Parameter die zweite Straßenanbindung, hinter welcher der Algorithmus einfach weiter Straßen und Gebäude gebaut hat. Das meinte ich damit, dass Bahnhöfe deswegen sehr schnell umschlossen werden.
Bei TPF2 gibt es das so nicht mehr, da muss dann wie in deinem Bild außenrum gebaut werden, über Schranken oder Brücken. Daher gilt das tendenziell schon, dass es schwieriger ist oder länger dauert, bis Bahnhöfe umbaut sind.
Soo, da habe ich heute dann nochmal TPF1 angeschmissen und hab da was gefunden: Der Landwert. Ist mir zwar unklar, wie der genau berechnet wird, aber scheinbar ist dieser an Bahnhöfen und Haltestellen mit guten Verbindungen höher. Das würde erklären, warum an verkehrsgünstigen Orten größere Gebäude entstehen.
Was daraus in TPF2 geworden ist, kann ich euch nicht sagen. Falls das einfach rausgenommen und durch ein simpleres System ersetzt wurde - wäre schon traurig.
Aber Städte haben sich damals einfach unkontrollierter und weiter ausgebreitet. Auf dem Bild sieht man das ganz gut. Einerseits deutlich zum Bahnhof und dahinter, aber auch auf die andere Uferseite, obwohl ich da nie Verbindungen hingebaut hab. Der Landwert ist beim Bahnhof hoch und damit i.d.R. auch die Gebäudewerte. Außerhalb ist der Landwert gering.
