Beiträge von VacuumTube

Reproduzierbar?

Bitte mir mal die osmdata.lua schicken.

In der Tat, der Bremswegabstand bestimmt den Zeitpunkt des Umschaltens des Signals, weil hier entschieden werden muss, ob der Zug bremst oder fahren kann.

Das hat leider den Nebeneffekt, dass Züge bei niedrigen Geschwindigkeiten "nicht weit voraus planen".

Hast du Realistic Train Brake aktiv? Weil das ändert ja den Bremsweg und daher auch das Umschalten von Signalen. (Auch das von Bahnübergängen btw)

Das mit den Wegpunkten überrascht mich, aber ist wahrscheinlich dem geschuldet, dass Wegpunkte ursprünglich im Spiel nichtmal ihr Aussehen im "on" state ändern. Die werden dann vermutlich schon "on" geschaltet, wenn sie sich bereits im MOVE PATH befinden (der wie ich ja rausgefunden habe, deutlich länger als der Bremsweg ist).

--- Version 1.2 ---

Ich habe die Neuerungen in einer neuen Version zusammengefasst: https://github.com/Vacuum-Tube/OSM-TPF2-Importer/releases

Außerdem habe ich auch aus dem Python Code eine exe Anwendung für Windows Nutzer gemacht. Das ist praktisch für User die kein Python installieren wollen und vereinfacht hoffentlich die Anwendung etwas.

Ich hatte die Möglichkeit einen 5800X und 5800X3D zu testen.

In einem Save ist die Simulationsperformance um 8% gestiegen, in zwei anderen um fast nichts (<1%). Die FPS sind auch leicht gestiegen. Aber ich würde nicht sagen, dass TPF2 den erweiterten L3 Cache effektiv nutzt. Nichtsdestotrotz ist die Investition für andere Spiele (z.B. MS Flight Simulator) oder zukünftige Spiele eventuell wert.

Um überhaupt eine passende Antwort zu geben, müsste man allerdings erst wissen wie TPF2 gespielt wird, denn darauf kommt es an. Einfach gesagt wird ein Schönbauer lieber Geld in eine GPU stecken und ein Wirtschaftsspieler in CPU.

Am Ende gibt es keine wirklichen Minimalanforderungen für eine bestimmte FPS leider. Es ist immer ein Kompromiss zwischen Budget, Mapausbau und resultierender Performance (Ruckler & FPS). Also eine Art Dreieck sozusagen.

Wegpunkte sind eine interessante Idee, um zusätzliche Informationen ohne GUI einzuspeisen. Z.B. Buchstaben für Richtungsanzeiger.

Ich würde aber versuchen, ohne auszukommen wo möglich, um die Komplexität klein zu halten. Wenn du die Geschwindigkeit eh ausliest (für automatische Geschwindigkeitsanzeiger), kann man daraus auch ablesen ob es sich um ein Abzweig mit gelben Licht handelt. Ich würde voraussetzen, dass Realitätsfeteschisten eh ein entsprechendes Gleis mit der richtigen Geschwindigkeit (in DE glaube 60km/h für HP2?) haben - daran könnte man das Signalbild bestimmen.

Die Auswahl im Menü sollte dann idealerweise einfach nur die baulich (konstante) Zusammenstellung darstellen, also zB Ausfahrsignal + dynamschem Geschwindigkeits(vor)anzeiger, oder Vorsignal+Richtungsanzeiger. Alles was dynamisch ist, sollte idealerweise nicht vorgegeben werden müssen, sonder automatisch besimmt werden, via Auslesen von Gleisgeschwindigkeit und reservierter Abschnitt. Theoretisch sollte man anhand der Geometrien auch rausfinden können was der "rechte"/"linke" Abschnitt ist (zB für Gegengleisanzeiger).

Wenn ich da noch eine fehlende Funktion beisteuern kann, sag gerne Bescheid.

Ich habe nun an einer Funktion gearbeitet, die unpassend hohe Krümmungen erkennt und dann entsprechende Nodes entfernt.

Es gibt ja eh unnötig viele Nodes, weil OSM keine echten Kurven darstellt. Daher besteht hier auch Optimierungspotential, um die Anzahl Edges im Spiel möglichst gering zu halten, da dies ja anscheinend hohen Performance Impact hat.

Daher habe ich eine weitere Funktion geschrieben, welche prüft ob eine Node entfernt werden kann, ohne dass die neue Kurve dabei einen zu hohen Fehler erzeugt.

Damit kann man insgesamt etwa 40% Edges einsparen!

Und die Kurven werden dadurch auch nochmal deutlich glatter.

Und man spart sich einen Teil der Nachbearbeitung.

It does not work in a simple way.

The Gui Api creates a lot of possibilites as I have shown in https://www.transportfever.net…6204-advanced-statistics/

There is also a Slider Component and a lot more.

Working with events and setVisibility, the mentioned characteristics could be realized.

Since it would be a special window, the placing would need to be handeled differently, but there are Mouse events.

Enzojz made it possible to bring something like that into the usual parameter window https://steamcommunity.com/sha…iledetails/?id=2138212041

This is just to say that it should be possible, with a lot of work.

If you are not willing to spend this time getting into the Api just for a little gui improvemnt, do it like other modders with dummy parameters, like DH106 said.

I wouldn't say it's impossible for the game, since there is an Api for Gui Modding. In theory you could build a specific window, where the slider / checkboxes etc. could be handeled dynamically. However, it seems an overkill if it can also be done with the static parameters somehow else.

Die aktuelle TPF2 Version ist 35732

Welche Spielversion verwendest du ?

Bitte eine stdout.txt

Nagut, dann auch nochmal mein Senf dazu:

Ich hatte zu Beginn der Pandemie viel Zeit und war an zahlreichen Mods dran. Modeinstellungen waren ein überfälliges Feature, aber es gab zum Glück eine Community Lösung: Das merk_modutil !

Das war zu dem Zeitpunkt nichts neues (schon aus TPF1 aber funktionierte direkt in TPF2) und schien mir eine geeignete Lösung. Via CommonAPI gab es sogar eine GUI zum einfachen Ändern der Werte. Daher schrieb ich Anleitungen um es allen einfach zu machen.

Modeinstellungen selbst waren zu dieser Zeit eigentlich noch ein selten genutztes Novum. Wie oft hat man früher bei manchen Mods gesagt, wäre es nicht schön diesen Parameter etc. individuell anpassbar zu machen. Das modUtil/settings.lua wurde von vielen Moddern aus Faulheit leider nicht genutzt (ich finde es aber nicht komplizierter als die UG Lösung, mit dem ganzen Parameter Handling). Die Folge war dann teilweise, dass manche Modder dieselbe Mod mehrmals hochluden, obwohl nur 1 Wert geändert wurde (..ähm ja auch ich...) Natürlich keine schöne und nachhaltige Methode.

Wenn ich damals gewusst hätte, dass UG nur einen Monat später ein Update mit einer eigenen Lösung ankündigt, hätte ich es wahrscheinlich anders gemacht. Natürlich finde ich es gut, dass es eine offizielle Lösung gibt, aber die kam halt (wie so vieles) zu spät... und war wie eis_os sagt, noch relativ lang verbuggt (ein Grund für ParamBuilder).

Da ich das Spielen mit Städtebau KI aufgegeben habe und mich auf andere Dinge konzentriere, wird da von meiner Seite aus nichts mehr kommen. Ja es wäre nicht furchtbar viel Aufwand, aber so ein Update kostet mit dem ganzen drumherum dann schon wertvolle Zeit, wobei nichtmal neue Funktionalität hinzukommt, sondern nur User-Bequemlichkeit. Da ist mein Idealismus dann schon irgendwann am Ende. Zu Bugfixes fühle ich mich gewissermaßen schon verpflichtet, aber ich habe nicht den Anspruch jede Mod perfekt zu machen. Am Ende ist es meine Entwicklungszeit vs. die Zeit des Users sich die Modbeschreibung durchzulesen oder einen Lexikonartikel.

Außerdem: Was wäre die Reaktion, wenn ich jetzt diese Mod updaten würde? 10 Spieler würden sich freuen. Aber auf Steam würde ich zig Kommentare bekommen "Warum gehen meine Einstellungen nicht mehr?". Das müsste dann ja jeder neu einstellen. Daher bleibe ich gerne beim Status Quo, wenn ein Update nicht wirklich notwendig ist.

Ich hatte schon irgendwo mal ein Plädoyer zu Modupdates gehalten: Ich finde, das Updaten und der Support von Mods wird zu wenig wertgeschätzt. Neue Mods erhalten immer ungleich mehr Aufmerksamkeit. Aber das aktuell Halten, Bugfixen, und Optimieren von Mods über mehrere Jahre ist ein signifkanter Anteil am "Modlebenszyklus", den man auf User Seite kaum sieht. Updates werden als selbstverständlich erachtet und bekommen nur (negative) Aufmerksamkeit wenn Probleme auftreten.

Und ja, warum nimmt das nicht jemand als Einstiegspunkt zum Modden? Das sieht nach einer sehr guten Anfängeraufgabe aus.

Übrigens hat jemand zumindest für die Schwester-Mod Town Building Levels die UG Modeinstellungen erstellt. Da könnte man sich sehr gut dran orientieren.

@TE + EMP

da ich kein Update machen werde, brauchst du die Mod auch nicht zu backupen. Das schwierige diesem Fall eines Updates wäre auch nicht die Einstellungen der settings.lua wiederherzustellen, sondern das Update überhaupt mitzubekommen, um zu reagieren.

Regelmäßig aufgerufen heißt eigentlich: die Gamescript "update" function. (alle 0.2 Sekunden)

Ich würde aber erstmal die Funktionen allgemein "bottum-up mäßig" entwickeln und mit Console arbeiten / die Funktionen aufrufen (mithilfe globaler Variablen). Das hat auch den Vorteil, dass dir bei Fehlern nicht gleich das Spiel abschmiert. Da kann man dann auch Timing Tests machen. Wenns läuft, das dann einmal auf einer großen Karte testen und schauen wie es sich verhält. Erst wenn die Ausführungszeit problematisch ist, würde ich mir Gedanken um eine Performance Optimierung machen.

Runden auf nächste durch 10 teilbare Zahl, das ist das kleinste Problem. Ich würde ab 5 einfach aufrunden.

Im Stumpfgleis muss ja ein Bahnhof sein der auf der Linie angefahren wird. D.h. der reservierte Pfad geht dann eben zum Halt und nicht zum nächsten Signal. Den Fall muss man generell auch abdecken natürlich. (Und schauen wie sich MovePath dabei verhält).

nightfury34 klingt gut! Bei weiteren Fragen einfach melden.

Um das Iterieren der Züge kommt man vmtl nicht drum herum.

Die Signale sollten aber in der Mod abgespeichert werden als Liste im state eines Gamescript. Wenn man ein neues (Fake/Konstruktions)Signal baut, kann man es in die Liste aufnehmen.

Prinzipiell ja. Die Frage ist, wie du diese ganzen manuellen Definitionen machst.

Meine Überlegung war, sich eine Gui zu sparen und die Geschwindigkeit automatisch vom dahinter liegenden Gleis auszulesen.

Danke für euren Input!

Das streetutil.addEdgeAutoTangents war mir neu, aber scheint sinnvoll.

Das mit dem EdgeGeometry sieht interessant aus, wobei bei mir auch wenn ich eine Gerade baue in den Proposal Daten (entity2tn) immer EdgeGeometry.CubicSpline angezeigt bekomme. Wird also wohl nicht wirklich genutzt.

eis_os ich will natürlich nichts im Spiel ändern. Kann ich auch gar nicht.

Aber gerade weil manche Sachen wie EdgeObjects relativ auf die Länge bezogen werden, stellt sich die Frage wie TPF2 die Länge genau berechnet.

Ich hatte in meiner Implementierung noch einen Denkfehler, weil ich den Kurvenparameter 0..1 bei den Splines nicht mit der Länge korrigiert hatte. Damit erhalte ich auch sinnvolle Tangenten direkt von der Spline Interpolation. Die muss ich dann auch nicht mehr in der Länge korrigieren. Die Länge der Tangenten hat ja auch einen direkten Einfluss auf die Geometrieform einer Kurve (Gerade ausgenommen).

Mathematisch ist die Tangente ja nichts anderes als die Geschwindigkeit mit der man durch die Kurve geht. Und die sollte überall konstant sein (bezogen auf die Weglänge also 1). D.h. die Tangenten von einer Edge zur nächsten sind auch tatsächlich gleich in TPF2 - nicht nur die Richtung, sondern auch die Länge - was man an der Darstellung in TPF2 nur nicht direkt sieht, da die Tangenten dort für jede Kurve individuell mit t=0..1 gelten.

Die Natural Splines sind jetzt implementiert und sehen gut aus.

Die Nodes können besser zu einer Kurve verbunden werden als mit der vorigen Methode und mit höheren Kurvenradien/Geschwindigkeiten.

Hier beispielthaft eine Kurve:

mit Geschwindigkeit(Tangenten) und Beschleunigung (2te Ableitung)

Der Betrag der Geschwindigkeit sieht so aus:

die Annahme ist also ziemlich genau erfüllt.

Hier die Krümmung (Kehrwert vom Kurvenradius):

Von der Kurve her würde man hier einen deutlich glatteren und einfacheren Verlauf erwarten. Da die Nodes aber nicht perfekt gesetzt wurden, ergibt sich die variiernde Kurvenkrümmung. Maximale Krümmung ist 0.006 -> 167m. Das kommt real bestimmt nicht hin. Kurven in Kartendarstellungen sehen also nur auf den ersten Blick glatt aus.

MOVE_PATH ist ein ComponentType und hängt an entities wie Zügen. Ich weiß gar nicht ob Autos auch einen MovePath haben.

https://transportfever2.com/wi…pe.html#MovePath.DynState

Am einfachsten nähert man sich der Sache, wenn man mit dem CommonAPI Inspektor Objekte anklickt und so schnell sehen kann, welche Components mit welchen Daten dahinter hängen.

Ich habe auch noch nie was mit MovePath gemacht, aber wollte für den vorigen Post die Machbarkeit prüfen.

Meine Erwartung war, dass dort eine Liste von Edges liegt, welche der Zug "reserviert" hat, also das Gleis bis zum nächsten Signal oder Bahnhof Stop auf der Linie.

Offenbar liegen aber die ersten Elemente hinter dem Zug auch noch drin. Zum Glück gibt es aber den Index, womit man den Ort des Zugs rausfindet. Der endOffset liegt dann ungefähr beim nächsten Signal.

Es ist kein Problem einen Mod im Download Bereich reinzustellen, wenn man dazu schreibt dass es sich um einen unfertigen Zustand / Beta Version handelt. Ob jemand sich das dann runterlädt bleibt jedem überlassen auf eigene Verantwortung. Je nach Art von Mod sollte man diese nur in Testsaves verwenden, wenn sich noch große Änderungen ergeben (oft geht es aber ohne Probleme).

Man kann einen Filebase Eintrag auch versteckt halten und nur bestimmten Benutzern zugänglich machen. Das ist aber eher unpraktisch und keine echte Beta Funktion.

Bilder kannst du dann hier im Thread anfügen für Feedback und Hilfe.

Also das Spiel geht davon aus, dass die Tangenten immer auf die Länge der Kurve normiert sind?

So wie ich das gesehen habe, ist die Länge von kubischen Splines gar nicht mal so leicht berechenbar.

Weiß jemand was passiert, wenn die Tangenten andere Längen haben?

Ich traue mich aktuell noch nicht den finalen Import durchzuführen und das liegt an den Kurven. Wie schon im ersten Post beschrieben liegt das Problem darin, dass Nodes in OSM nicht immer mit der höchsten Genaugikeit platziert werden, was in Karten zwar nicht so auffällt. Da Gleise hohe Kurvenradien erfordern, die auch noch möglichst konstant sein sollten, kann das aber im Spiel sehr wohl zum Problem werden, wenn wackelige Kurven mit geringen Radien entstehen.

Aktuell berechne ich mir zwar Tangenten damit es keine Knicke in den Gleisen gibt, aber das war etwas improvisiert.

Daher beschäftige ich mich gerade intensiver mit dem Thema Kurvendarstellung in TPF2.

Vielen Dank an WernerK für die Aufarbeitung des Themas im Lexikon.

Kurven werden in TPF2 als Hermite-Kurven modelliert. Das sind kubische Splines, also einfache Polynome.

Ich habe etwas gebraucht, um zu verstehen, dass Hermite einfach nur heißt, dass man die Tangenten an allen Punkten vorgibt. Im allgemeinen Fall kann man das kubische Polynom aber auch anders bestimmen.

Polynome sind einfach zu berechnen und geeignet für Computerdarstellungen.

Die Geometrie von Eisenbahnstrecken folgt aber eigentlich einer ganz anderen Logik.

Kleiner Exkurs: Geometrie bei Planung von Eisenbahnen

Im Prinzip gibt es nur 3 Arten von Geometrien: Geraden, Kreisbögen und Übergänge dazwischen.

Die Übergänge werden gerne mit Klothoiden modelliert, weil diese die schöne Eigenschaft haben, dass die Krümmung (Kehrwert von Kurvenradius) linear mit der Kurvenlänge zu- oder abnimmt. D.h. wenn man mit konstanter Geschwindigkeit entlang der Bahnlinie fährt, von Gerade zu Kurve, nimmt die Krümmung nicht schlagartig, sondern linear zu. Ansonsten würde die Fliehkraft einen Sprung machen, was einen Ruck verursacht und nicht angenehm wäre.

Dasselbe passiert übrigens auch bei Straßen: Der Übergangsbogen sorgt dafür, dass ich linear das Lenkrad einschlagen kann und erst wenn der Kreisbogen erreicht ist, bleibt der Einschlag konstant.

Diese Darstellung ist viel intuitiver, da sie (im Gegensatz zur Koordinatenbetrachtung der kubischen Splines) aus der Sicht des Fahrzeugs entlang der Kurve gemacht wird. Leider ist diese Modellierung mathematisch aber schwieriger zu handhaben.

Daher werde ich mit kubischen Splines arbeiten. Trotzdem dachte ich, wäre es schön, wenn ich die Eigenschaft kontinuierlicher Krümmungen (mathematisch: 2fache Differenzierbarkeit) beibehalten kann. Das geht und heißt Natural cubic splines!

Vorher habe ich nur dafür gesorgt, dass die Tangenten an den Nodes gleich sind. Jetzt gehen aber auch die Kurvenradien stetig ineinander über. Damit haben wir Geometrien, die besser sind, als man sie beim normalen Bauen in TPF2 hat! Eine Gerade bauen und dann ein Kreisbogen - das würde in der Realität zu einem heftigen Ruck führen.

Die Herausforderung jetzt ist eben nur noch, schlecht gemappte Nodes zu erkennen und die Kurve zu korrigieren. Dank der Spline Darstellung kann ich mir den Kurvenradius an jeder Stelle der Kurve exakt berechnen. Nur wie ich die Korrektur mache, weiß ich noch nicht genau.

Das galt jetzt alles für die x-y Ebene (2D). Eigentlich habe ich dasselbe Problem aber auch in der z Ebene für die Höhen. Die Höhe entlang der Kurve ist zum Glück nur 1 dimensional. Es ist trotzdem ein bisschen anders, weil die Höhen ja erst im Spiel festgelegt werden und daher die z Werte und Tangenten in Lua berechnet werden müssen. Falls ich hier noch einen Geistesblitz bekomme, wie man den Verlauf geschickt glätten kann, erhält man vielleicht direkt passende Steigungen und muss nicht überall den Ramp Equalizer anwenden. Vielleicht muss ich das Terrain auch zwischen den Nodes abtasten. So müsste man sich ggf auch weniger Mühe in der Terrain Vorbereitung geben.

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.