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
Mit dem NEP-Addon kann man die Renderdistanz feiner einstellen. Außerdem wird der Wert wieder abhängig von der Geometry Einstellung (Mittel: 50%, Niedrig: 25%).
Das Tool ist aktuell nur auf Github, ich werde es hier veröffentlichen, sobald ich etwas Feedback bekomme und ggf noch ein paar Dinge hinzufügen werde.
Hab gerade gesehen, dass es von der Modwerkstatt auch ein H/v 69 Signal Paket gibt. Hatte nur das von Sebbe auf dem Schirm. Hat jemand Erfahrungen damit? Wo sind die Unterschiede?
Ich frage mich auch wie das ablaufen soll... ich kann mir gut vorstellen, dass kein einziger TPF2 Modder sofort anfangen wird, für Konsolen zu modden. Modder und Konsolenspieler als "Casual Gamer" sind ja das krasse Gegenteil. Und selbst wenn ein Modder ne Konsole hat und sich das Spiel dort nochmal (!) kauft: Support für verschiedene Konsolen und Stores (App Store, GOG, Epic Games) sind ein Stress, den ich nicht freiwillig auf mich nehmen würde. Forum und Steam sind mir manchmal schon zuviel.
Daher bleibt UG eigentlich nur übrig, selbst eine kleine Anzahl Mods zu erstellen. So simple Config Mods sind da schnell gemacht. Bei Modellen und größeren Scriptmods wirds dann schwierig. Vielleicht fragen sie den Mod Autor. Ansonsten stellt sich die spannende Frage, ab wann das Urheberrecht greift.
The "industry/lane.mdl" might be the correct approach. It contains the transportNetworkProvider. You might also add a transportNetworkProvider directly to your mdl.
Check the lanes with AltGr+L
Nach längerer Pause meinerseits mal eine Zwischenstandsmeldung!
Ich bin inzwischen wieder an der Frankfurt Karte dran um die letzten Vorbereitungen für die Anwendung des OSM Imports vorzunehmen. Das betrifft vor allem das Terrain, welches unbedingt vor dem Anwenden bearbeitet werden sollte. Das Anpassen der Höhen dauert leider auf einer größenwahnsinnigen Karte seine Zeit. Typische Heightmap Daten sind bestenfalls bei 20m Auflösung, was einfach nicht detailliert genug ist, dass sie Bahndämme, Brücken, usw. metergenau abbilden würden. Zusätzlich muss ich die Nachteile eines Oberflächenmodells (DSM) erfahren: Meine Heightmap zeigt am Waldrand immer Steigungen von 10-15 Meter, wo es in echt flach ist. Hier zeigen sich die Vorteile eines echten Geländemodells (DGM/DTM).
Im OSM Importer habe ich z.B. noch die Möglichkeit hinzugefügt, vorgefertigte osm/pbf Dateien von einem größeren Kartenausschnitt zu nutzen, zB von Geofabrik
Das hat den Vorteil, auch ältere Versionen von OSM Karten zu nutzen (gibt keine andere Möglichkeit, historische Kartenzustände zu erstellen). Der (traurige) Grund ist, dass ich das Overlay schon vor 2 Jahren erstellt habe, aber OSM ja kontinuierlich verändert wird (neue Objekte, aber auch Korrekturen von Positionen), was dann zu Differenzen zwischen Overlay und vom OSM Import gebauten Straßen/Gleisen führt.
Außerdem wollte ich noch Signale in die Automatisierung einbauen. Die sind nämlich oft sehr detailliert gemappt, außerdem gibt es ja schon viele verfügbare Signale aus Mods. Hier zeigt sich allerdings wieder ein architektonischer Unterschied zwischen OSM und TPF: In OSM werden Signale als Nodes definiert, die auf den Ways, also den Gleisen liegen, zwischen einzelnen Edge Stücken. In TPF wiederum liegen Signale als "EdgeObjects" direkt auf einer Edge zugeordnet. Das zu konvertieren sieht soweit machbar aus. Ich hatte erst noch Probleme beim Hinzufügen von EdgeObjects in Proposals, da mir die Api abschmiert... die Dokumentation ist hierzu dürftig. Dank einer schnelle Antwort von UG ist das Problem aber schon gelöst.
Dann fehlt nur noch die Dokumentation, woran ich schon am schreiben bin. Gleichzeitig arbeite ich an der Frankfurt Karte, bis ich den Import endgültig machen kann. Dann kann es richtig losgehen mit dem Nachbau.
abgesehen von den "falschen" Parallelgleisabständen
Das Gute am Import ist auch dass die Gleise einzeln mit Gleisbett und in näheren Abstand gebaut werden, je nach Mapping in OSM:
(unbearbeitet nach OSM Import)
Your approach is right.
Make sure to connect your house with lanes to the street.
But then the mod stopped appearing
There has to be an error message.
DAS ist revolutionär, Leute!
Du hast das Unmögliche möglich gemacht...
Ich bin mir sicher, darüber wird im Hause UG nicht schlecht gestaunt werden.
Natürlich sieht die Grafik dann besser aus... du brauchst aber eine Grafikkarte die 4x soviele Pixel rendert. D.h. aktuelle Topmodelle. Und selbst dann ist nicht garantiert dass die FPS hoch bleiben. Also lohnt sich meiner Meinung nach nicht. Was bringt einem eine hochauflösende Diashow?
Es scheint also bedauerlicherweise auch in diesem Fall so, dass (trotz der tollen Spielidee) die Programmierung im Detail einfach schlecht ist, zumindest wenn man Wert legt auf einen gewissen Realismus (z. B. Nutzung von Frachtzentren statt Direktversorgung). Der Transport der Güter erscheint willkürlich und nur mangelhaft kontrollierbar zu sein.
Der Transport und dessen Organisation ist deine Aufgabe. Also kontrollieren, wo welche Güter hinwandern.
Frachtzentren sind durchaus möglich!
Allerdings kenne ich solch ein "Dauerruckeln", das – wenn es einmal da ist – nicht mehr verschwindet, nur von TPF2
Das liegt daran dass die Simulation in deinem Savegame überlastet ist, einfach zuviele Personen, Güter usw. vorhanden sind.
Das Spiel teilt das dem Spieler leider nicht mit - im Gegenteil, es versucht es zu verschleiern, in dem Simulation langsamer abläuft. Dann kommen fragen wie "warum fahren meine Züge halb so schnell wie angegeben"
Ab jetzt weißt du, dass man die Simulationsdiagramme regelmäßig im Blick haben sollte, um zu checken, wieviel "Puffer" man nocht hat.
Da bei dir die Erhöhung von Kapazitäten ja eindeutig dazu geführt hat, würde ich das mal rückgängig machen.
Ich würde auch regelmäßig die Bewohnerkapazitäten (via Editor/Sandbox) runterdrehen soweit sinnvoll. So erreicht man auch irgendwann 100%.
Lkw-Station ... mit Abladestationen an der "richtigen" Stelle
Was heißt das? Wie sieht die Abdeckung aus? (Klick auf die Station zeigt Abdeckung)
Öl an Bauernhöfen
Das Spiel kennt mehr (absurde) Transportwege als du, aber nimmt sie manchmal (aus Gründen.. nachfrageorientiert, die Weglänge ist dann egal). Cargo Filter kann hier helfen.
Für mich ist es ein totaler Widerspruch, dass ich trotz der akzeptablen FPS-Werte (45-50) solche Lags habe. Die Lags sind übrigens exakt getaktet, unabhängig von der FPS-Zahl: Alle zwei Sekunden ein Lag mit einer Dauer von ca. 0,5 Sekunden. Bei allen Fahrzeugen.
Das ist Simulationsruckeln. Der Grund ist, dass in TPF2 Simulation und Grafik in getrennten Threads ablaufen. Daher ist es vollkommen logisch, dass eine überforderte Simulation zwar zu Pausen führt (Lag der Fahrzeuge und aller Bewegungen), aber das Renderung und die UI ganz normal weiterlaufen.
Mehr Informationen mit AltGr+i
Workaround: Temporär den Lod Scale runterdrehen (Debug Tools (AltGr+D))
Meine Reaktion war, die Kapazität aller Frachtstationen sowie der LKWs und Güterzüge zu erhöhen, in der Hoffung, dass sich das positiv auf die Stadtversorgung auswirken würde. Es hat jedoch nur dazu geführt, dass mein Spiel nun lagt, obwohl ich durchschnittlich 50 FPS habe.
Interessant, bisher war mir nur bekannt, dass sehr hohe Produktion von Industrien (durch Industriemods) starke Auswirkungen auf die Simulationsperformance haben kann. Dies liegt daran, dass alle Güter einzeln durch "Güter-Sims" simuliert werden. Anscheinend führt auch die reine Kapazitätserhöhung von Zwischenstationen zu Problemen.
Screenshots von der Abdeckung der Stadt könnten helfen.
Mods wie
capacity passenger using all seats
könnten Probleme machen
In dem Kontext ist vielleicht interessant, dass in Advanced Camera Views auch eine Überprüfung von mdls notwendig wurde (durch eine Überarbeitung mithilfe EAT1963 ) RE: Triebwägen - Gelenke verhalten sich komisch
So haben wir eine ganze Reihe Mods (und ein Vanilla Modell) entdeckt, die fragwürdige Definitionen enthielten.
Diese Logik hatte mir bisher jedoch kein anderer Modder oder UG bestätigen können. Die dokumentation dazu hatte ich da nicht 100% verstanden.
Jedenfalls gibt es nun seit knapp 1 Jahr keine Beschwerden.
Demnach sind folgenden Vanilla Dateien fehlerhaft:
Advanced Camera Views - Delete invalid fakeBogie: 'configs[1].fakeBogies[1].' [res/models/model/vehicle/train/usa/speedance_express_front_v2.mdl]
Advanced Camera Views - Delete invalid fakeBogie: 'configs[1].fakeBogies[1].' [res/models/model/vehicle/train/usa/speedance_express_middle1_v2.mdl]
Advanced Camera Views - Delete 0 entry in 'configs[1].blinkingLights1' [mods/urbangames_legacy_vehicle_pack_1/res/models/model/vehicle/tram/usa/skoda_10t.mdl].Prinzipiell könnte ein (Anti-)Viren Programm beim Lesen interferieren.
Wie groß ist die Savegame Datei?
Und wie liegt die TPF Installation? Auch SSD?
Ich hatte diesen Versuch auch schon gewagt, hier kommt es aber zu dem Problem das einige Mods via Steam aboniert worden waren und "zu aktuell" für die alte Version sind.
Auch wenn du den Spielstand einfach ohne Mods lädst?
Die Gleisdateien sollten früh genug (vor anderen Problemen) beim Laden gecheckt werden.
Dir fehlt immer noch ein Gleis. Leider ist die Fehlermeldung hier nicht so zielführend.
Dein Spielstand ist von vor dem Spielupdate, bei dem das Fallback fehlender Straßen/Gleise hinzugefügt wurde. Daher funktioniert das Fallback nicht und der Umgang mit älteren Spielständen wurde offenbar nach der Umstellung bei der Fehlermeldung nicht mehr berücksichtigt. Daher stochert man hier erstmal im Dunkeln mit Trial und Error.
Eine Möglichkeit wäre, das Spiel mittels buildArchive auf die alte Version umzustellen, wo fehlende Gleisdateien noch angezeigt wurden.
Siehe
War Shift in der Kameraperspektive nicht irgendwie, dass die Bewegung schneller wird?
Jedenfalls gibt es in der settings.lua diesen Block
controllerCameraSpeed = {
cockpitMove = 0.5,
cockpitRotate = 0.5,
gameRotate = 0.5,
gameScroll = 0.5,
gameZoom = 0.5,
},womit man die Kamerabewegung langsamer machen könnte.
Übrigens habe ich seit der Überarbeitung von Advanced Camera Views letztes Jahr nichts mehr von Freezes gehört.
EAT1963 und ich haben einen Workaround für das Problem der Grafikengine (von unsichtbaren Groups) programmiert. (Was allerdings eh nur die Seat Views betraf)
Was du möchstest kann sich eigentlich mit ACV anpassen lassen.
In der Datei AdvancedCameraViews.lua kann jeder die gewünschten Views abändern, spezifisch für Loks/Waggons/Trams/Schiffe...
zB die unerwünschten Views einfach auskommentieren.
kommt wie immer drauf an, wie du spielst, und was du vorhast. Also wäre die erste Frage, wo du aktuell am meisten Probleme hast. Wie sind die FPS? Sind viele Ruckler zu spüren? Ist die Simulation am Limit? Dafür sind die Debug Infos interessant. Ob der Arbeitsspeicher am Limit (am Auslagern) ist, siehst du im Ressourcenmanager (bei Windows).
Allgemein würde ich sagen, wenn du Geld hast: alles.
RAM auf jeden Fall wenn du Karten größer als "mittel/groß" oder mit vielen Mods spielst.
GPU wenn du mit vielen Fahrzeug/Texturen Mods spielst bzw. falls du Wert auf hohe Grafik legst, oder deine FPS gering sind.
CPU schwer zu sagen... ob es sich wirklich lohnt noch auf ein bessere AM4 CPU zu setzen oder nicht gleich auf AM5 geht um zukunftssicher zu sein.
Kein Scherz, wenn ein Modder bei Steam zB Standard Straßendateien ersetzt und plötzlich Lust auf eine andere Textur etc bekommt, kommt ein Update bei jedem an. (Und ja es gibt Mods, die heißen irgendwas mit Town und ändern die Geometrie)
Also die eigentliche Frage ist, welche Straßenmods du nutzt, welche davon kürzlich Updates hatten, oder ob du neue Mods hinzugefügt hast (da das Problem erst seit kurzem da ist?).
Bei Mods immer nachlesen, ob Vanilla Dateien ersetzt werden.
