Beiträge von VacuumTube

UG soll etwas für tausende Mods entscheiden? Und zukünftige?

Wird nicht passieren. Ist ja auch gar nicht eindeutig zu definieren.

Außerdem: Ab wievielen Mods soll/darf ein Modder eine eigene Kategorie aufmachen? Vielleicht wollen manche User auch alle Gebäude in einer Kategorie, unabhängig vom Ersteller?

Ich habe einen Vorschlag gemacht, zu einer Community Lösung. Ich seh schon, das einigen wird dann schwierig.

Aber wenn ein paar wenige sich eh mit einer guten Sortierung beschäftigen und einen guten Vorschlag machen, würden viele davon profitieren. Und wie gesagt, das ganze ist update-sicher und reversibel.

Wenn jemand ein Minimalbeispiel bereitstellt (3 Einträge, Liste wie oben) kann ich einen Prototyp schreiben.

Zitat von Carbonunit

Letzten Endes kann nur UG Ordnung in die Sache bringen durch fixe Kategorieen und Unterkategorien, in die sich Mods einfügen müssen.

UG ist in gewisser Weise für die Koordination von Schnittstellen bei Mods verantwortlich, aber kann keine Modder dazu zwingen. Wie soll das Spiel erkennen, dass das Modell was der Modder dort in der "tree" Kategorie verordnet hat, ein Haus darstellt?

Ich habe hier schonmal irgendwo geschrieben, dass UG früher vielleicht mehr konkrete Kategorien hätte vorgeben sollen und dies prominent im wiki betonen. Das Problem ist halt, dass Vanilla nur wenige Kategorien mit Icon existieren und wenn jemand eine Kategorie von einer anderen Mod benutzt überschreiben sich die Icons. Jetzt ist es halt wie es ist und sie können da auch nicht mehr viel machen. (Haben hoffentlich für den Nachfolger gelernt)

Zitat von Computerhocker

Eine "Community Icon Categories Mod" wäre dann wohl eine Lösung.

warum eigentlich nicht?

Die Kategorien von Konstruktionen kann man einfach per modifier überschreiben, das ist update sicher.

Leute lernt Script Modden

Damit löst man viele Probleme.

Ich kann einen Prototyp schreiben. Die Community muss dann eine Liste gemeinsam entwickeln, welche kontinuierlich erweitert werden kann. In folgender Form:

newcategories = {
    ["modderX/asset1.con"] = "house",
    ["modderY/asset2.con"] = "industry",
}

Das hätte den Vorteil, dass nicht jeder selbst die Kategorien von Hand ändern muss, sondern man eine gute Lösung nutzen kann, die für die meisten sinnvoll ist. Hier ist aber der Knackpunkt... die Community muss sich auf eine Lösung einigen Das ist glaub ich das ist hier das größere Problem...

Ja das ist weil du das Log angeschaltet hast

Ich habe nochmal über das Thema nachgedacht und ich halte die Idee Dynamische Signale schon für machbar... allerdings anders als ich zuerst vorgeschlagen habe. Entsprechend deinem Ansatz (1) könnte man den Fahrtweg von Zügen abfragen und prüfen in welchen Abzweig dieser hinter einem Signal wäre. Intern lässt sich das in TPF2 via MOVE_PATH abfragen. Dieser Ansatz hätte den Vorteil, dass man keine manuelle Zuordnung machen muss und daher ohne GUI auskommt!

Man bräuchte extra Konstruktionen, die man neben das Gleis platziert, während auf dem Gleis selbst ein unsichtbares Signal ist. So vermeidet man Eingriffe in das Gleisnetz und die Definition als Konstruktion ermöglicht Parameter (an/aus, Hp2, dynamische Geschwindigkeit, Geschwindigkeitsvoranzeiger, Gegengleis...). Also praktisch eine Fake Signalkonstruktion, die man nicht funktional aufs Gleis setzen kann, aber mit einem Script verbunden ist. Die müsste man entweder aus den bisherigen Signalmods speisen oder sauber neu programmieren mit allen Kombinationen und Teilmodellen.

Hier ein grobes Code Konzept.

1. Wenn ein neues Dynamisches Signal platziert wird, wird es in eine Liste aufgenommen zur Zuordnung.

2. Es braucht eine Funktion (udpateRailNetworkInfo) um regelmäßig die Gleisinfrastruktur durchzugehen und dabei die Abzweige hinter den Signalen analysiert. Mit den api Funktionen sollte das möglich sein, den Nodes und Edges zu folgen. Dabei wird die tatsächliche Höchstgeschwindigkeit ermittelt, sodass automatisch die richtige Nummer am Signal gezeigt wird!

3. Kontinuierlich muss dann geprüft werden ob ein Signal angeschaltet werden muss, weil ein Zug sich einen Pfad reserviert (checkSignalStates). Dazu muss der Move Path von allen Zügen analysiert werden, da sich nur hier die Informationen finden. Dann weiß man wo der Zug hinwill und kann das richtige Signalbild bestimmen. Die Konstruktion kann entsprechend geupgradet werden.

function udpateRailNetworkInfo()
     
     -- for all dynamic signals:
    
    -- echtes signal am Gleis finden
    signals = game.interface.getEntities({radius=5,pos={x,y}}, { type = "SIGNAL" })
    assert (#signals==1)

    signal_edge = api.engine.system.streetSystem.getEdgeForEdgeObject(signals[1])
    n2e = api.engine.system.streetSystem.getNode2TrackEdgeMap() -- Gleis Graph

    -- folge in Signalrichtung über alle Weichen/Abzweigungen bis zum nächsten Signal
    -- ermittle dabei jeweilige Richtungen und Maximalgeschwindigkeiten
end

function checkSignalStates()
    trains = {}
    api.engine.system.trainMoveSystem.forEach(function (a) table.insert(trains, a) end)
    -- for all trains
    
    move_path.path.edges[move_path.dyn.pathPos.edgeIndex]
    ... bis 
    move_path.path.edges[move_path.dyn.pathPos.edgeIndex+move_path.path.endOffset]  -- geht manchmal immer noch übers Signal hinaus
    
    -- checken ob einer der pfade über eines der Signale läuft und in welchen Abzweig (und ob das Signal an ist)

Analog diesem Ansatz wäre es auch einfach möglich, von Vorsignalen (auch als extra Fake-Konstruktion) den Pfad zum nächsten Hauptsignal zu ermitteln und dann abzuändern, wenn das Signal umschaltet. Hier sollten sich aber keine Abzweige bis zum Hauptsignal befinden.

Soweit das Konzept. Ich lasse das einfach mal hier liegen. Ich werde da nämlich in absehbarer Zeit nicht selbst daran arbeiten können. Wenn sich jemand der Sache annehmen will, werde ich aber gerne unterstützen!

Sowieso wäre es hier notwendig, dass ein Signal Modder von der Modwerkstatt entgegenkommt.

breite des Baumenü anpassen

hab ich auch noch ne gesprengte (und verbogene) Brücke auf Lager

So ist es, OSM ist als 2D Kartendarstellung gedacht. Die Höhendaten müssen von einer anderen Quelle kommen.

Der "ele" Tag ist nur sehr punktuell genutzt und daher nicht sinnvoll zu nutzen (wiki: "Dieser Wert ist hauptsächlich für Berggipfel vorgesehen")

Ich habe mir für die Frankfurtkarte damals ein DSM von opendem geholt, aber würde es heute wahrscheinlich anders machen. Siehe Real-Nachbau in TPF 2

Es gibt wohl keine Höhendaten, die so hoch aufgelöst sind, dass sie Dämme und Brückenrampen perfekt abbilden, auf denen der OSM Importer direkt die Straßen und Gleise bauen kann. Daher ist das Terrain tatsächlich ein Knackpunkt, da sich dieser Schritt nicht automatisieren lässt. Das muss man vor dem Import von Hand machen (siehe Map preperation).

Zitat von Rutel

Eine performance-mäßige Frage: ich versuche möglichst, Feldwege etc. von normalen Straßen für Fahrzeuge abzukoppeln (nur die violetten Verbindungen bei AltGr-L), um die Wegfindungsroutinen zu entlasten; Fußgänger laufen ja sowieso nicht so schrecklich weit. Meint Ihr, daß das was bringt, gerade auch im Zusammenhang mit so einem Monster-Import?

Klingt sinnvoll. Der Straßengraph wird damit vereinfacht, was die Wegsuche verkürzen sollte. Um genaueres zu wissen bräuchten wir allerdings den Quellcode oder UG müsste ein paar Hinweise geben, was konkret hilft.

Es gibt auch eine Option beim OSM Import, solche Wege wegzulassen, das spart auch RAM ein. Ich hatte auch überlegt, sie via Texturen nachzumalen, aber gibt keine API dafür.

Ich plane aber sowieso möglichst wenig Autoverkehr, um mir die Performance nicht direkt zu versauen. Der Plan ist, Gebäude nur mit Fußgänger Anschluss zu setzen und vereinzelt Automagneten zu setzen, dann aber mit hoher Kapazität (in der Hoffnung dass die Wegsuche nur einmal für alle Bewohner gemacht wird, aber auch hier nur eine Vermutung).

TPF2 ist ein teures Hobby, wenn man es drauf anlegt, aber moderne Hardware lohnt sich...

Ich kann nur jedem empfehlen klein anzufangen. Natürlich ist es schade das Gebiet abzugrenzen, aber so wird man nicht nur bessere Performance haben, sondern auch schneller zu Ergebnissen kommen.

Endlich ist es soweit!

Der OSM Importer ist Release fertig.

Das Tool ist hier auf Github verfügbar: https://github.com/Vacuum-Tube/OSM-TPF2-Importer

Dort finden sich Code und Dokumentation (englisch).

Die zu schreiben hat einige Zeit gekostet, ich hoffe aber es ist vollständig und verständlich. Insgesamt ist das doch sehr umfangreich geworden.

Ich wünsche viel Spaß damit bei zukünftigen Nachbauprojekten!

Ich weiß nicht genau was du vorhast.. Es klingt als würdest du Modelle via Konstruktion ins Spiel bringen wollen.

Lua und Scriptmodding decken ja aber noch viel mehr ab. Wie du gemerkt hast, gibt es dafür keine wirklichen Tutorials. Das muss man sich größtenteils durch andere Mods und Trial and Error erlernen. Das wiki ist dennoch ein guter Startpunkt, weil es eine gute Übersicht über die Modding Möglichkeiten gibt.

Vielen hilft es, in andere Mods zu schauen und an Beispielen zu lernen. Such dir einfach Mods raus, die du schon benutzt und verstehe, wie die funktionieren. Hier gibt es allerdings das Dilemma, dass kleinere Script Teile von Moddern, die wenig mit Lua machen, manchmal unnötig kompliziert sind und so manchmal die Fehler von anderen kopiert werden - auf der anderen Seite sind umfassendere Script Mods oft schwer für Einsteiger zu durchblicken, weil Script Modder den Code mit eigenen Funktionen optimieren (was langfristig den Code besser macht).

Zum Lua lernen: https://www.lua.org/pil/contents.html

Lua hat seine Eigenarten und ist manchmal etwas umständlich, aber wenn man damit klarkommt, ist es gar nicht schwer. Grundprinzip: alles ist eine Table, also eine Art dict, was Lua aber auch als Array nutzt.

Der ParamBuilder ist ein Interface für Parameterdefintionen und die Ermittlung vom ausgewählten Wert in der updateFn. Man sollte schon wissen wie Parameter funktionieren: https://www.transportfever2.co…ding:constructionbasics&s[]=parameter

Man kann damit die interne Darstellung als Integer umgehen und direkt die Werte nutzen um die es eigentlichen geht (Strings, Dateinamen, ...)

Texturen auswählbar heißt mehrere Modelle, schätze ich. Skalierung ist eines der meist gemachten Dinge, daher schau einfach wie andere Mods das machen. Manche beschreiben die Transf Matrix direkt; der saubere Weg ist, die Scale Funktion der transf.lua zu benutzen.

denke nicht, außer bei kollisionsfreien Assets

Die RAM Anforderungen betreffen das Thema Nachbau i.A. und habe ich hier geschätzt: Real-Nachbau in TPF 2 (wobei die Spalte hoch für OSM Import gedacht ist)

Es hängt logischerweise von der Kartengröße ab, aber auch von der Bebauungsdichte. Eine ländliche Region mit ein paar Dörfern braucht natürlich viel weniger als wenn man eine stark besiedelte Metropolregion nachbaut.

Das Ding ist natürlich, dass durch meinen Ansatz enorm viele Elemente ins Spiel kommen, die man beim normalen Spielen nie erreicht. Der Nachteil ist, dass man direkt nach dem Import mit dieser Menge an Elementen umgehen muss, während beim klassischen Bauen die Größe langsam anwächst und man entscheiden kann aufzuhören. Das hat andererseits den Vorteil, dass man direkt weiß wie die Anforderungen für den vollen Ausbau der Karte tatsächlich sind.

Nach meinen Erfahrungen sind für die RAM Auslastung die Anzahl Edges (Straßen/Schienen Segmente) entscheidend. Die verbrauchen durschnittlich 100KB pro Edge (wegen der reversiblen Terrainänderung). Die 3,7 Mio Bäume erzeugten nur ca. 1GB zusätzlich. Wie ich am Anfang des Threads schon beschrieben hab, gibt es für Frankfurt 500 000 Edges, welche ich im Härtetest gebaut habe. Zum Vergleich, Hans Dampfs 1. Karte hat 50k Edges. Man erreicht mit dem OSM Import bei größenwahnsinnigen Karten also Werte, die wahrscheinlich noch kein Spieler gemacht hat. Es ist also tatsächlich eine spannende und offene Frage, ob das Spiel unter solchen Umständen überhaupt lauffähig ist.

Wenn nicht, wird man die Anzahl der Edges wohl oder übel verringern müssen und auf kleinere Wege/Pfade verzichten.

Ich finde das Thema interessant, mal eine Herausforderung, wo keiner was auf Lager hat.

Mir ist aufgefallen, dass der Cargo Hub auf meiner Asienkarte schon fast alle Transportarten beinhaltet. Flugzeuge haben noch gefehlt und Straßenbahnen... werden per Zug transportiert. Fahrräder gibts aber definitiv nicht.

Hab ich übrigens schon gesagt, dass Flüsse/Bäche als Wassertexturstraßen gebaut werden?

Die werden praktischerweise 1m abgesenkt im Terrain.

eis_os Danke hat geklappt. Straßen gehören jetzt dem Spieler.

Ich arbeite kontinuierlich an der Frankfurt Karte weiter, bin aber noch nicht ganz fertig mit den Terrain Vorbereitungen. Parallel bin ich dann immer am Testen mit Teilausschnitten. Dadurch ergaben sich zuletzt noch eine ganze Reihe kleiner Fixes/Optimierungen. Der Plan war eigentlich, erst nach dem kompletten Import eine finale v1.0 hochzuladen, aber ich werde das jetzt vorziehen. Änderungen wird es wahrscheinlich sowieso geben.

Aber bald sollte es dann soweit sein und dann geht es hoffentlich mit dem Nachbau vorran. Wird dann einen eigenen Thread geben natürlich. Aber alles zu seiner Zeit. Auch wenn das Ergebnis von OSM Importer auf den ersten Blick gut aussieht, sind im Detail noch Anpassungen nötig (Postprocessing).

Und dann war da ja noch die Performance Frage... RAM ist bestellt ich hoffe 32+64 reichen aus mal schauen ob es dann flüssig läuft... bin gespannt

In den letzten Wochen komme ich gut voran, die Dokumentation ist fast fertig.

Spontan ist mir noch eine weitere (und wahrscheinlich letzte) Automatisierung eingefallen. Brücken sind oft problematisch, da die Höhe der Nodes ja praktisch nur durch das Terrain ermittelt wird. Besteht die Brücke nur aus einem Segment, hängt sie schön gerade in der Luft, wenn die Brückenenden ordentlich geformt wurden. Sind allerdings zwischendrin Nodes, so kleben diese am Boden.

Hier eine Auswahl typischer bis extremer Fails:

Bisher hatte ich dieses Thema der Nachbearbeitung zugeordnet, da man ja mit dem Rampenvergleichmäßiger mit wenigen Klicks daraus eine gerade Verbindung machen kann:

----->

Dann dachte ich mir, dass ich die Nodes dazwischen auch einfach mithilfe der Anfangs- und Endnode Höhe interpolieren kann. War schneller implementiert als gedacht.

Das hier nun direkt nach dem Import.

Was man leider auch sieht, dass auf meiner Karte Overlay und OSM Koordinaten Abweichungen von bis zu 5m haben, was nervig werden kann. Daher achtet sehr präzise auf die Anpassung!

-----------------------------

Außerdem habe ich mir Gedanken zum Thema Häuser gemacht. Eine ziemlich herausfordernde Aufgabe zur Automatisierung, wenn man unterschiedliche Haustypen und Formen berücksichtigen muss. Ich werden Häuser erstmal Stück für Stück manuell ohne Kapazitäten setzen und schauen wie ich voran komme. Es gibt ja auch Mods mit Straßen wo automatisch Häuser sind, vielleicht ist das praktisch.

Stellt sich natürlich auch die Frage, ganz klassisch mit TPF2 Städten und Gebäudegenerierung zu arbeiten, wobei ich das eigentlich aufgegeben habe. Man würde sich so auf einer großen Karte, die nicht nur ländliche Kleinstädte hat, innerhalb kürzester Zeit die Performance ruinieren. Vielleicht möchten manche aber bei einem kleineren Nachbau doch damit arbeiten und man kommt ja auch schneller zu Ergebnissen so. Mittlerweile gibt es ja mit den Parcels/Zones der CommonAPI auch Möglichkeiten den Bauwahn etwas einzudämmen. Das Problem was ich noch sehe, ist allerdings dass die "KI" mit aktiven Stadtwachstum die nachgebauten Straßen umwandeln kann und neue bauen wird. Die vom Tool gebauten Straßen sind nicht gesperrt, da ich das playerOwned Feld bei Proposals irgendwie nicht setzen kann.

Zitat von P8_2401_Coeln

Was ist der Construction Mover, wozu dient er und wo finde ich ihn?

Mein Suchtool findet auch manchmal Steam Einträge: Forum Suche via Google (Site Search via Google)

Hat der Construction Mover eigentlich noch Vorteile oder kann man genauso gut Move It verwenden?

In den Parametern der Industrie.

Kenne gerade keine Möglichkeit einer globalen Einstellung.

You would need to create a mod if you want to add custom pedestrians/models.

Read the wiki to understand how Mods work by overwriting files in a virtual file system. For this it does not matter if files are zipped. (You could even unzip them in the game directory)

HOWEVER, be careful if you edit or add "person" models. The past has shown that this can trigger mod issues when person mdls are removed from a savegame or change properties during a savegame.

Im Gegensatz zu anderen Fehlern ist dieser ziemlich eindeutig zu analysieren....

Wie gesagt, es kann sein, dass du vor langer Zeit eine Industriemod aktiv hattest, die die Levels erhöht, dann hatte deine Sägemühle auf LVL 6 upgegradet und Jahre später bricht die Produktion jetzt bei dir aus irgendeinem Grund ein und es wird ein Downgrade getriggert, wo ein Fehler geworfen wird weil Sägemühlen nur 4 Level haben können.

Übrigens braucht man nicht löschen, es reicht auch Auto-Upgrade zu deaktivieren (Sandbox), dann ändert sich das Level nicht mehr von alleine.