Beiträge von nightfury34

Danke für das Feedback! Werde ich gleich fixen!

Heute habe ich für euch Vorsignale:

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.

Zitat von Computerhocker

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.

Zitat von HansVader

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

Da oben steht Endstation und daneben ist eine Checkbox (rund) die man anklicken kann

Nene.

Auf dem Bild hattest dus schon:

https://www.transportfever.net…asted-from-clipboard-png/

Zitat von HAVELLAENDER

ist bei mir in der Linienführung unter more settings...

Genau, die Checkbox bei Endhaltestelle müsste noch angewählt werden und dann kannst du, falls du das möchtest, der Haltestelle noch einen eigenen Namen geben

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:

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:

    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

Zitat von VacuumTube

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.

Zitat von VacuumTube

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

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.

Zitat von HansVader

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.

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"

{
    alignment = "LEFT",
    alpha = 1,
    alphaMode = "CUTOUT",
    childId = "front_body",
    color = { 1, 0.70624995231628, 0, },
    filter = "NONE",
    fitting = "NONE",
    nLines = 1,
    params = { },
    renderMode = "EMISSIVE",
    size = { 55, 4, },
    transf = { 0.0099999997764826, -3.8941436741879e-09, 8.7422774575074e-10, 0, -3.8941436741879e-09, -0.0099999997764826, -8.7422769023959e-10, 0, 8.7422807881765e-10, 8.7422730166153e-10, -0.0099999997764826, 0, -9.039999961853, -2.1800000667572, -1.3799999952316, 1, },
    type = "LINE_NAME", -- <== HIER IST DER WICHTIGE TEIL
    verticalAlignment = "BOTTOM",
},

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.

{
   alignment = "LEFT",
   alpha = 1,
   alphaMode = "CUTOUT",
   childId = "front_body",
   color = { 1, 0.70624995231628, 0, },
   filter = "NONE",
   fitting = "NONE",
   nLines = 1,
   params = { },
   renderMode = "EMISSIVE",
   size = { 55, 4, },
   transf = { 0.0099999997764826, -3.8941427860095e-09, 8.7422769023959e-10, 0, -3.8941423419203e-09, -0.0099999997764826, -6.2783294119129e-09, 0, 8.742300772191e-10, 6.2783289678237e-09, -0.0099999997764826, 0, -9.039999961853, -2.1099998950958, -1.3799999952316, 1, },
   type = "NEXT_STOP",
   verticalAlignment = "BOTTOM",
   dontModify = true -- <== Wichtig, damit die Linienbeschreibung diesen Eintrag nicht modifiziert.
},

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:

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

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

{
    alignment = "LEFT",
    alpha = 1,
    alphaMode = "CUTOUT",
    childId = "front_body",
    color = { 1, 0.70624995231628, 0, },
    filter = "NONE",
    fitting = "NONE",
    nLines = 1,
    params = {
        offset = 2,
    },
    renderMode = "EMISSIVE",
    size = { 19, 3, },
    transf = { 0.0099999997764826, -3.8941423419203e-09, 8.7422769023959e-10, 0, -3.8941414537419e-09, -0.0099999997764826, -8.6625151496378e-09, 0, 8.7423102090867e-10, 8.6625142614594e-09, -0.0099999997764826, 0, -9.039999961853, -2.0799999237061, -1.3799999952316, 1, },
    type = "NEXT_STOP",
    verticalAlignment = "BOTTOM",
    dontModify = true
},

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.

{
    alignment = "LEFT",
    alpha = 1,
    alphaMode = "CUTOUT",
    childId = "front_body",
    color = { 1, 0.70624995231628, 0, },
    filter = "NONE",
    fitting = "NONE",
    nLines = 1,
    params = {
        offset = 5,
    },
    renderMode = "EMISSIVE",
    size = { 55, 4, },
    transf = { 0.0099999997764826, -3.8941432300987e-09, 8.7422769023959e-10, 0, -3.8941432300987e-09, -0.0099999997764826, -3.8941436741879e-09, 0, 8.7422918904068e-10, 3.8941432300987e-09, -0.0099999997764826, 0, -9.039999961853, -2.0199999809265, -1.3799999952316, 1, },
    type = labelType,
    verticalAlignment = "BOTTOM",
    dontModify = true
},

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

Gefällt mir richtig gut Sehr gelungenes Modell! Auf den ersten Blick ist mir nur dieser Lila streifen aufgefallen.

Freu mich auch schon auf die kommenden Modelle!

Zitat von eis_os

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!

Vielen Dank für die Erklärung! Ich werde entsprechende Parameter noch nachführen. Ich denke es läuft wohl im Endeffekt auf eine grössere Sammlung von Parametern heraus, die ich dann halt entsprechend Dokumentieren muss.

Nun können Waypoints die Signale beeinflussen. Habe für den Start mal 3 Values hinzugefügt. Bin hier aber auch auf euch angewiesen was es da genau braucht.

Kurz zur Erklärung:

Die Values sind schlussendlich die Parameter, welche die Konditionen für die Signalbilder stellen.

In meinem Beispiel: (Versuche es am deutschen Beispiel zu beschreiben, da ich mir bei den Schweizer Namen nicht so sicher bin)

Speed: Die erlaubte Geschwindigkeit auf dem Abschnitt (Zs3)

Dest(ination): Als Richtungsanzeiger (Zs2)

Direction= Gegengleisanzeiger (Zs6)

Wie gesagt bin ich hier auf eure Inputs angewiesen, was an Parametern noch benötigt wird.

Zitat von DomenicLP

Hi zusammen,

kurze Frage wäre es auch so möglich einerseits die Hochsignalisierung bei Ks Signale funktioniert

In Theorie ja. Praktisch muss ich aktuell leider die Vanilla-Distanzen für das Grünschalten der Signale verwenden. Was in der Regel leider bedeutet, dass ein Signal erst relativ spät auf Grün stellt, weshalb die Hochsignalisierung in den wenigsten Fällen wirklich zu sehen wäre. Denke, dass die benötigte Funktionalität aber vorhanden sein sollte in der fertigen Mod, um sowas zu realisieren.

Zusätzlich habe ich mich mit der Performance auseinandergesetzt. So werden aktuell nur noch Züge, welche sich in einem gewissen Radius vom Spieler befinden, ausgewertet. Das hat der Performance schon spürbar geholfen. Jedoch funktioniert das aktuell auch nur in der Hauptansicht. Heisst Züge, welche man sich durch extra Fenster einblenden lässt und sich ausserhalb des Radius befinden, werden aktuell nicht von der Signalauswertung erfasst. Werde schauen, dass ich dafür aber auch noch eine Lösung finde.