Posts by nightfury34

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

    Falls du diese Aussage auf das Typ N System bezogen hast, dann ist sie falsch. Normalerweise würde ich auch sagen, dass das Vorsignal eine Spiegelung des nachfolgenden Hauptsignals darstellt. Beim Typ N muss das aber gerade nicht der Fall sein.

    Danke für die Klarstellung! Das vereinfacht das ganze ungemein. Ich hab mir da schon den Kopf zerbrochen, um irgendwelche sonder Konditionen.


    In dem Fall muss ich meinen Signalfundus erweitern, um auch die Vorsignale sinnvoll testen zu können.

    Heute habe ich für euch Vorsignale:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Kleine Frage an alle, die sich mit dem Typ N Signalen auskennen:

    Zeigen die Vorsignale in der Regel ein gelbes Licht an, oder schalten die auf dunkel, wenn gerade keine Fahrstrasse gestellt ist?

    Finde es wirkt ein wenig komisch, wenn nur der Geschwindigkeitsanzeiger angeht um eine Geschwindigkeit "vorangezeigt" wird.


    Wie immer freue ich mich über Feedback :)


    P.S. Das Anzeigen von Geschwindigkeitsausführungen geht auch. Aktuell wird das noch beim Bau entschieden, ob eine Geschwindigkeits-Ankündigung oder Ausführung angeziegt werden soll. Möchte ich aber auch noch dynamisch gestallten.

    Ich vermute, dass die Wegfindung für den "Grünradius" die selbe Antwort annimmt, die bei der Berechnung des Bremsweges zum Signal herauskommt UND das nur das folgende Signal betroffen ist.

    Kann mir gut vorstellen, dass es an die Bremswegdistanz gekoppelt ist. Signale können jedoch auch mehrere gleichzeitig auf Grün gestellt werden. Auf meinem ersten Bild ist auf dem oberen Gleis ein grösserer Haufen an Signalen, welche alle Grün zeigen.

    Ich weiss nicht wieweit du Vorsignale bereits berücksichtigt hast, aber gerade dieser "Kompromiss" erscheint für mich dafür sogar notwendig.

    Vorsignale stehen auch noch auf meiner Liste. Diese unterscheiden sich aber wohl in der Funktion, da sie diese - verbessert mich gerne - das folgende Signal widerspiegelt, während ein wie oben beschriebenes "Wegpunkt" Signal, eigene Inputs z.B. anhand der Streckengeschwindigkeit generiert.

    Aber in dem Fall, werde ich das so einbauen.

    Ein Problem was mich aktuell beschäftigt, ist der extrem kleine "Grünradius" den die Züge haben. Was ich damit meine, die Distanz, ab welcher der Zug sein Signal Grün schalten kann.

    Hier im Bild versuche ich das zu veranschaulichen. In diesem Beispiel z.B. wird gerade einmal bis zu dem rot markierten Signal auf Grün geschaltet.


    Ich meine aber eine Lösung für das Problem zu haben und wollte euch deshalb nach eurer Meinung fragen:

    Zwar haben die Signale eben einen extrem kleinen "Grünschaltradius", Wegpunkte hingegen nicht. Im Beispiel oben wurden alle Wegpunkte bis zum blau markierten auf Grün geschaltet.


    Deshalb hatte ich mir überlegt, ob ich Wegpunkte auch als "funktionierende Signale" nutzen soll. Für den Streckenbau stelle ich mir das dann wie folgt vor:

    (Zumindest auf offener Strecke)



    Man hat die Möglichkeit abwechslungsweise Signale und Wegpunkte zu platzieren, welche von meiner Mod aber beide als Signale behandelt werden.

    So könnte man den Signalabstand erheblich vergrössern und eine "Hochsignalisierung" wäre möglich. (Die Signale kennen jeweils den Status der noch folgenden Signale)


    Das würde natürlich auch bedeuten, dass ein Zug praktisch nur an jedem 2ten Signal (oder je nachdem wie viele Wegpunkte man dazwischen platzieren möchte, natürlich auch mehr oder weniger) halten können.

    Gesamthaft würde das aus meiner Sicht ein schöneres Bild auf den Strecken geben, da nicht mehr alle Signale auf den letzten 10m bevor der Zug da ist auf Grün springen.


    Mich würde interessieren, ob ihr mit einem solchen "Kompromiss" leben könntet und ob ihr sowas überhaupt nutzen würdet oder ob ihr evtl. sogar eine eigene Idee habt :)

    Keine Sorge :)

    Ich war mir nicht bewusst, wie vertraut du mit Modding bist.

    Das wirkt aber so, als hätte der Modder bereits genau das implementiert, was ich oben beschrieben habe.

    In dem Fall müsstest du nur noch die CommonAPI beim Spielen installieren und dann entsprechend Endbahnhöfe markieren

    Klar :) Einfach ungeniert fragen ^^


    Deine .mdl-Files für deinen Wagen/deine Lok sollte es auch entweder gleich zu Anfang oder in den ersten paar Zeilen einen Block:

    Lua
    function data()
    return {
    (...) -- Hier geht das File dann weiter mit Meshes, Materialien, Labellist, Collider, etc.

    geben.

    Und zwischen das


    function data()


    und


    return {


    muss dann der folgende Teil dazwischen:

    Code
        local labelType = "NEXT_STOP"
        if (commonapi ~= nil and commonapi.supports and commonapi.supports("LINE_DESTINATION")) then
         labelType = "LINE_DESTINATION"
        end

    Ansonsten kannst du auch gerne die ersten ~10 Zeilen mal hier als Kommentar da lassen, dann kann ich direkt an deinem Beispiel zeigen, wo das hereinmuss :)

    Ich würde aber versuchen, ohne auszukommen wo möglich, um die Komplexität klein zu halten.

    Die Waypoints sind ohnehin eher als "Addon" gedacht. So nach dem Sinne, für alle, die noch ein bisschen mehr Kontrolle über die Signale haben wollen.

    Alles was machbar ist, soll am besten auch ohne funktionieren.


    Alles was dynamisch ist, sollte idealerweise nicht vorgegeben werden müssen, sonder automatisch besimmt werden.

    Bin ich einverstanden mit. Der User sollte sich am Ende nur noch darum kümmern müssen, wie das Signal ausschaut. Aktuell sind sie noch ganz praktisch fürs Debugging :P


    Die Idee vom Automatischen Gegengleisanzeiger finde ich verlockend, bin mir aber noch unschlüssig. Das Problem, dass das Gegengleis nicht in jedem Land dasselbe ist, wäre mit einem Boolean wohl schnell gelöst, aber ob der Algorythmus dann auch mit den Wilden Gleiskonstrukte der TPF2 Spielern klarkommt, wo von vornherein wohl nicht immer klar ist, was nun Gegen- und "richtiges" Gleis ist.

    Genau, das war der Gedanke dahinter. Ich hoffe so lassen sich trotzdem alle benötigten Signalbilder abbilden. Für den Fall, dass das ganze zu kompliziert in der Bedienung sein sollte, lässt sich dann trotzdem auch auch ein UI dazu basteln.


    Das wird sich dann aber wohl erst nach ein paar praktischen Tests zeigen.

    Im UI-Menü hätte man die verschiedenen Signalbegriffe aufgelistet. Daneben bräuchte es ein Auswahlmenü, um die Wegpunkte den Signalbegriffen zuzuordnen. Intern würden dann die ganzen Abfragen gemacht. In meinem Beispiel, zumindest wenn dies möglich wäre, würde jeder Wegpunkt schlussendlich einen True/False Wert haben. Diese werden dann genutzt, um das korrekte Signalbild anzuzeigen.

    Meine Hoffnung, war es wenn möglichst ohne UI auszukommen. Darum die Beeinflussung der Parameter via Wegpunkte. Könnte mir hier vorstellen einen Filter für Signale einzubauen. Also dass man z.B. sagen kann „signal=1234,speed=30,occupied=True“


    Denke ich werde zunächst auch so fortfahren. Falls für eine Praktische Verwendung dann noch ein UI gebraucht wird, kann ich das auch noch hinzufügen.

    Ich versuchs sonst mal mit einer Lösung:


    Ich basiere das Ganze auf der Anzeige, die ich für das SBB FV-Dosto (RABDe 502) Repaint gemacht habe. Falls jemand eine bessere Lösung kennt, bin ich auch froh zu lernen :)
    Da habe ich folgendes Resultat erzielt:

    transportfever.net/wsc/attachment/229775/


    Wichtig hierbei ist für End- und Zielbahnhof wird die CommonAPI2 benutzt. Die ermöglicht es überhaupt erst Endbahnhöfe zu definieren. Zudem empfiehlt es sich die Mod Verbesserte Linienbezeichnungen (Update 06.05.23) zusätzlich zu installieren.


    Meine Variante sollte aber mit sowie ohne diese beiden Mods funktionieren (aber nicht im vollen Funktionsumfang).

    Der Einfachhalt halber beziehe ich auf die Nummern von dem folgenden Bild:



    Vorbereitung
    Da meine Variante sowohl mit als auch ohne die CommonAPI funktioniert, muss per Script geprüft werden, ob diese installiert ist oder nicht, damit entsprechend das Verhalten angepasst werden kann.

    Hierzu wird im .mdl file ein kurzer CodeBlock eingefügt:


    Wichtig hierbei sind Zeilen 2 bis 5.

    Lua
    function data()
        local labelType = "NEXT_STOP"
        if (commonapi ~= nil and commonapi.supports and commonapi.supports("LINE_DESTINATION")) then
         labelType = "LINE_DESTINATION"
        end
    return {
        boundingInfo = {...},
        collider = {...},
        ...
    }


    Label 7 Linienbezeichnung

    Die Linienbezeichnung erhält den type = "LINE_NAME"



    Label 8 Nächster Halt

    Hier wird der nächste Halt angezeigt. Das mit dem type = "NEXT_STOP". In meinem Fall habe ich noch dontModify = true hinzugefügt, damit die beiden zusätzlichen Mods dieses Label nicht zu einer Zielanzeige ändern.


    Label 9 (Label 10,11) Übernächster Halt
    Dieses Label zeigt den übernächsten Halt an. Hierzu wird wieder der type auf "NEXT_STOP" gesetzt. Um aber den Übernächsten halt anzuzeigen, wird zusätzlich noch der params Wert wie folgt angepasst:


    Lua
    {
        params = {
            offset = 2,
        },
        type = "NEXT_STOP",
        dontModify = true, 
    },


    Um den über-übernächsten Halt anzuzeigen, muss entsprechend das offset erhöht werden.



    Label 12 Zielbahnhof

    Um den Zielbahnhof/Endbahnhof anzeigen, muss type = labelType gesetzt werden.

    zudem kann/sollte dontModify = true wieder hinzugefügt werden.


    Damit für den Fall, dass die CommonAPI nicht installiert ist, nicht einfach der nächste Halt angezeigt wird, habe ich hier noch den params = { offset = 5, }, gesetzt.



    Ich hoffe, ich konnte zumindest ein wenig weiterhelfen. :) Und sonst einfach fragen.

    Warum ist das UI Abhängig?

    Meine aktuelle Lösung orientiert sich am Code den VacuumTube für Advanced Statistics genutzt hat. Da hat er die Kameraposition, welche aus game.interface.getCamera() kommt, genommen.


    Für die kleinen Fenster werde ich dann wohl die Boundingbox nutzen. Das Entity bekomme ich vielleicht über den ViewManager. Mal schauen :) Danke für den Input!