Beiträge von DHEModding

Willkommen in der Transport Fever Community

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


    Nun ja, es gibt ja schon unterschiedliche Zwecke. Mein Tool ist sozusagen ein Kompromiss aus Schönheit und Spielbarkeit (ich flache z.B. die Gelände stark ab und sorge für vollständige Lieferketten), andere gehen viel stärker Richtung Schönheit/Realismus, ggf. auch mit Zielgruppe Schönbauer.


    Meins hab ich eigentlich angefangen, um Szenarien/Kampagnen zu erstellen, aber bin dann abgedriftet, weil mich die Möglichkeiten schon fasziniert haben, insb. jetzt mit den importierbaren Biomen.

    Ja, das stimmt. Die Ziele und Schwerpunkte sind schon unterschiedlich. Mein Fokus liegt eher auf einer realistischen Landschaftsgestaltung, insbesondere im Gebirge, sowie auf der Darstellung mithilfe angepasster Klimamods. In Bezug auf die Spielbarkeit hat mein Ansatz natürlich auch einige Nachteile.

    Ursprünglich wollte ich nur eine Heightmap leicht bearbeiten und importieren. Allerdings ist das Standardklima nicht auf reale Höhendaten ausgelegt. Und so kam eins zum anderen. Und mithilfe von KI konnte ich dann relativ schnell ein funktionierendes Programm mit für mich guten Resultaten bauen.

    Das können diese ja gerne tun, da wird auch nichts passieren. Im Zweifel fahren die Schiffe dann halt nicht. Die sav Dateien funktionieren aber alle und damit kann man auch spielen, weil das Spiel die Savedateien nach einer bestimmten Logik aufbaut. Somit braucht man nur ein Decoder und Coder schreiben der eben funktionale sav Dateien erstellen kann.


    Deine Gedanken kannst Du gerne äußern, wie auch Verbesserungsvorschläge oder neue Ideen. Aber das machst Du ja leider nicht, sondern äußerst unebgründete Zweifel die sich nur auf Mutmaßungen stützen und damit ist dann halt niemanden wirklich geholfen. Anders als wenn man Du das einfach testen würdest, meisten fallen vier Augen mehr auf, als nur zwei. Ich komme ja auch nicht in deinen Thread und äußere meine Bendenken und sage, naja das kann aber deutlich besser machen, etc.

    Falls meine hypothetischen Bedenken als unangemessene Kritik angekommen sind, möchte ich mich dafür entschuldigen. Ich wünsche dir weiterhin viel Erfolg bei der Entwicklung.


    Du bist selbstverständlich jederzeit herzlich eingeladen, auch in meinem Thread Bedenken jeglicher Art zu äußern, Kritik zu üben und Verbesserungsvorschläge einzubringen.

    Was ist hier eigentlich deine Mission? Mit Vermutungen kann man in der Regel nichts anfangen und genau darum testet man ja sowas.

    Ich möchte lediglich meine Gedanken dazu teilen und auf mögliche Risiken hinweisen. Wie du das Ganze letztendlich umsetzt, ist natürlich deine Entscheidung. Experimente sind völlig in Ordnung und auch wichtig.

    Mir geht es nicht darum, deinen Ansatz schlechtzureden. Im Gegenteil: Ich finde ihn persönlich sehr interessant und spannend.

    Behalte aber bitte im Hinterkopf, dass möglicherweise auch andere, technisch weniger versierte Nutzer dein Programm verwenden werden.

    Da habe ich nichts festgestellt und funktioniert auch mit einer 120 km Karte sehr gut

    Das Problem ist nicht die Karte an sich, sondern das Zusammenspiel zwischen der Karten, Spielengine, den Spielmechaniken, Spielobjekten, Assets usw.

    Solche Eingriffe können zu unvorhersehbaren Zeitpunkten Probleme verursachen, die sich auf völlig unerwartete Weise äußern.

    Ein Beispiel (nur ein spontaner Gedanke): Städte wachsen nicht mehr oder entwickeln sich merkwürdig, weil interne Abfragen der Wasserflächen fehlschlagen oder falsche Daten liefern. Das könnte wiederum weitere Seiteneffekte auf das Wirtschaftssystem und andere Spielmechaniken haben.

    Solche Probleme müssen bei ersten Tests nicht zwangsläufig auffallen, sondern können sich erst nach längerer Spielzeit zeigen. Genau das macht solche tiefgreifenden Eingriffe in die Spielmechanik schwer vorhersehbar und aufwendig zu testen.

    Am besten den Code Water Mesh anschauen. Es ist noch nicht perfekt, bei Flüssen baut er Treppenstufen rein


    Fluss

    https://www.dropbox.com/scl/fi…7ujdllin&st=gu0puci3&dl=0

    Ich habe mir den Code angeschaut. Dein Ansatz, die Wasserflächen direkt in die SAV zu schreiben, ist interessant,

    aber auch etwas riskant. Damit wird die Standard-Pipeline des Spiels zur Kartengenerierung umgangen, mit möglichen

    Auswirkungen auf Kompatibilität, Stabilität und Performance. Dabei muss man beachten, dass alle Elemente des Spiels, die in irgendeiner Form mit Wasser interagieren – sowohl sichtbar als auch unsichtbar –, dadurch beeinflusst werden können.

    Also nur um das Bergflüsse/-seen-Problem noch mal klarzustellen: Klar kann man das in einer begrenzten Region hinbekommen, weil man dort das Tal auf 0 stellen kann. Aber wie ich z.B. den Spitzingsee (1084 m ü. NN) auf eine Karte bekommen soll, auf der auch der Tegernsee (726 m ü NN) drauf ist, ohne das Gelände dazwischen stark zu verfälschen, muss mir in der aktuellen Game-Engine noch jemand zeigen :-). Und die wahren Probleme kommen natürlich bei Karten von ganzen Ländern (z.B. Deutschlandkarte), wo ich die Meere und die Alpen drauf habe.

    Bezüglich der Flüsse und Seen habe ich das folgendermaßen gelöst:


    Alle Wasserflächen, die unterhalb eines einstellbaren Höhenwerts über dem niedrigsten Punkt der Karte liegen (z. B. 100 m darüber), werden auf das Wasserniveau abgesenkt. Alles oberhalb dieser Grenze wird mit einer Wassertextur dargestellt. Zusätzlich wird das Gelände durch Terraforming angepasst, damit beispielsweise Seen möglichst ebene Wasserflächen erhalten.

    Für die Wasserflächen nutze ich ein eigenes Biom. So lassen sich beispielsweise Bergseen zumindest optisch recht gut darstellen.

    Der Ansatz zur Darstellung von Wasserflächen ist noch nicht ganz ausgereift und hat logischerweise einige Nachteile. Für den Anfang funktioniert er aber ganz ordentlich.


    Bezüglich der Berge:


    Das ist der Hauptfokus meines Generators. Im Klima-Mod definiere ich für die jeweilige Karte realistische Höhengrenzen, beispielsweise eine Baumgrenze bei 1.800 m über dem Meeresspiegel (MSL) oder eine Schneegrenze ab 2.500 m.

    Diese Höhengrenzen werden anschließend entsprechend dem Maßstab der Karte und der Bezugshöhe (niedrigster Punkt der Karte) auf die Ingame-Höhen umgerechnet.

    Dadurch lassen sich die Vegetations- und Höhenzonen auch bei unterschiedlichen Kartenmaßstäben möglichst realistisch darstellen.


    Karten von ganzen Ländern werden mit dem Realdaten-Ansatz logischerweise schwierig.

    Was mir dazu durch den Kopf geht, ist ein Ansatz mit segmentierten Karten. Dabei wird die Karte in mehrere größere Bereiche aufgeteilt, beispielsweise Norddeutschland, Mitteldeutschland und Süddeutschland. Diese Segmente könnten dann einzeln möglichst sinnvoll ausgewählt, skaliert und aufbereitet werden.

    Wenn man diesen Ansatz weiterdenkt, könnte man die Karte auch in ein regelmäßiges Raster aufteilen und die einzelnen Bereiche unabhängig voneinander bearbeiten.

    Das größte Problem wären dabei natürlich die Übergänge zwischen den Segmenten. Hier müsste man mit einer geschickten Auswahl und Aufteilung der Segmente, geeigneten Glättungsalgorithmen und gegebenenfalls manueller Nachbearbeitung arbeiten, um möglichst natürliche Übergänge zu schaffen.

    Der Beitrag ist raus.

    tf3-AutoMapGen – Realistic Transport Fever 3 Maps from Real Geodata Project Showcase


    Vielleicht kurz zu meinem Ansatz, mehr Naturdetails ins Spiel zu bringen:


    Mein Ansatz basiert im Wesentlichen auf Custom-Klima-Mods. Am einfachsten lässt sich das am Beispiel von Feldern erklären:


    Das angepasste Klima definiert eigene Biome für verschiedene Feldtypen, beispielsweise Weizen- oder Maisfelder. Für jedes Biom lassen sich individuelle Regeln festlegen, etwa welche Bodentexturen verwendet und welche Assets platziert werden.


    Mein Framework lädt die entsprechenden Felddaten aus OpenStreetMap (OSM) und erzeugt daraus automatisch die Biommasken für die jeweiligen Feldtypen.

    Beim Laden der Karte ordne ich die erzeugten Masken den entsprechenden Biomen zu. Das Spiel übernimmt anschließend die Darstellung der Felder anhand der definierten Regeln.


    Grundsätzlich lassen sich auf diese Weise beliebige Biome im Klima definieren. Allerdings gibt es einige Einschränkungen:


    Ein Problem ist die Auflösung der Biommasken. Soweit ich es bisher getestet habe, arbeitet das Spiel mit einer Mindestbreite von ungefähr 16 Metern (Ingame-Maßstab).

    Ich habe beispielsweise versucht, Feld- und Wanderwege über eigene Biome darzustellen. Das hat allerdings nicht zufriedenstellend funktioniert, da die Wege im Spiel etwa 16 Meter statt der gewünschten 4 Meter breit waren – obwohl sie in der Maske nur einen Pixel breit angelegt waren.

    Hecken, Mauern und Obstwiesen könnten daher schwierig umzusetzen sein, zumindest als eigenständige, schmale Biome.

    Eine mögliche Alternative wäre, beispielsweise für ein Obstwiesen-Biom die Regeln zur Asset-Platzierung so anzupassen, dass an den Rändern automatisch Hecken oder Mauern erzeugt werden.

    Das ist allerdings nur eine Idee und entspricht meinem aktuellen Erkenntnisstand aus den bisherigen Experimenten. Ob und wie gut sich das tatsächlich umsetzen lässt, müsste man noch testen.


    Ein weiterer wichtiger Aspekt der Custom-Klima-Mods ist die Anpassung der Höhengrenzen für Fels, Schnee und andere Bodentexturen.

    Im Standardklima sind diese Grenzen relativ niedrig angesetzt, sodass bereits ab etwa 500 Metern Ingame-Höhe Schnee dargestellt wird. Durch die Anpassung der Klimadefinition lassen sich diese Höhengrenzen gezielt verändern, um insbesondere Hochgebirgslandschaften realistischer darzustellen.


    Den Code will ich bald Veröffentlichen, dann kannst du dir das genauer anschauen. Muss aber erstmal etwas Aufräumen etc.

    tf3-AutoMapGen – Technical Details

    Extended technical information for the project introduced in the previous post.

    1. Why a custom climate mod?

    TF3 has node-based climate graphs: on import they place vegetation and rocks; on loading they assign ground materials.

    The standard temperate climate uses forest, rock and snow thresholds near 310, 330–350 and 380–430 game metres. On real Alpine terrain (reference elevation 250 m, scale 0.5), these altitude zones would be far too low.

    The single global water level also means elevated mountain rivers must use painted water textures.

    tf3-AutoMapGen extends the existing climate graphs instead of replacing them.

    2. Source data and generated files

    Sources:

    • Elevation: elevation models accessed through OpenTopography (or supplied as local GeoTIFF files).
    • Land cover: ESA WorldCover 10 m (forests, cropland, grassland and other land-cover classes).
    • Map features: OpenStreetMap, including waterways, paths and settlements; OSM extracts can be obtained from Geofabrik.
    • Game resources: the local TF3 installation, especially the existing climate graphs and terrain assets.

    Outputs:

    • A 16-bit heightmap using the game's 4 m-per-pixel grid, including terrain adjustment around planned towns and industries, shaped river banks and a water-level solution.
    • A biome map, determined from elevation bands and slope-related rules.
    • Import layers for forest, meadow, cropland, rock, riverbed, water, shore, crop textures and mountain / transition areas.
    • A generated climate mod with extended node trees.
    • A towns-and-industries import file, two small supporting map mods (field/hiking paths as streets and industry naming) and preview images.

    The standard temperate climate declares two import layers ('rivers' and 'mountains'). A custom climate can declare additional layers, up to 12 in total. The current Alpine Realistic preset uses all 12 slots.

    3. How the generated climate works

    Import tree (runs during map import):

    Uses masks for forest and rock placement within the game's resolution limits. Species vary by altitude and biome, with boulders in rocky areas, forests and riverbeds.

    Material tree (evaluated on map loading):

    Uses masks, biomes and altitude rules for meadows, crops, rock, scree, riverbeds, painted water, shores and waterfalls, optionally with texture noise.

    The configurable Alpine Realistic preset uses:

    • Tree line: 2,100 m above sea level
    • Scree: from 2,100 m
    • Rock: from 2,200 m
    • Snow: from 2,500 m

    These are stylistic settings, not measured local climate data.

    The terrain graphs work in game metres, so thresholds are converted by:

    game height = (real elevation - reference height) × scale

    At reference height 250 m and scale 0.5, a 2,500 m snow line becomes 1,125 game metres. Maps with matching settings can share a climate mod.

    The look is defined in TOML presets (surfaces, altitude zones, forests, rocks, mask assignments). Landscape configurations can also modify the appearance across a map.

    4. Framework architecture

    Simplified workflow architecture:

    The tool uses a generic, graph-based processing framework. Its map generator is assembled from smaller nodes with typed inputs and outputs rather than implemented as one monolithic script.

    The main processing groups are:

    Source Data → Terraforming → Planning → Final Terrain → Biome Creation

    Additional branches generate the climate mod and supporting map mods.

    The map graph has roughly 190 reusable nodes, including subgraphs.

    Map-generation graph (overview):

    The design separates:

    • Data: typed, immutable height fields, masks, plans and graph objects.
    • Parameters: TOML climate, landscape and project settings.
    • Processing: individual Python functions.
    • Composition: JSON graph documents describing how nodes are connected.
    • Execution: validation, dependency ordering, caching, memory handling and previews.

    The engine validates types, links and parameters. Versioned lineage keys allow unchanged intermediate results to be reused, so changing forest parameters need not recalculate rivers.

    Parameters and graph variants allow new regions without rewriting code. The framework core is game-independent.

    5. GUI and workflow

    Local browser GUI with the Innsbruck–Karwendel project selected:

    Typical workflow:

    1. Select a geographical area, map size, aspect ratio, scale and climate settings in the local browser GUI (or use the command line).
    2. Download or load the elevation data, land-cover tiles and OSM data. OpenTopography requires a free API key for supported downloads. Later runs reuse cached data.
    3. Execute the graph to generate the heightmap, biome map, import layers, climate mod, town/industry data, support mods and previews.
    4. Open the TF3 map editor, select the generated climate, import the images using the height and water-level values provided by the GUI, and import towns and industries.

    Outputs can be copied to the TF3 user-data folder; the editor import remains manual.

    6. Evaluation

    The three maps demonstrate Alpine altitude zones (Karwendel), agricultural land-cover patterns (Zurich–Schaffhausen) and large-scale landscape transitions (Brenner). Results are qualitative, not pixel-accurate; there are no systematic performance benchmarks or controlled comparisons with the default climate yet.

    7. Current limitations

    • Import-layer resolution: the game samples layers more coarsely than the heightmap grid. Narrow paths and streams cannot be reproduced precisely; imported layers are essentially binary masks.
    • Assets and layers: only a limited number of masks, ground textures and vegetation/rock assets are available.
    • Water: the single water level requires painted rivers above that level; those are not real water.
    • Performance: high-resolution masks, elaborate material graphs and dense vegetation can increase RAM use and loading times. In-game terraforming can trigger expensive recomputation. These costs have not yet been benchmarked systematically.
    • Scope: the current preset is focused on Alpine terrain and is based on the temperate climate. Dry and tropical climates are not yet implemented.
    • Road networks: paths and country-road traces can influence terrain, but a complete road network between towns is not yet generated.
    • Testing: only a few maps, mainly in the Alps, have been tested in the game so far.

    8. Related work and planned next steps

    Related projects include TPF3 Map Studio by sharpi13822 and Terra2Fever3. I have not evaluated them in depth, so this is not a comparison or review. Their workflows and my focus on generated import layers plus climate mods may complement each other.

    Next: publish the code, create more maps, benchmark performance and add configurable climate presets.

    References / attribution

    Source code: https://github.com/Froggy94/tf3-AutoMapGen

    Feedback welcome! I am particularly interested in whether the landscape and terrain look right on different systems, whether the generated maps work reliably in longer games, and which limitations matter most in practice.

    tf3-AutoMapGen – Realistic Transport Fever 3 Maps from Real Geodata Project Showcase


    DOWNLOAD(GIT): https://github.com/Froggy94/tf3-AutoMapGen


    Technology study / experimental prototype v0.1 – October 2026

    I would like to introduce tf3-AutoMapGen, an experimental, graph-based framework for generating realistic Transport Fever 3 maps from real-world geodata.

    The basic idea: a real heightmap is not enough. It reproduces the shape of the terrain, but the game's standard climate does not automatically reproduce the actual forests, fields, riverbeds, rock faces or realistic Alpine altitude zones.

    My approach combines three matching outputs:

    • a heightmap based on real elevation data,
    • a biome map and additional import layers derived from land-cover data and OpenStreetMap,
    • a generated climate mod that extends the game's own node-based terrain generator and interprets those layers.

    The goal is to generate the landscape as automatically as possible, rather than manually painting large maps in the editor. The climate mod, the import layers and the heightmap are designed to work together.


    The framework, including its source code, is on git: https://github.com/Froggy94/tf3-AutoMapGen


    I am aware that other projects with a similar focus already exist, such as TPF3 Map Studio and Terra2Fever3. My intention is not to compete with these projects, but to present my own approach and position it as a potential complement to existing solutions within the broader context of TF3 map generation.


    What does it look like? Three examples:

    1. Innsbruck – Karwendel | Alpine terrain

    https://mod.io/g/transportfever3/m/innsbruck-karwendel1#description

    Very Large, 1:1 aspect ratio, scale 0.5 (about 33 × 33 km of real terrain). Focus: realistic transitions between forests, scree, rock and snow. Terrain, towns and industries were generated automatically and left unchanged; roads were built in the game editor.

    Real-world reference (Google Maps):


    Generated map (Transport Fever 3):

    2. Zurich – Schaffhausen | Forests, fields and meadows

    https://mod.io/g/transportfeve…schaffhausen2#description

    Very Large, 1:2 aspect ratio, scale 0.5 (about 22 × 45 km of real terrain). The first prototype; focus on land-cover patterns. Some terrain around towns was corrected manually, and roads were built and partly reworked in the editor.

    Hallau – real-world reference (Google Maps):

    Hallau – generated map (Transport Fever 3):

    https://mod.io/g/transportfeve…a-13-scale-05#description

    Gigantic, 1:3 aspect ratio, scale 0.5 (about 33 × 98 km of real terrain). Focus: large-scale generation and the gradual transition from the greener northern Alps to the drier southern Alps. Around 90–95% of the terrain and landscape was generated automatically; towns and industries required substantial manual changes.

    Brenner / Wipptal – real-world reference (Google Maps):

    Generated Brenner map (Transport Fever 3):

    These are qualitative visual comparisons, not pixel-accurate or camera-aligned reconstructions. The game engine, terrain resolution and available assets impose limits. I think the results are promising, but there are still issues with fine details, roads, large maps and performance.


    For anyone interested in how this works, I have included the technical details below.

    Technical details: See my next post in this thread for the implementation, architecture, limitations and references.

    Servus,

    interessantes Projekt! Ich arbeite aktuell ebenfalls an einem Tool zur automatisierten Kartenerstellung für TPF3 auf Basis realer Geodaten. Dadurch sind Folgende Karten entstanden:

    - DHE Zürich - Schaffhausen (https://mod.io/g/transportfeve…usen2#description)(leicht nachbearbeitet)

    - Innsbruck - Karwendel very Large 1:1 Scale 0.5 (https://mod.io/g/transportfeve…ck-karwendel1#description) (komplett auto generiert)

    - Brenner – Innsbruck - Bozen Giga 1:3 Scale 05 (https://mod.io/g/transportfeve…a-13-scale-05#description) (teilweise bearbeitet)


    Mein Fokus liegt momentan insbesondere auf der möglichst realistischen Darstellung der Landschaft durch angepasste Klima-Mods, die unter anderem Vegetation, Bodentexturen und Felder anhand realer Daten erzeugen.

    Weniger priorisiert habe ich bisher dagegen das Laden, Bearbeiten und Einfügen realer Straßen- und Schienennetze.

    Bei der Kartenauswahl und Terrainbearbeitung gibt es durchaus einige Überschneidungen zwischen unseren Projekten.

    Ich werde in Kürze einen eigenen Forenbeitrag erstellen, in dem ich mein Projekt und den technischen Ansatz genauer vorstelle.

    Vielleicht ergeben sich ja interessante Möglichkeiten zum Austausch oder zur Zusammenarbeit!