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
VacuumTube: Vielleicht nicht unlösbar (wenn man nicht an fest codierten Werten scheitert), aber eine Monsteraufgabe.
Eine personenbefördernde Gartenbahn im Maßstab 1:5 wäre für einen Enthusiasten dieser Idee wohl ein geeignetes Zwischenziel, weil da praktisch alle wirklichen Probleme auftauchen, und der Rest dann "nur" noch ungeheuer viel Arbeit ist. Und man hat mit einem Bahnhof und einem Gleistyp schon einmal etwas sinnvoll einsetzbares.
... gab es nicht schon mal die Idee einer Gartenbahn?
Meines Wissens sind einige Parameter wie die Abstände eingerasteter paralleler Gleise hardcoded. Das wäre dann ziemlich nervig. Und das grundsätzliche Problem, daß sich TpF2 an der 25-fachen Menge an Fahrzeugen, Bäumen, Häusern etc. verschluckt, ändert sich auch nicht. Ebenso wird z. B. der Ausblick einer Mitfahrt ähnlich wie bei einer Modelleisenbahn sein, man hat einfach zu viel Überblick über die winzigen Gegenstände.
... Und um das *ganze* Zeug zu verkleinern, braucht es einige sehr engagierte Modder.
Hallo LipeYT,
Ein paar Antworten wirst Du wahrscheinlich nicht mögen.
Vielleicht tröstet es Dich, wenn Du Dir überlegst, daß Du für einen 1:1-Deutschland-Nachbau, wäre er denn möglich (das könnte in 20 oder 30 Jahren anfangen, realistisch zu werden), auch gar keine Zeit hast.
Was ich meine, ist daß bei normalen Abständen von Vor- und Hauptsignal und dem aktuellen Schaltzeitpunkt das Vorsignal für den vorbeifahrenden Zug immer "Halt erwarten" anzeigt. Das Vorsignal wäre also witzlos. Den Schaltzeitpunkt vorzuverlegen, wäre möglicherweise problematisch.
Du kannst aber auch kaum verhindern, daß nicht irgendein Spieler zwischen Vor- und Hauptsignal eine Weiche setzt. Dann ist sogar die Zuordnung von Vor- und Hauptsignal variabel in Abhängigkeit vom Zug, der gerade vorbeifährt - TpF2 kennt keine Weichenstellungen oder Fahrstraßen, sondern jeder Zug fährt sturheil seinen Weg. Das alles geradezuziehen ist viel Arbeit für relativ wenig Effekt, und wohl nur von UG zu erledigen, weil es sehr tief ins Spiel eingreift.
Wenn man sich anschaut, wie die Signale bisher reagieren, dürfte das auch einen größeren Umbau im Hauptprogramm erfordern. Die Signale sind ja alle standardmäßig rot und schalten erst auf grün, wenn der Zug schon lange am Vorsignal vorbei wäre (falls der nächste Abschnitt frei ist). Das müßte geändert werden, damit man mal ein Vorsignal auf grün erlebt. Und da fürchte ich Probleme bzw. Blockaden in eng gebauten Gleisanlagen.
Was läuft hier wohl schief? Auf jeden Fall die Ladung...
Die pfeilerlose, gemauerte Brücke im Hintergrund ist zwar auch schon ein lange bekannter optischer Bug, aber so schmerzhaft habe ich es selten gesehen. Oh nein, es ist eine Schneeflocke drauf gefallen, gleich bricht sie zusammen!
1000 Mods sind schon 'ne Menge. Speziell was das Texturenswappen anbelangt, hängt es aber auch stark von der Texturlastigkeit der Mods ab. Und die RTX 3080 scheint 10 GB RAM zu haben, die halt auch irgendwann vollaufen (einer der Gründe, warum ich mich für eine 3060 mit 12 GB entschieden habe ...).
Hast Du viele verschiedene Loks/Wagen gleichzeitig auf den Schienen? Wenn Du denen allen auch noch begegnest, kann das das Swappen schon triggern.
VECtron2017: Du sprichst immer von "Personen laden". Damit triffst Du die Sache nicht ganz. Geladen in dem Sinn wird ein Modell mit den zugehörigen Geometriedaten und Texturen. Davon hat das Vanilla-Spiel wahrscheinlich nicht viel mehr als 40 Stück (plus etwas weniger Autos). Die 10000 Leute auf einer Map sind alle Klone von diesen 40. Ein Klon braucht dann nur ein paar Hundert Byte im Speicher: Wie heißt er, hat er ein Auto, wo ist er, wo wohnt er, wo arbeitet er, wo will er gerade hin, in welchem Bewegungszustand ist er. Dazu kommt einfach noch ein Zeiger auf das Modell des Sims und seines Verkehrsmittels.
Es ist nicht das, was Graphikkartenpower kostet, sondern die Vielzahl der Modelle, wenn Du 1000 Mods hast. Denn jedes hat (bis auf wenige Ausnahmen) seine eigenen Texturen. Da muß nicht mal eine Mod besonders böse sein.
VacuumTube: Wenn das System bei einer Zugfahrt langsamer wird, dürfte das schon am VRAM liegen, vor allem, wenn der gute VECtron2017 mit vielen Mods spielt. Dann werden ständig Texturen hin- und hergeschaufelt (wobei die Figuren ein kleines Problem davon sein dürften). Ein fleißiger Mod-Sammler kommt schnell auf mehr Texturspeicherverbrauch als eine Graphikkarte hat. Und im Gegentum zu den meisten anderen Spielen kann man bei TpF2 in einer Sekunde völlig wo anders sein und einen komplett neuen Satz an Texturen brauchen.
Das müßte übrigens schlimmer werden, wenn Du nicht mit dem Zug fährst, sondern ziemlich schnell hintereinander unterschiedliche Stellen aus der Nähe betrachtest.
VECtron2017: Der Trick an den LOD-Stufen ist der, daß möglichst nicht viel mehr berechnet wird als angezeigt wird. Besteht die Person in der besten Auflösungen aus einigen tausend Dreiecken, sind es aus der Ferne vielleicht noch zehn oder zwanzig, bei denen auch noch die innere Bewegung fehlt. Eine nahe stehende Person frißt also so viel Rechenleistung wie hundert oder mehr weit entfernte. Da ist es relativ egal, an welchem Punkt eine Figur ganz verschwindet.
Du kannst die LOD-Entfernungen im Spiele-Ordner finden in der Datei ..../res/models/model.zip und darin model/characters/aaa.mdl (aaa ist Platzhalter für die jeweiligen Namen).
Es ist aber eine sehr schlechte Idee, darin einfach herumzufuhrwerken (lesen ja, schreiben nein). Du bist gewarnt.
Im Rahmen einer Mod sollten sich die LOD-Entfernungen für ein Spiel, das die Mod lädt, ohne Kollateralschäden überschreiben lassen. Wenn Du Dir das nicht zutraust, solltest Du erst recht nicht direkt in die Spieledateien schreiben. Die von VacuumTube erwähnte Mod (und deren Analyse) könnte ein Startpunkt sein, wenn sie nicht sowieso genau das tut, was Du willst.
Es hängt davon ab, was Du genau meinst.
1) Es sind grundsätzlich alle Personen im Spiel und werden mit ihren Bewegungen simuliert und "leben" im RAM. Das ist natürlich eines der Haupt-Performance-Fresser (Prozessorleistung), aber auch ein Hauptcharakteristikum des Spiels. Karlchen Schmitz bleibt Karlchen Schmitz, egal ob er umzieht oder den Job wechselt, ob Du die Straße, auf der er läuft, abreißt, oder ob Du Dir auf der Map Köln oder Düsseldorf anschaust - ich weiß nicht, ob das Spiel Namen doppelt vergeben kann, aber jede Nase dürfte eine eigene ID haben. Deswegen auch die Leistungseinbrüche bei großen Karten gegen Ende des Spiels. Das läßt sich auch kaum ändern ohne das Spiel neu zu programmieren.
2) Die Sichtbarkeit läßt sich sicher ändern, dazu müßte man die LOD-Stufen (LOD: Level of Detail) der Personen anpassen. Das würde die Graphikkarte etwas entlasten, aber ich könnte mir vorstellen, daß das nur beschränkt etwas bringt. Die vollen Details siehst Du nur, wenn Du näher als 15 m an einer Person dran bist, sie verschwindet ganz, wenn sie mehr als 360 m entfernt ist (habe ich an einem Beispiel angeschaut, vielleicht sind andere anders). Ich denke, das hat UG sauber optimiert.
a.s.bavaria : Du aktivierst Mods, indem Du im 3. Bild des von Dir zitierten Beitrags von elektronikfreak auf "Optionen auswählen" klickst (eigentlich ist das der Zustand vom 2. Bild, aber die Optionen sind da abgeschnitten). Dann bekommst Du die Liste der von Dir abonnierten/heruntergeladenen Mods angezeigt und kannst sie dem Spiel hinzufügen.
Wenn Du ein fremdes Savegame hast, ist das allerdings schon erledigt, und das Spiel beschwert sich vermutlich wegen fehlender Mods. Ich bin kein Steam-User, aber ich denke, Du wirst sie einzeln zusammensuchen müssen, wenn der Autor nicht eine Modliste zusammengestellt hat, die Du als Ganze abonnieren kannst.
Das dürfte eher daran liegen, daß man sich bei Schiffen die Kollisionsprüfung weitgehend gespart hat.
Es müssen auch nicht die Wasserwege breiter sein, sondern das "Schiffbarkeits-Raster" (die Quadrate, die in Gewässern die Schiffbarkeit anzeigen) müßte kleiner werden. Wenn man im Maßstab 1:1 spielt, muß man im Vergleich zu Luftbildern/Stadtplänen alle Hafeneinfahrten und die meisten Hafenbecken viel zu breit machen, damit sie befahren werden können. Und auch das hängt möglicherweise wieder mit der Kollisionsprüfung zusammen: Es ist nicht nur für den Steuermann, sondern auch für den Programmierer eine Herausforderung, in einen Hafen zu fahren ohne mit der Uferbefestigung zu kollidieren.
Bisher bin ich ohne Beweis davon ausgegangen, daß sich die Höhenschritte nach der Skalierung, die man beim Import der Höhenkarte angibt, bestimmen - sonst hat die Möglichkeit der Skalierung relativ wenig Sinn, außer Rundungsfehler zu provozieren. Woher hast Du den Hinweis auf die 0.05 m - Höhenschritte?
Die elektronische Kupplung ist wohl das, was angedacht ist. Als ehemaliger Modellbahner bin ich aber bei allem skeptisch, was geschobene Züge anbelangt. Sicher, bei der Modellbahn ist es wegen der unrealistisch engen Kurven alles noch schwieriger, aber ich denke, daß auch in der Realität Unfälle bei geschobenen Zügen schwerer werden als bei gezogenen, weil erst noch einmal ein Teil des Zuges versucht, über die verunglückten Wagen zu rollen.
Zur Heightmap-Bearbeitung in GIMP ganz kurz: In GIMP kann man mit Ebenen arbeiten - das sind quasi eigenständige Bilder innerhalb eines Bildes. Bei der normalen Bildverarbeitung wird das z. B. benutzt, um Vorder- und Hintergrund separat zu halten - man kann so Leute in eine Landschaft stellen, in der sie nie waren. Man kann diese Ebenen vereinigen und dabei unterschiedliche Rechenoperationen durchführen, auch multiplizieren, addieren etc (mit gewissen Einschränkungen). Du müßtest im konkreten Fall einen Graustufen-Verlauf, der um die gewünschte Absenkung ansteigt, von der Heightmap subtrahieren.
Dabei gibt es ein paar Hürden. Die unangenehmste: GIMP rechnet "optisch" richtig, und nur mit als "veraltet" markierten Funktionen mathematisch richtig.
@Oberhausener: Das korrekte Verhältnis der Breiten von Rhein und Ruhr ist wahrscheinlich gar nicht so wichtig. Die tollen Bilder im Schönbau siehst Du aus Fußgänger- oder Führerstandperspektive. Da kommst Du, im Gegensatz zur Vogelperspektive, praktisch nie auf die Idee, die Flußbreiten zu vergleichen. Es ist wohl besser, mal ein schnelles "gegenüberliegendes Ufer" als Kulisse zu bauen und zu schauen, ob Dir der Blick über den Fluß zu mickrig aussieht. Wenn der Rhein bei 400 m Breite gut aussieht, nimm ihn. Wenn er bei 700 m besser aussieht, dann nimm das. Du wirst in den Städten sowieso viele Straßen weglassen müssen. Dann halt ein paar mehr, aber das ist ein guter Blick über den Fluß wert.
a) Mit den Geländeänderungen meine ich bildlich gesprochen folgendes: Stelle Dir vor, Du hättest die Landschaft auf einer Modelleisenbahnplatte aufgebaut, die Flüsse an den Plattenrändern mit Brettern gegen Auslaufen gesichert, und die Flüsse mit Wasser befüllt. In der normalen Landschaft läuft dann die Ruhr etc. leer und der Rhein läuft über. Dann kippst Du die Platte so, daß Du den Startpunkt der Ruhr bei Hagen, des Rheins bei DüsNeuss und den Endpunkt des Rheins bei Wesel auf der gleichen Höhe hast. Dann sollte sich das Wasser in den Tälern verteilen (natürlich nicht perfekt). Gegenüber ihrer näheren Umgebung änderst Du damit die Höhe der Berge nicht.
Das kann man im Prinzip mit einer Höhenkarte auch rechnerisch machen. Der Vorschlag, sich nur auf die Ost-West-Richtung zu beschränken ist eine Vereinfachung, die vermutlich so gerade eben funktioniert.
(Für die Mathefreaks: Ich weiß, daß diese beiden Sachen nicht 100% äquivalent sind: Eine Rotation der Platte gegen eine Scherung bei der Höhenkarte. Das ist bei den kleinen Winkeln aber vernachlässigbar.)
b) Die Breite der Flüsse ist Deine Entscheidung. Ich würde allerdings den Rhein lassen und nur die kleineren Flüsse und Häfen so weit aufbohren, daß sie gerade eben ohne "Schwänzeltanz" schiffbar sind (mit Schwänzeltanz meine ich die engen Kurven der Schiffe, wenn die Quadrate, die Schiffbarkeit anzeigen, diagonal aneinandergereiht sind). Du kannst versuchen, die aufgebohrten Flüsse mit Hilfe von Blöcken, Felsen und Bäumen im Schönbau optisch wieder zu verkleinern. Der Rhein war übrigens an keiner Stelle, an der ich gerade eben gemessen habe, mehr als 400 m breit.
c) Ich hatte vor zwei Jahren mal mehr versehentlich eine 8-bit-Graustufenkarte verwendet, was zu einer Art Reisterrassenoptik der Landschaft führt. Bei 8 bit hast Du nur 256 verschiedene Höhenstufen. Wenn sich Deine Landschaft über 511 Höhenmeter erstreckt (des einfachen Rechnens halber), hast Du eine Höhenauflösung von 2 m. Du bekommst also entsprechend hohe Stufen in die Landschaft. Bei 16 bit teilst Du jede dieser großen Stufen in 256 Teile, Du bekommst also Stufen von 8 mm Höhe, und die sind egal.
Das Spiel rechnet intern mit 16 bit oder noch höherer Auflösung, einen Performancegewinn kann es da also nicht geben (ich bekomme kleine Stufen angezeigt, wenn ich die Wasserflächen-Mod von Relozu benutze, also vermute ich tatsächlich 16 bit).
Was der Haken bewirkt, weiß ich nicht. Ich habe mindestens zwei Theorien, was er bewirken könnte: Entweder die Auswahl der Dateien auf 16-bit-Graustufenbilder zu beschränken oder eine Glättung für 8-bit-Bilder zu aktivieren. Mogele mal ein 8-bit-Bild ins Verzeichnis. Dann kannst Du mindestens die erste Theorie testen und die Stufen anschauen.
Markus1014 : Mir ist klar, wie Du es gemeint hast. Ich bezog mich ausschließlich auf den Post direkt vor meinem.
wunder99: Das was im Weltraum gut berechenbar ist, schafft auf Schienen zusätzliche Probleme. Wenn z. B. das vordere Fahrzeug auch das hintere bremst, verlierst Du Bremskraft.
Auf was für Ideen die Leute kommen 
Im All gibt es keine Notbremsung innerhalb von Sekunden.
Vor dem Problem mit den hohen Ufern bin ich auch zurückgeschreckt, weil die beste Lösung, aus den Höhendaten etwas brauchbares zu machen, die mathematische Keule verlangt. Das Prinzip ist, die drei Stellen, an denen Rhein und Ruhr die Karte betreten bzw. verlassen, auf die gleiche Höhe zu setzen und die Höhen des restlichen Geländes entsprechend zu ändern. Das ist zwar immer noch nicht perfekt, weil das Gefälle nicht gleichmäßig ist, aber Du mußt dann nicht mehr 70 m, sondern vielleicht noch 5 m oder 10 m wegretuschieren.
Die Mathematik in Graphikprogrammen ist auch von daher problematisch, als daß die versuchen, die Farbempfindung und nicht die Mathematik "korrekt" hinzubekommen. Ich hatte meine liebe Not damit, GIMP zur korrekten Mathematik zu zwingen (das muß man dem irgendwie mehr als einmal sagen).
Etwas einfacher ist, vor allem wenn Du die Berge sowieso von Hand baust, das Gelände nach Osten hin porportional zum Abstand vom Rhein hin abzusenken.
Bei der Schiffbarkeit von Hafenbecken und schmaleren Flüssen wirst Du Kompromisse eingehen müssen, gerade bei einem kleineren Maßstab. In Köln ist der Rhein meines Wissens etwa 400 m breit, bei Duisburg nicht so schrecklich viel breiter (eher 500 m als 700 m), aber das kannst Du in Google Maps nachmessen.
