Nodes und Edges - Bedeutung der Zahlenwerte

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


  • Immer wieder tauchen Nodes und Edges in .con-Dateien und anderswo auf. Gibt es eigentlich irgendwo eine Doku, wo die einzelnen Werte genau erklärt werden? Sind ja irgendwelche Maße, nur weiß ich nicht, wofür genau. Im offiziellen Modding-Wiki habe ich nicht allzuviel Erhellendes gefunden.


    Um mal konkret zu werden, ich meine sowas hier:

    Code
        edges = {
          -- one entry refers to a position and a tangent
          { { .0, -79.0,  .0 },  { .0, 15.0, .0 } },  -- node 0 (snap node)
          { { .0, -64.0,  .0 },  { .0, 15.0, .0 } }   -- node 1
        },
            snapNodes = { 0, 1 },
            freeNodes = { 0, 1 }
          },

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • In der ersten Schweifklammer in Zeile 3 sind Koordinaten eines Nodes drin (xyz). In der zweiten ist die Lane, die an diesem Punkt beginnt, definiert: sie zeigt in Richtung 0, 15, 0.


    Diese Richtung kann beliebig skaliert werden. 0, 15, 0 ist für das Spiel dasselbe wie 0, 1.5, 0 oder auch 0, 1, 0 - es kommt nur auf das Verhältnis zwischen den 3 Richtungen an. Anderes Beispiel: 2, 3, 4 wäre dasselbe wie 1, 1.5, 2 oder 200, 300, 400 etc. :)

  • Also das erste ist der Anfangspunkt, bezogen auf was? Meinen Cursor? Der zweite Wert in der Klammer wäre dann ein Vektor?

    Und was steht in Zeile 4? Der Endpunkt? Und nochmal ein Vektor?

    Ist das so eine Art Bezierkurve? Kann man damit also auch gebogene Verbindungen definieren?

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • https://www.transportfever2.co…ransport_network_provider

    Das ist der betreffende Artikel im Wiki für solche Lanes in models.

    Zitat
    nodes is a list of nodes which are used to define the edges. Every two nodes form one edge. Each node has three properties:
    1. The coordinate relative to the model origin.
    2. The tangent at the node position. Please note that the length of the vector must be equal to the length of the edge. Otherwise negative side effects like compression and stretching of vehicles may occur.
    3. The width of the edge. It is only used for the capacity calculation.

    https://www.transportfever2.co…tructionbasics#edge_lists

    Das ist der betreffende Artikel im Wiki für Edges in constructions. Dort hast du ja auch dein Beispiel her. Unter dem Code steht dann die Erklärung:

    Zitat
    edges is a list. Every two entries form an edge. The first entry is the start node of the edge, the second entry is the end node of the edge. Every node has two vectors with three values:
    • the first vector is the point relative to the construction origin with values for x, y and z axis.
    • the second vector is the tangent in this point with values for x, y, and z axis.

    Alle Koordinaten innerhalb einer Konstruktion sind relativ zum "Ursprung" der Konstruktion, üblicherweise ist der am Cursor, außer es snappt wo dran.

  • Nach ein bisschen Herumprobieren habe ich das Prinzip verstanden. Tatsächlich lassen sich damit z.B. gebogene Gleissegmente herstellen. Das ist schon mal genial, da könnte man z.B. fertige Kurven für Weichen mit bauen. ;) Es ist nur schade, dass es keine Planfigur gibt, das würde alles etwas transparenter machen. Aber ich hab jetzt mal eine gezeichnet und frag einfach mal, ob das so richtig ist. ;) Das Schwarze wäre die resultierende Kurve, in Magenta sind die beiden "Anfasser", also die tangentialen Vektoren, eingezeichnet. Die Endpunkte der Vektoren, also der jeweils zweiten Werte in den geschweiften Klammern, die haben ihren Achsen-Ursprung aber nicht im Ursprung der Konstruktion, sondern jeweils in den beiden Anfangs- und Endpunkten (hellgrün)?? Und die nächste Frage wäre, wie lang müssen die Vektoren jeweils sein, damit ich ein echtes Kreissegment hinbekomme, das an jeder Stelle denselben Radius hat, also keine Klothoide oder sonst was "Eiriges"?


    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Ich kann die Unklarheiten auf jeden Fall verstehen, ich habe auch eine Weile gebraucht, den Sinn zu verstehen.

    Das Datenformat ist schon etwas ungewöhnlich, dass jeweils zwei zusammengehörende Einträge, Anfangs- und Endpunkt, in einer Liste hintereinander sind? Die Liste muss somit immer eine gerade Anzahl haben.

    Dann gibt es die 2 xyz Vektoren in jedem Element, die von der Einheit [m] her dasselbe sind, von der Interpretation ist das 1. ein Ortsvektor, das 2. der Tangentenvektor.

    Dieses Format wird einfach für große Konstruktionen sehr unübersichtlich, das habe ich beim Flughafen festgestellt. Vor allem wenn man später bestimmte Edges/Nodes für andere Definitionen "wieder finden" muss. Für (angehende) Modder ist das schwer, dort ansetzen zu können. Da müssten einfach gewisse Hilfsfunktionen zur Verfügung stehen.


    Wie DH-106 behauptet hat, spielt die Länge des Tangentenvektors keine Rolle, da er ja nur eine Richtung anzeigt. Ich bin auch davon ausgegangen.

    Allerdings hat Enzojz hier behauptet, dass diese Länge einen Einfluss auf die spielinterne Längenberechnung hat.

    Kann das jemand bestätigen?


    Vom Bild her würde ich sagen du hast es verstanden ;)

    Für echte Kreisstücke musst du wohl etwas Mathematik auspacken.

  • Wenn die Tangenten total verkehrt sind, kann das Spiel auch mit einem Crash quittieren. Doppelte Lanes mag es auch nicht gerne...


    Für TPF2 sind für Lanes interessant (streetutil.lua):

    streetutil.addEdgeAutoTangents(edges, p0, p1, t0, t1)


    Das ist eine Funktion, da kippt man seine edgelist, die Punkte und die ungefähren Richtungen als Tangenten rein und bekommt dann das Ergebnis ausgerechnet. Das ist was für faule Programmierer ;)


    Bzw. TPF1 Variante war das hier:

    laneutil.makeLanes(input)

  • Ich bin auch faul, suche aber eher nach einer Funktion, wo ich den ersten Node sowie Radius und Länge der Lane (oder alternativ den Winkel) eingebe und raus kommen die Daten des zweiten Nodes, und zwar so, dass sich ein sauberes Kreissegment ergibt. Wobei am besten das Ganze noch so zurechtgerückt würde, dass mein Cursor wieder in der Mitte liegt.


    Ich habe schon beim Code für den "gebogenen Brückenbahnhof" reingeschaut, wo das Ganze schließlich auch irgendwie implementiert sein muss. Es ist aber so komplex, dass ich im wahrsten Sinne des Wortes nur "Bahnhof" verstehe. :/ Den "Kreisverkehr" habe ich mir auch zu Gemüte geführt, aber hier haben wir den Sonderfall, dass 90-Grad-Stücke erzeugt werden. Ich vermute mal, dass ich die benötigten Funktionen bei diesem vec1, vec2- und vec3-Zeugs finde, aber ich bin da noch auf der Suche.


    Ich finde Bezierkurven einerseits sehr fortschrittlich, bin aber andererseits der Meinung, dass Dokumentation und Anwendung "smarter" sein sollten. Für mich ist das Ganze zunächst nur Grundlagenforschung, um zu verstehen, was eigentlich überhaupt so modbar ist, und welche Algorithmen dahinterstecken. Ob man dann etwas Brauchbares draus konstruieren kann, ist die sekundäre Frage. Vielleicht Weichenschablonen, obwohl die KI ja doch wieder alles nach Lust und Laune verbiegt, was nicht "Bahnhof" heißt.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Ich hab jetzt mal Versuche gestartet, indem ich die Ausrichtung der Vektoren beibehalten, die Länge aber verändert habe. Die Proportion x/y bleibt also konstant.


    1. Versuch


    Code
    { { .0, -20.0,  .0 },  { 0, 10, .0 } },  -- node 0 (snap node)
    { { 2, 20.0,  .0 },  { 1, 10, .0 } }   -- node 1

    Ergebnis: Kurve unterschreitet den Mindestradius an den Enden.


    2. Versuch


    Code
    { { .0, -20.0,  .0 },  { 0, 80, .0 } },  -- node 0 (snap node)
    { { 2, 20.0,  .0 },  { 8, 80, .0 } }   -- node 1

    Ergebnis: Kurve unterschreitet den Mindestradius in der Mitte, wo ein V-förmiger Knick entsteht.


    Womit bewiesen wäre, dass die Vektorlänge zumindest in Kurven nicht egal ist.


    Der goldene Mittelwert liefert wie gehabt ein ansehnliches Ergebnis und auch keine Fehlermeldung:


    Code
    { { .0, -20.0,  .0 },  { 0, 40, .0 } },  -- node 0 (snap node)
    { { 2, 20.0,  .0 },  { 4, 40, .0 } }   -- node 1

    Also scheint es so, dass die Vektoren ungefähr so lang sein müssen wie das Kurvensegment. Aber "ungefähr" ist eben keine Mathematik. Nach wie vor ist der Algorithmus dahinter die große Unbekannte.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Gemäss Wikieintrag zur .mdl definition spielt die Vektorlänge schon eine Rolle:

    Zitat

    2. The tangent at the node position. Please note that the length of the vector must be equal to the length of the edge. Otherwise negative side effects like compression and stretching of vehicles may occur.


    Für einen sauberen Kreisbogen müsste die Länge des Vektors dem Bogenmass entsprechen.


    Beispiel:

    Bei einer Länge von 10m ergibt das für einen Viertelkreis 10*Pi/2

    Code
          { { 10, 0, 0 },  { 0, 15.708, 0 } },
          { { 0, 10, 0 },  { -15.708, 0, 0 } }

    Trolle bitte nicht füttern. Danke!

  • Inzwischen habe ich nach einer Reihe von Fehlversuchen wohl herausgefunden, wie die Formel lautet. Es ist tatsächlich die Standard-Kreisnäherungsformel für kubische Bezierkurven, aber mit - aus welchem Grund auch immer - dreifacher Verlängerung der Tangentialvektoren - und diametral entgegengesetzter Ausrichtung des hinteren Vektors! Die Formel mit Pi/2 sollte wohl auch einigermaßen funktionieren, wird aber im Quellcode-Kommentar zu roundabout.con (die con-Datei für den Vanilla-Kreisverkehr) ausdrücklich als die schlechtere Formel angegeben. Hängt wohl damit zusammen, dass Kreisdarstellungen über Bezierkurven stets nur näherungsweise möglich sind.


    In Tests mit der Formel habe ich bislang korrekte Ergebnisse bekommen. Mit der Formel könnte man z.B. funktionstüchtige vorgefertigte Gleisstücke für Weichen etc. als Assets bauen, und das wäre der Hammer!

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Gemäss Wikieintrag zur .mdl definition spielt die Vektorlänge schon eine Rolle

    Das gilt für den transportNetworkProvider.

    Daher ist die Frage bei edgeLists weiter offen.


    Ich würde vermuten, dass man mit Einheitsvektoren zumindest geometrisch dasselbe Ergebnis hat.

  • Da müssten einfach gewisse Hilfsfunktionen zur Verfügung stehen.

    Hab die streetutil.lua jetzt erst entdeckt. Das geht ja schon so in die Richtung.

    Was mich aber irritiert ist das "street", denn das geht ja genauso für Gleise. Es geht ja um edges, warum nicht edgeutil?


    Eine Schnittstelle nützt auch wenig, wenn keiner sie kennt. Warum wird die im Wiki nicht erwähnt?

    Im Flughafen wurde die auch nicht verwendet, hätte den Code zumindest etwas vereinfacht.

    Und im erwähnten roundabout.con wurde einfach die addEdge Funktion reinkopiert...

    Sieht aus als wäre mehr interne Kommunikation notwendig...

  • UG will das nicht dokumentieren, die Funktion(en) habe ich ja oben schon genannt. Natürlich geht das auch für alle anderen edges.

    Du kannst aber auch nicht erwarten das UG die Funktionen stabil anbieten (siehe TPF), daher rate ich allen, sich ne eigene Lib zu bauen, die ist dann auch stabil...

  • Wenn sie nicht dokumentiert sind, nicht in Beispielen sind, nicht stabil sind und nicht mal UG sie selbst benutzt, frage ich mich, warum es die überhaupt gibt :D

    daher rate ich allen, sich ne eigene Lib zu bauen, die ist dann auch stabil...

    ist wohl die beste Variante, aber kann man halt nicht von jedem Modder erwarten. Und wenn ich mir erst eine Lib schreiben muss, kann ich mich am Ende weniger auf das Wesentliche konzentrieren und weniger Mods produzieren.

    Anfängermodder werden dann aber das direkte Format nehmen und aus den Beispielen kopieren, was erstens länger dauert und zu Unübersichtlichkeit, schlechte Erweiterbarkeit und höhere Bug-Wahrscheinlichkeit führt.


    Darauf wollte ich halt hinaus, es gibt halt bei den Modding-Schnittstellen gewisse "Interface-Lücken" (wie ja auch schon bei den Parametern angesprochen), die zu unnötigem Overhead führen. Wenn das mal zukünftig überdacht wird, können am Ende alle mehr erreichen und mehr Mods erstellen.

  • It explains as follows:


    raw format:

    (p0, v0, w)

    (p1, v1, w)



    friendly format:

    (p0, p1, v0, v1)


    In Which


    p0:start Point

    p1:end point

    v0:start tangent Vector

    v1:end tangent vector

    W: lane width(optional)



    !!!! |v0| ==|v1| and |v0| = |v1| = length of the curve.


    snapNode: indices from 0 for raw foramt

    freeEdge: indices from 0 for raw format, both ends should be specified


    The offical documentation is here:


    Construction Basics [Transport Fever 2 Wiki]


    Hope that helps.

    This guy is too lazy to create a signature. 8o

    2 Mal editiert, zuletzt von Enzojz ()

  • After a little trying, I understood the principle. In fact, it can be used to produce .B. curved track segments. This is awesome, you could build .B. finished curves for switches. ;) It is just a pity that there is no plan figure, that would make everything a little more transparent. But I've drawn one now and just ask if ;) that's the right thing to do. The black would be the resulting curve, in magenta the two "handles", i.e. the tangential vectors, are drawn. The endpoints of the vectors, i.e. the second values in the curly brackets, have their axis origin but not in the origin of the construction, but in each of the two start and end points (light green)?? And the next question would be, how long do the vectors have to be in each case, so that I can get a real circle segment that has the same radius at every point, i.e. no klothoids or anything else "Eiriges"?


    The length of the vector is exactly the length the arc, if it's shorter, you get visually an arch but the game will compute as shorter, if it's longer, you get a nested curve

    You will observe this on a bus or a car, take a straight for a test, you can teleport a bus, or make it very slow, by changing the vector length.

    This guy is too lazy to create a signature. 8o

    Einmal editiert, zuletzt von Enzojz ()

  • If they are not documented, are not in examples, are not stable and do not even use UG themselves, I wonder why they exist at all. :D

    is probably the best variant, but you just can't expect from every modder. And if I have to write a Lib first, I can end up focusing less on the essentials and producing fewer mods.

    Beginner modders will then take the direct format and copy it from the examples, which firstly takes longer and leads to confusion, poor extensibility and higher bug probability.


    I just wanted to do that, there are certain "interface gaps" (as already mentioned with the parameters) with the modding interfaces, which lead to unnecessary overhead. If this is reconsidered in the future, everyone can end up achieving more and creating more mods.

    Some code and resources in the game dates back Train fever, so if you see them not used, that may bacause they were used.

    But the edge principal never changes, I feel the function provided by UG not so handly so I created my own arch lib to process all edges, unless it's really simple by hand.

    This guy is too lazy to create a signature. 8o

BlueBrixx