Dynamische Zusatzanzeiger am Signal?

Interessante Idee.

Ich denke, die Art wie Signale aktuell implementiert sind, ist das größte Problem, dem Signal mehr Schaltbilder als an/aus beizubringen. Da gibt es auch keine einfache API funktion das anzusprechen.

ABER die Line Events der CommonAPI könnten hier eine Lösung sein. Man müsste sich das ganze etwas zu recht skripten, aber es wäre denkbar, 2 (oder mehr) Signalmodelle hinzustellen und jeweils un/sichtbar zu machen... ach mist das geht nur mit Konstruktionen. Also müsste man ein Fake signal als Asset neben das Gleis stellen...

Geht also Richtung Möglichkeit 2

joa zusammenbasteln kann man sich das jetzt schon für den Einzelfall. Muss sich halt etwas mit den Line Events auseinandersetzen. Damit ist aber einiges möglich, zB Rangieren. Ist halt nicht benutzerfreundlich für den einfachen User.

Man müsste eine Konstruktion erstellen für die Signale die man braucht und einen Parameter mit dem man das un/sichtbar machen kann. Diesen steuert man dann mit dem Line Script Event.

Das ganze in eine einfach nutzbare Gui unterzubringen wäre natürlich eine Mammutaufgabe.

Weitere Ideen wären: variable Geschwindigkeitsanzeiger, variables Hp1/2

Interessante Idee. Ich sehe da aber ein Problem beim Kosten Nutzen Verhältnis. Du könntest natürlich auch ein EdgeObject via SimplePropsal umbauen via event, das würde aber ein Umbau der Gleisanlage bedeuten. Dazu würde ich ganz klar abraten... (Das triggert eine Neuberechnung aller Linien, es darf sich da gerade kein Fahrzeug befinden usw.)

Was ich mir schon mal überlegt habe, das man in Assets den Zustand eines Signals bzw. eines Bahnübergangs bekommt und dadurch Animationen auslösen könnte. Sprich man bindet eine Asset an eine Animationsquelle. Ich fand den interne Aufwand aber noch nicht gerechtfertigt.

Auf meiner Karte wollte ich an einem Fussweg noch ne Schranke "stellen", aber die Sims würden ja trotzdem durchlaufen. Das hab ich dann nicht weiter verfolgt. Das würde erst wieder interessant wenn ich irgendwie ein Waypoint mit Ampelfunktion auf einer Straße kreieren könnte, die ich dann selber via Script steuern kann. Das ist aber nur ne grobe Idee,

Aber auch die Tramgleise in der Mitte einer Straße und der NodeEditor waren grobe Ideen.

Das Problem ist dann eher eine Zeitliche. Wenn ich für ne grobe Idee zum fertigen Feature im besten Fall ein Jahr brauche, ist TPF2 schon abgekündigt.

Für so etwas bräuchte halt ne bessere Lösungen, als mit den Binärcode zu puzzeln...

Ich habe nochmal über das Thema nachgedacht und ich halte die Idee Dynamische Signale schon für machbar... allerdings anders als ich zuerst vorgeschlagen habe. Entsprechend deinem Ansatz (1) könnte man den Fahrtweg von Zügen abfragen und prüfen in welchen Abzweig dieser hinter einem Signal wäre. Intern lässt sich das in TPF2 via MOVE_PATH abfragen. Dieser Ansatz hätte den Vorteil, dass man keine manuelle Zuordnung machen muss und daher ohne GUI auskommt!

Man bräuchte extra Konstruktionen, die man neben das Gleis platziert, während auf dem Gleis selbst ein unsichtbares Signal ist. So vermeidet man Eingriffe in das Gleisnetz und die Definition als Konstruktion ermöglicht Parameter (an/aus, Hp2, dynamische Geschwindigkeit, Geschwindigkeitsvoranzeiger, Gegengleis...). Also praktisch eine Fake Signalkonstruktion, die man nicht funktional aufs Gleis setzen kann, aber mit einem Script verbunden ist. Die müsste man entweder aus den bisherigen Signalmods speisen oder sauber neu programmieren mit allen Kombinationen und Teilmodellen.

Hier ein grobes Code Konzept.

1. Wenn ein neues Dynamisches Signal platziert wird, wird es in eine Liste aufgenommen zur Zuordnung.

2. Es braucht eine Funktion (udpateRailNetworkInfo) um regelmäßig die Gleisinfrastruktur durchzugehen und dabei die Abzweige hinter den Signalen analysiert. Mit den api Funktionen sollte das möglich sein, den Nodes und Edges zu folgen. Dabei wird die tatsächliche Höchstgeschwindigkeit ermittelt, sodass automatisch die richtige Nummer am Signal gezeigt wird!

3. Kontinuierlich muss dann geprüft werden ob ein Signal angeschaltet werden muss, weil ein Zug sich einen Pfad reserviert (checkSignalStates). Dazu muss der Move Path von allen Zügen analysiert werden, da sich nur hier die Informationen finden. Dann weiß man wo der Zug hinwill und kann das richtige Signalbild bestimmen. Die Konstruktion kann entsprechend geupgradet werden.

function udpateRailNetworkInfo()
     
     -- for all dynamic signals:
    
    -- echtes signal am Gleis finden
    signals = game.interface.getEntities({radius=5,pos={x,y}}, { type = "SIGNAL" })
    assert (#signals==1)

    signal_edge = api.engine.system.streetSystem.getEdgeForEdgeObject(signals[1])
    n2e = api.engine.system.streetSystem.getNode2TrackEdgeMap() -- Gleis Graph

    -- folge in Signalrichtung über alle Weichen/Abzweigungen bis zum nächsten Signal
    -- ermittle dabei jeweilige Richtungen und Maximalgeschwindigkeiten
end

function checkSignalStates()
    trains = {}
    api.engine.system.trainMoveSystem.forEach(function (a) table.insert(trains, a) end)
    -- for all trains
    
    move_path.path.edges[move_path.dyn.pathPos.edgeIndex]
    ... bis 
    move_path.path.edges[move_path.dyn.pathPos.edgeIndex+move_path.path.endOffset]  -- geht manchmal immer noch übers Signal hinaus
    
    -- checken ob einer der pfade über eines der Signale läuft und in welchen Abzweig (und ob das Signal an ist)

Analog diesem Ansatz wäre es auch einfach möglich, von Vorsignalen (auch als extra Fake-Konstruktion) den Pfad zum nächsten Hauptsignal zu ermitteln und dann abzuändern, wenn das Signal umschaltet. Hier sollten sich aber keine Abzweige bis zum Hauptsignal befinden.

Soweit das Konzept. Ich lasse das einfach mal hier liegen. Ich werde da nämlich in absehbarer Zeit nicht selbst daran arbeiten können. Wenn sich jemand der Sache annehmen will, werde ich aber gerne unterstützen!

Sowieso wäre es hier notwendig, dass ein Signal Modder von der Modwerkstatt entgegenkommt.

Das klingt ja sehr interessant!

Dies wäre auch immer schon ein grosser Wunsch von mir gewesen. Wenn es meine Zeit mal zulässt, schau ich das genauer an, und versuche es mal mit Schweizer L Signalen umzusetzen.

Zitat von VacuumTube

Intern lässt sich das in TPF2 via MOVE_PATH abfragen.

Mir wird leider aus deinem Code-Snippet nicht ganz klar, woher MOVE_PATH kommt, oder wie ich MOVE_PATH accessen kann.

Leider haben meine Google suchen danach auch nur zurück zu diesem Thread geführt.

Könntest du das evtl. etwas näher erleutern?

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.

Mal eine Ganz doofe idee;
Wenn man den Spaß als Asset baut,

Ließe sich dann nicht ienfach Über die selbe abfrage wie auch der dynamische abfahrtsanzeiger abfragen, welche linie das ist und dann vorher festlegen getreu dem motto "Wenn Linie S21 vorbeikommt, mach zs3 Kz3" oder so?

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.

Hm. Die Frage ist halt, wie rundet man die Geschwindigkeiten im Weichenbereich - ich hab oft 49 Km/h oder so n Spaßy rundet man dann auf oder ab?

Und du kannst ja auch leider nicht auslesen ob der Zug in ein Stumpfgleis einfährt oder nicht (denk ich Mal)

Bin mittlerweile an einem Punkt, an welchem ich den Path evaluieren und den State der Signale abfragen kann. (In der Konsole ist der Signalname und der State 0/1 zu sehen.)

Für den Fall, dass sich zurzeit auch jemand mit dem Thema auseinandersetzt und sich austauschen möchte.

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.

Zitat von VacuumTube

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.

Yup ist geplant. Schau mir da bisschen was von der Zäune Mod zum Registrieren vom Bauen und der Timetable zum Abspeichern von States ab.

Die Optimierung vom Script werde ich mir wohl erst anschauen, sobald ich was Funktionierendes habe.

Vielen Dank für das Angebot

Ich bin gerade auf der Suche nach einem sinnvollen Event/einem sinnvollen Ort, um mein Script aufzurufen. - Also die "checkSignalState" Funktion, welche ja immer und immer wieder aufgerufen werden soll, aber gleichzeitig nicht zu sehr an der Performance nagen soll, da doch mindestens der Loop über alle Fahrzeuge und der Loop über den Path jedes Fahrzeugs nötig ist. Fällt euch da etwas ein?

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.

Das erste Signal schaltet auf Grün

...Nur leider nicht mehr zurück auf Rot. Aber ich denke, das ist ein gutes Prove-of-concept.

Werde mir noch überlegen, wie ich die Signale wieder rot schalte und anschliessend den Code etwas aufräumen und mich dann um die Geschwindigkeitsanzeiger kümmern.

Ich möchte hier einfach mal meine Gedanken für das Coden der Signale einbringen.

Würde die Pfadabfrage auch Wegpunkte und ihren State erfassen?

Wenn ja, könnte man auf diese konditionieren?

Wenn ja, hätte man alles, was man für ein dynamisches Signalsystem braucht.

Durch eine Kaskade von Bedingungen könnte man unterscheiden welches Signalbild dargestellt werden soll. Einen Umweg über Geschwindigkeiten müsste man nicht machen.

Ich könnte mir eine Signalkonstruktion vorstellen, bei der man zunächst auf den State eines Signals oder Wegpunkts konditioniert. Wenn dieser rot ist, dann zeigt das Signal den Fahrbegriff halt. Sonst würde man anschliessend den möglichen Fahrbegriffen jeweils einem Signal oder Wegpunkt zuordnen.

Also beispielsweise wenn das anliegende Signal rot zeigt, dann zeigt die Konstuktion halt. Sonst wenn der Wegpunkt 1 im Pfad liegt, dann wird der Fahrbegriff 1 dargestellt. Sonst wenn der Wegpunkt 2 im Pfad liegt, dann wird der Fahrbegriff 2 dargestellt.

Damit dies geht (zumindest denke ich das), braucht es nur die direkte Konditionierung. Wenn man wie VacuumTube vorschlägt, die Signale und Wegpunkte in einer Liste aufführt, wäre es vielleicht möglich, wie bei der Gleisauswahl verschiedener Mods, dort das gewünschte Ziel auszuwählen. Das Problem der Unübersichtlichkeit könnte so aber ziemlich gross sein.

Und selbstverständlich müssten diese Bedingungen stetig überprüft werden, sodass plötzliche Änderungen erfasst und umgesetzt werden können.

Ich bin jedenfalls gespannt darauf, was hier entsteht und was man damit alles umsetzen könnte.

Grundsätzlich sehe ich kein Problem damit states von Wegpunkten auszulesen. Die Idee anhand der Wegpunkte Signalbilder zu erzeugen gefällt mir auch sehr gut. Werde ich definitiv prüfen und mit einfliessen lassen.

Ich könnte mir Vorstellen eine Art Mischbetrieb einzubauen. Dass die Signale Grundlegend auch ohne Wegpunkte funktionieren und in dem Fall anhand der „Minimal“ Geschwindigkeit/sonstigen Einflüssen die Signalbilder erzeugen, dass aber sobald ein entsprechender Wegpunkt im Pfad entdeckt wird, dieser diese Standard Funktionen überschreibt/ergänzt.