Beiträge von VacuumTube

Mit Advanced Statistics hast du eine Liste der Resourcen

https://steamuserimages-a.akam…r=#000000&letterbox=false

In der Tat kenne ich keine Tutorials/Lexikon Artikel die sich mit Script Modding für TPF2 beschäftigen. Da muss man sich Stück für Stück durchbeißen. Mal in andere (einfache) Mods schauen, wie die das machen. Und immer wieder trial and error...

Hier ein paar Links:

Offizielles Wiki: https://www.transportfever2.com/wiki/doku.php

Api: https://transportfever2.com/wiki/api/

Dateien in Notepad++ und LUA-Formatierung

https://www.lua.org/pil/contents.html

Gibt es eine Modding Schnittstelle, mit der das Maltool bzw. die Bodentexturen benutzt werden können?

Zitat von RPGFabi

Und zudem liegt das Problem nicht am "dummen" Spiel sondern an den Moddern, denen jegliche Einsicht auf sowas zu achten fehlt.

Viele Modder wissen es auch einfach nicht. Das ist ja nur eins von vielen Problemen, die bei manchen Mods bestehen, weil nicht jeder Modder alle Richtlinien bzw "Best Practices" von TPF kennt.

Das mit der Kleinschreibung ist aber einfach eine Tatsache, die unter vielen Windows Opfern (wie mich) nicht so bekannt ist. Trotz Programmiererfahrung habe ich das relativ spät zufällig erfahren, weil irgendwo ein Mod bei einem Linux User nicht funktioniert hat.

Pragmatische Lösung vom Spiel wäre, bei Mods mit Dateien die Großbuchstaben enthalten, einen Fehler zu werfen. Umlaute kann man gleich mitnehmen, das führt ja auch immer wieder zu Problemen.

Zitat von Thaimike2112

Kannst du schon verraten wann ungefähr diese tolle Tool rauskommt? Bin so ungeduldig und kann es kaum erwarten, da ich es mit diesen Overlay nicht hinbekommen habe

Da sich auch meine Erwartung, wann ich diese Ankündigung schreiben kann, immer wieder nach hinten verschoben hat, nein.

Ich weiß nicht, ob der OSM Import das Overlay ersetzen kann. Klar hat man dadurch schonmal die Straßen Struktur. Aber ein Overlay ist schon praktisch, weil da ja alle möglichen Details wie Gebäudeumrisse drauf sind.

Ich habe mir ein Overlay für die gesamte Karte erstellt, das kann ich per Mod jederzeit rausnehmen. Das finde ich praktischer als das aufmalbare.

Versuch es doch solang nochmal mit dem Overlay. Ich weiß, es ist nicht einfach, ich musste mir die Infos auch von verschiedenen Stellen zusammensuchen. Ein Lexikon Artikel gibt es leider nicht.

Also wie gesagt, wer das Tool anwenden möchte kann so oder so schonmal anfangen, einen Kartenausschnitt auszuwählen, sich ein Overlay zu machen und ggf. eine Heightmap zu finden und importieren.

Zitat von HoratioCaine

Wie, bitte schön, kommst Du auf so eine Idee?

Naja, ich wollte Nachbau machen, hatte aber keinen Bock, alle Straßen und Gleise von Hand zu setzen. Bei 500 000 Stück wird das vermutlich schnell langweilig. Mit der Script Lösung hole ich etwas weiter aus, habe dafür aktuell noch keinen Baufortschritt. Aber durch das Programmieren bleibt die Motivation oben, man lernt was dazu und gleichzeitig kann es am Ende von jedem genutzt werden

Zitat von HoratioCaine

Soll ich schon mal RAM kaufen?

Warte mal ab... die Preise sinken ja tendenziell.

Es hängt aber davon ab was du machen willst. Für eine kleinere Karte oder bei einer ländlicheren, weniger bebauten Gegend braucht man wahrscheinlich nicht upgraden.

Zitat von Asaja

wenn man ein großen Bahnhof nachbauen will wäre das eine super Hilfe. Werden auch die ganzen Weichen automatisch gesetzt? Könnte man dann z.b. nur den Bahnhof München mit den ganzen Gleisanlagen auswählen und von dort dann das gebastel starten?

Bahnhöfe sind so ne Sache. Die Gleise davon werden ganz normal gebaut. Aber die Station muss man schon selbst im Spiel Bauen. Da wird man sowieso wahrscheinlich je nach Bahnhof sehr flexibel sein müssen. Theoretisch könnte man aber versuchen mit der Freestyle Station einfach nur die Bahnsteige zu ziehen.

Die Gleise sind in OSM schon per Nodes verbunden, d.h. sie sind es auch im Spiel. Weichen müssten kein Problem sein. Kann aber sein, dass da öfters mal der Bau nicht geklappt hat. Passt das Overlay, kann man die ja schnell nachziehen. In OSM sind sogar Doppelkreuzweichen definiert, allerdings musste ich das vorerst rausnehmen, weil es zum Crash führen kann (src\Lib\Geometry\Streets\track\Crossing.cpp:235: Assertion `Angle(m_ctxs[0].curve[2], m_ctxs[1].curve[2]) >= ANGLE_MIN' failed.)

ja... aber nur wenn der Mod Autor das eingetragen hat.

Und dann sagt CommonApi standardmäßig dass die abhängende Mod vorher geladen werden muss. Was meistens unnötig ist. Dafür gibt es übrigens requiredModsAnyLoadOrder

völlig egal. Solang die Mods sich nicht beißen. Es wird nur relevant wenn die Mods dieselben Dateien ändern oder scriptmäßig was an der selben Stelle machen.

In letzter Sekunde auch noch ein Beitrag von mir

Ich habe testweise mal den OSM Importer für meine Frankfurt Karte laufen lassen. Alle Straßen, Gleise und Bäume wurden mithilfe des Tools platziert, nichts per Hand.

Ihre Nachricht ist zu lang. Es stehen maximal 10.000 Zeichen zur Verfügung.

WTF?

Roadmap

Nach den festgestellten Performanceproblemen im Härtetest werde ich wohl weitere Analysen machen müssen, um die Situation in den Griff zu bekommen. Der Sinn des OSM Imports von allen Straßen, Gleisen, Wäldern bevor man mit Gebäuden, Linien und Details (welche ja ebenfalls Ressourcen verbrauchen) weitermacht, ist ja nicht dass die Performance schon früher als sonst im Keller ist. Vielleicht lässt sich die Baumdichte verringern oder unnötige Straßenwege einsparen. Vielleicht ist das Ergebnis dieses Tests aber auch einfach, dass man eine bebaute 24x24 km Karte nur mit 128 GB RAM vernünftig spielen kann. Es lohnt sich eventuell also doch, mit kleineren Karten anzufangen^^

Dann werde ich demnächst natürlich auf die aktuelle Spielversion übergehen und hoffen, dass es keine größeren Probleme gibt. Gleichzeitig arbeite ich an der Frankfurt Karte weiter und bereite das Terrain auf den finalen Import vor. Dabei wird es sicher noch ein paar Optimierungen am Konverter/Importer geben. Sobald ich einen finalen/vorzeigbaren Stand habe, veröffentliche ich das Tool mit entsprechender Anleitung.

Seit einiger Zeit beschäftige ich mich mit dem Nachbau von realen Städten in TPF2. Viele haben es mal angefangen, oft geht aber nach einiger Zeit die Motivation aus, einfach aufgrund des großen Aufwands so eines Projekts und der schieren Menge an zu bauenden Straßen, Gleisen, Bäumen, Gebäuden usw., was monoton werden kann. Allerdings besteht mit OpenStreetMap (OSM) bereits eine umfangreiche, detaillierte und offen zugängliche Quelle für Kartendaten. Ich habe mir gedacht: Warum nicht die hier bereits gemappten Straßen, Gleise und weitere Daten verwenden und automatisiert in TPF2 bauen lassen?

So beschäftigte ich mich zunächst mit OpenStreetMap, welche Daten es gibt und wie sie dort dargestellt sind. Hierzulande ist der Detailgrad und die Genauigkeit der Straßen, Gleise, Flächen usw. relativ hoch. Viele der Informationen lassen sich für TPF2 nutzen. Ich fing an, einen Konverter zu schreiben und entwickelte eine Toolchain, mit der die Daten in TPF2 eingelesen und über die Modding API automatisiert gebaut werden können.

Das Ganze mache ich am Beispiel von Frankfurt und Umgebung, wozu ich auch eine entsprechende Karte plane (mehr dazu unten). Der aktuelle Konverter ist schon in einem sehr fortgeschrittenen Stadium, allerdings fallen immer noch kleinere Probleme auf. Die finale Version wird zu gegebener Zeit veröffentlicht, mit entsprechender Anleitung.

OpenStreetMap

OpenStreetMap (OSM) ist ein erfolgreiches Projekt seit 2004 zur Etablierung einer freien, offenen Kartenbasis, an der jeder mitwirken kann. Die Datenbank besteht aus Straßenverläufen, Eisenbahnanlagen, Gebäudeumrissen, Stromleitungen, Landnutzung (z.B. Wald) bis hin zu Objekten wie Mülleimern. Auf der Hauptseite osm.org werden nicht alle Daten dargestellt; manche kennen vielleicht auch OpenRailwayMap, was dieselbe Datengrundlage nutzt, nur mit anderer Visualisierung (z.B. auch abgerissene Gleise).

In OSM gibt es grundsätzlich 3 Arten von Elementen: Nodes (Punkte mit Koordinaten), Ways (Verbindung von Punkten) und Relations (Zusatzinfos zu Nodes und Ways). In den zugehörigen Tags sind weitere Informationen als Attribute enthalten (XML). Prinzipiell können hier beliebig viele Tags vorhanden sein, die Mapping Detailtiefe variiert allerdings. Genauer anschauen kann man sich das ganze auch über die Objekteabfrage via Rechtsklick.

z.B. https://www.openstreetmap.org/way/48905770

Auch wenn in TPF Straßen & Gleise ebenfalls via „Nodes“ und „Edges“ darstellt werden, gibt es einige Unterschiede. So stellt nämlich im Spiel eine Edge immer eine Verbindung zwischen genau 2 Nodes dar, während ein Weg in OSM über sehr viele Nodes verlaufen kann. Außerdem gibt es in OSM (wie auch in Google Maps) keine echten Kurven! Wenn man genau hinschaut, sieht man, dass Kurven praktisch nur aus vielen kleinen (geraden) Segmenten bestehen. Das ist für Karten ausreichend, aber in einem Spiel wie TPF nicht.

Die OSM Daten sind nur 2-dimensional und enthalten keine Höheninformationen. D.h. wir brauchen nichtsdestotrotz eine vernünftige Heightmap. Diese muss natürlich von der Position an den Kartenausschnitt kalibriert werden. Für flachere Gegenden kann man sich den Aufwand einer Heightmap ggf. sparen. In jedem Fall empfiehlt sich ein OSM Overlay.

Welche Daten können genutzt werden?

Der primäre Fokus liegt auf den Straßen und Gleisen. Gerade das monotone Bauen von Straßen könnte vermieden werden, da diese in enormer Zahl vorhanden sind. Die nächste Frage ist natürlich, welcher Straßen-/Gleistyp gebaut wird. Die OSM-Daten enthalten oft Infos zu Art der Straße, Höchstgeschwindigkeit, Anzahl Fahrspuren, Bodenbeschaffenheit usw. Mithilfe diesen Informationen kann ein geeigneter Typ bestimmt werden, sodass direkt die entsprechende Geschwindigkeit oder Straßenart (Bürgersteig, Landstraße, Autobahn, Feldweg) verwendet wird.

Da Wälder in den Landnutzungsdaten direkt als Polygon verfügbar sind, lag eine Nutzung der Förster Mod nahe. Hierfür war eine kleine Anpassung nötig, sodass der Förster über eine Schnittstelle nun die Wälder der OSM Daten bauen kann. Sogar die Information über Waldart (Laub/Misch/Nadel) kann berücksichtigt werden.

Mit den Koordinaten von Städten/Stadtteilen können entsprechende „Labels“ erstellt werden (Fake Städte, nicht funktional).

Weiterhin gibt es ein paar punktuelle Objekte (z.B. Poller, Litfaßsäule), welche mit geeigneten Assets dargestellt werden können. Für viele andere Elemente wie Gebäude, Stromleitungen, Zäune gibt es zu wenige Informationen, als dass eine Automatisierung sinnvoll wäre.

Die Toolchain

Die OSM-Daten zu einem Kartenausschnitt kann man sich ziemlich einfach über die Webseite exportieren. Die Daten sind zunächst in einem XML-Format gegeben. Da ich mir die ganze Konvertierung nicht in Lua antun wollte, finden die Schritte zur Zwischenverarbeitung in Python statt. Das Python Script liest die XML-Daten zum entsprechenden Kartenausschnitt ein, filtert diese nach den relevanten Daten und erzeugt eine Lua Datei in einem geeigneten Format für TPF2.

In der Zwischenkonvertierung findet zum Beispiel die Transformation der Weltkoordinaten zu Map-Koordinaten statt. Das allein war ein längerer Spaß, weil man feststellt, dass die Erdkrümmung bei einer Größe von 24x24 km in der Tat auffallen kann^^. Weitere Verarbeitungsschritte sind die Optimierung der Edges und das Hinzufügen von Tangenteninformationen bei Gleiswegen, damit diese auch passend kurvig ineinander übergehen. Bei geraden Segmenten wäre die Zugfahrt sonst sehr zackig^^

Auf der TPF2-Seite steht praktisch eine Script Mod, die über die Konsole angesprochen wird. Die zuvor erzeugten Daten werden dann eingelesen, sodass über die TPF2-API die Objekte automatisiert gebaut werden können. Hier sind nur ein paar minimale händische Eingaben nötig. Bei großen Kartenausschnitten kann das Bauen eine Weile dauern, aber man kann es auch vorher mit kleineren Teilausschnitten testen.

Für Straßen und Gleise wird die buildProposal Funktion genutzt. Theoretisch kann man hier beliebig viele Nodes und Edges auf einmal angeben, was ich anfangs versucht habe. Bei einem critical Error (Bau nicht möglich), also mehr als eine einfache Kollision (bei einem großen Proposal sehr wahrscheinlich), hat man allerdings keine Möglichkeit, die problematische Stelle zu erkennen oder zu beheben. Daher müssen alle Edges nacheinander mit einzelnen Proposals gebaut werden. Deswegen kann das natürlich etwas dauern bei etwa 5 Commands/s.

Beispiel Frankfurt Karte

Wie oben erwähnt, plane ich eine Karte zum Nachbau von Frankfurt und Umgebung. Ein 1:1 Maßstab ist für mich, spätestens seit der Kopplung mit OSM, unabdingbar. Ich wollte nicht erstmal klein anfangen, sondern habe eine größenwahnsinnige Karte (24x24 km), womit leider trotzdem nicht allzu viel RMV Gebiet bleibt: Der Kartenausschnitt reicht von Langen im Süden, dem Flughafen, über Kronberg im Taunus, knapp zum Altkönig, bis Oberursel und Bad Vilbel im Norden und Mühlheim im Osten.

Heightmap fürs Terrain habe ich mir geholt, ebenso ein OSM Overlay. Leider ist die Heightmap nicht von bester Qualität, weshalb ich aktuell hauptsächlich mit Erdarbeiten beschäftigt bin. Wichtig ist, dass alle Dämme, z.B bei Brücken vorhanden sind und das Terrain bei Straßen und Gleisen halbwegs glatt ist BEVOR man den OSM Bau ausführt. Anpassungen im Nachhinein sind nämlich aufwändiger. Daher kann ich auch erst NACH dem erfolgreichen Import mit Bahnhöfen, Gebäuden, Linien usw. weitermachen und kann aktuell noch nichts allzu spannendes zeigen.

Ich habe einfach mal einen Härtetest durchgeführt und den OSM Importer für die gesamte Karte angewandt. Aktuell bin ich noch auf Build 35049, weil ich mir die zusätzlichen Probleme des aktuellen Updates gerne noch sparen möchte und es Performance mäßig ja auch nicht gerade viel reißt. Bisher habe ich nur Teilausschnitte getestet, was für einen Stadtteil mit etwa 20 000 Edges (1h Bauzeit) kein Problem war. Das Gesamtgebiet hat allerdings 500 000 Edges, was 30h gedauert hat. Die Savegamegröße ist von 30 MB auf 3 GB angestiegen und das Speichern der Autosaves ist auf 20 min angestiegen (vermutlich wegen der RAM Auslagerung). Die Speicherauslastung lag laut Ressourcenmonitor bei 100 GB! Nach dem Neuladen warens 68 GB, leider mit erheblichen Rucklern. Aber gut, was will man bei einer vollgebauten, größenwahnsinnigen Karte auch erwarten? Es wurden immerhin 3,7 Mio Bäume, 10500 km Straße und 1000 km Gleise gebaut.

Von oben ist durchaus ein Wiedererkennungseffekt gegeben. Von Nahem sieht es noch nicht so ideal aus, vor allem wenn viele Edges auf kleinem Raum sind mit vielen Kreuzungen. Daher gibt es teilweise Lücken, weil bei manchen Edges der Bau nicht möglich ist. Aber der Großteil der Struktur von Straßennetz und Gleisen ist so schonmal vorhanden.

Man sieht, dass die Nodes manchmal einfach nicht so akkurat gemappt sind, was bei der Kartendarstellung nicht auffällt, in TPF aber schon

Die Kurven und Steigungen der Gleise sind leider nicht immer direkt perfekt. Wie man sieht, hängt viel vom Terrain ab. Es wird eine gewisse Nachbearbeitung geben müssen. Das ist aber im Endeffekt immer noch deutlich schneller als es komplett selbst bauen. Die Tools von WernerK wie z.B. der Rampenvergleichmäßiger sind hierfür hervorragend geeignet.

Das Kameratool erzeugt unkomprimierte Einzelbilder, die man dann wieder zusammenfügen muss, also klar dass da kein Sound ist.

Sinn macht es wenn die FPS kritisch sind und dir flüssige Wiedergabe wichtig ist.

Zitat von Sandtorhai

Hat jemand Erfahrungen mit dieser Version?

https://github.com/lolluslollus/lollo_build_with_collision_1

Lollus hat eine eigene Version von BwC gemacht. (mit meiner Erlaubnis der Veröffentlichung)

Habe ich mir nie genauer angeschaut. Also keine Ahnung was die kann / was die anders macht.

Kann gerne mal getestet werden.

Der blaue Button gehört aber ja nicht zum Menü, sondern hängt an der Leiste die immer da ist.

Und erklärt auch nicht warum mit ESC geht und nur nicht mit dem X Klick. Das erzeugt exakt dasselbe Event. (auch nur 1 mal)

Aber zerbrechen wir uns nicht den Kopf, wenn das später eh ersetzt wird

Zitat von WernerK

Andererseits funktioniert mein rein privates Patch so gut, dass ich es als Übergangslösung nahelegen würde.

Poste es gerne hier für alle, die nicht auf mein Update warten wollen

Grundsätzlich sind viele Information über das Modding Interface verfügbar.

In meiner Mod Advanced Statistics lese ich ungefähr alle Informationen aus einem Spielstand aus. Das kann sich evtl anschauen.

https://github.com/Vacuum-Tube…tics/script/data/line.lua

Es erfordert aber einiges an Aufwand, diese Daten dann noch in eine Datei zu schreiben und in Excel zu konvertieren.

Der Crash der 1.3 von Build with Collision beim X auf das Baumenü ist bekannt.

Du hast die 1.3 aktiv welche allerdings Beta ist. 1.2 ist stabil, aber funktioniert nicht bei Assets.

Der alternative Button macht scheinbar Probleme, eine Erklärung habe ich bisher nicht.

UG hat versucht eine andere Lösung zu finden was seit der neusten Testversion anscheinend möglich ist.

Mehr Infos immer hier RE: Build with Collision

Es gab ja noch Probleme mit UGs neuem Mouselistener. Mir wurde geschrieben, dass es gepatcht wird/wurde (und jetzt insertMouseListener gibt.)

WernerK Ich würde diese Lösung auch als idealer sehen, daher ist der untere Button dann auch überflüssig.

Ich hab mir aber die neuste Version noch nicht angeschaut. Ich bin aktuell noch auf der alten Pre Console Version unterwegs, da ich die ganzen Änderungen und Stabilitätsprobleme gerade gar nicht gebrauchen kann. Ich hoffe dass ich die nächsten Wochen mal dazu komme.

Versuch mal die cargo Nachfrage zu ändern, das aktualisiert alle Gebäude auf einmal.

(Für residential braucht man glaub ich ne mod wie town tuning)

I was noticing that, too.

I don't know how, but the game seems to use any available trees when residential houses are built. Maybe because of tree = { } in metadata.