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
Hast du Realistic Train Brake aktiv?
Auf meiner Testkarte nicht, aber auf meinem Nachbau von Zürich, auf welcher ich die Mod auch bereits getestet habe, was meiner Meinung nach einen positiven Effekt hatte. Dadurch konnte ich im Bahnhofsbereich, wo eher langsame Geschwindigkeiten gefahren werden, Signale verbauen und musste nicht mit Wegpunkten auffüllen.
Die "Hochsignalisierung" bei der Arbeit 
Jetzt auch mit deaktivierbaren Geschwindigkeitsanzeiger
Gibt es festgelegte Regeln, wann beim Typ N System Geschwindigkeitsankündigungen verwendet werden, oder geschieht das nach Bedarf? HansVader
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.
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.
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
Da oben steht Endstation und daneben ist eine Checkbox (rund) die man anklicken kann
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"
endAnsonsten 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 
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:
dev.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"
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:
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.
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!
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!
