Dynamische Zusatzanzeiger am Signal?

Wuhu Ein erster Durchbruch. Ich hoffe die kleine 5 ist deutlich genug zu erkennen im Video. Prinzipiell ist alles, was Geschwindigkeitsanzeiger anbelangt, noch Einstellungssache. Werde wohl den aktuellen Stand noch ein bisschen testen und mir dann mal den Vorschlag von HansVader anschauen. Wäre cool, wenn man damit dann auch Richtungsanzeiger/Weiser oder Rangierfahrten usw. usw. darstellen kann. Auch Vorsignale würde ich mir bei Gelegenheit zur Brust nehmen.

Ich werde wohl einige Zeit in das Optimieren vom Code stecken müssen. Das Evaluieren der Fahrstrassen für alle Züge - wobei ich diese schon filtere - zieht recht schnell an der Performance.

Zur Referenz: Mein letzter Test war auf einer winzigen Karte mit 17 Zügen auf 28 Signale und die Züge bewegen sich alle Sekunde mal ein kleines Stück.

Mache mir trotzdem Hoffnung da noch einiges herauszuholen

Es gibt wieder mehr zu zeigen! Da Signale oft nahe beieinander stehen, kann ich nicht immer meine neuen "Fake" Signale mit dem geografisch am nächsten gelegenen "Richtigen" Signal verbinden. Deshalb habe ich mir ein kleines Selektionstool gebastelt, mit welchem man nun ein Signal auswählen kann. Mit den Tasten ü + ¨ bzw ü und + (auf einer deutschen Tastatur) kann man das nächste Signal selektieren.

Freue mich über ein Feedback, was ihr von dem System haltet

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.

Hi zusammen,

kurze Frage wäre es auch so möglich einerseits die Hochsignalisierung bei Ks Signale funktioniert und andersseits ob bei Mehrabschnittsignale dann das Signal zwischen Halt, Fahrt, Halt erwarten switchen kann.

MfG DomenicLP

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.

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.

Die Anzeige unten beim Schweizer N Signalsystem kann folgendes anzeigen:

- Geschwindigkeiten (Zahl) -> Speed

- Vorwarnung wenn die Blöcke kurz sind und das übernächste Signal rot zeigt: V

- Besetztes Gleis: Strich

- Kurze Fahrt: Ist denke ich nicht so wichtig

Welche Parameter hier passend wären, ist mir nicht klar. Denke nicht, dass dies abhängig von der Infrastruktur im Game gemacht werden kann, sondern einfach nach Lust eingestellt wird.

Beim L-System ist es ähnlich.

- Die verschiedenen Signalbegriffe für die Geschwindigkeit -> Speed

- Kurze Fahrt = Abstand zum nächste Signal oder Sperrsignal sehr kurz

- Besetzes Gleis = Ein Zug steht schon da

-> Freie Wahl?

Fazit: Es bräuchte einen Parameter für Sonderfunktionen, die nicht von der Infrastruktur ableitbar sind.

Btw: Tolle Fortschritte!

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.

Zitat von nightfury34

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.

Hmm, du müsstest ein BoundingBox Punkt eines Zuges bzw. des ersten Fahrzeugs zu rate ziehen können ob ein Zug in der Nähe des Signals ist? Warum ist das UI Abhängig?

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!

Welche Parameter gebraucht werden hängt ganz vom Komplexitätsgrad ab. Ich weiss natürlich nicht ob gewisse Parameter, oder mehrere statt einen, sich stärker auf die Performance auswirken oder nicht.

Zumindestes für die Umsetzung welche ich im Kopf habe, würden mehrere True/False Werte ausreichen. Nachfolgendes Beispiel ist für die Typ L Signale. Dies sollte aber analog für Typ N und vermutlich die meisten anderen Signalsysteme anwendbar sein.

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.

Die Abfrage basiert darauf, ob ein Wegpunkt im Pfad ist oder nicht. Aufgrund dieser Unterscheidung im Pfad, könnte man das Signalbild unterscheiden. Da die Pfade vermutlich bloss eine begrenzte Distanz voraus berechnet werden, können damit Vorsignale wohl nur in Relation zum nächsten Signal aufgebaut werden (insofern sie nahe genug beieinander stehen).

Dort wo ein Signal ist (rote Punkte: WP1 im ersten Beispiel, WP1 und WP2 im zweiten Beispiel), wäre genauso eine direkte Referenz auf das Signal möglich.

Selbstverständlich könnten Zusatzanzeigen wie kurze fahrt, besetztes Gleis, genauso integriert werden. Die Limitierung hierfür liegt vermutlich darin, dass ein definierter Pfad immer diese Zusatzanzeige haben würde. Eine Abfrage ob im folgenden Bahnsteigbereich ein Zug das Gleis besetzt, sollte nicht möglich sein, weil gerade keine Abfrage für eine Fahrt in diesen Block stattfindet.

Ich bin der Meinung, dass man es so einfach wie möglich halten sollte, gerade weil die gesamte Verarbeitung periodisch durchgeführt werden muss und so die Performance belastet.

Genau so Stelle ich mir das auf vor, wenn auch mit Deutschen Signalen

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.

Achso jetzt verstehe ich, was du da genau meintest. Du möchtest den nächsten Wegpunkt im Pfad erkennen und dessen Namen auslesen. Dieser Name wiederum soll als Parameter im Script dienen, um zu bestimmen welches Signalbild dargestellt werden soll.

Einen Parameter zur Aktivierung könnte sinnvoll sein, sodass nicht der beliebig nächste Wegpunkt, sondern der nächste ausgewählte (=aktivierter) Wegpunkt dafür genutzt wird.

Sofern es nicht zu anderweitigen Kollisionen mit dem Spiel oder Mods führt, könnte es vielleicht besser sein statt alle Parameter vorzugeben, den Modersteller die Möglichkeit für eigene Parameter zu geben. Dann könnten die Unterschiede der verschiedenen Signalsysteme durch die entsprechende Moder mitberücksichtigt werden, ohne dass du zugleich eine umfassende Parameter Auswahl bereitstellen müsstest.

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.

Wegpunkte sind eine interessante Idee, um zusätzliche Informationen ohne GUI einzuspeisen. Z.B. Buchstaben für Richtungsanzeiger.

Ich würde aber versuchen, ohne auszukommen wo möglich, um die Komplexität klein zu halten. Wenn du die Geschwindigkeit eh ausliest (für automatische Geschwindigkeitsanzeiger), kann man daraus auch ablesen ob es sich um ein Abzweig mit gelben Licht handelt. Ich würde voraussetzen, dass Realitätsfeteschisten eh ein entsprechendes Gleis mit der richtigen Geschwindigkeit (in DE glaube 60km/h für HP2?) haben - daran könnte man das Signalbild bestimmen.

Die Auswahl im Menü sollte dann idealerweise einfach nur die baulich (konstante) Zusammenstellung darstellen, also zB Ausfahrsignal + dynamschem Geschwindigkeits(vor)anzeiger, oder Vorsignal+Richtungsanzeiger. Alles was dynamisch ist, sollte idealerweise nicht vorgegeben werden müssen, sonder automatisch besimmt werden, via Auslesen von Gleisgeschwindigkeit und reservierter Abschnitt. Theoretisch sollte man anhand der Geometrien auch rausfinden können was der "rechte"/"linke" Abschnitt ist (zB für Gegengleisanzeiger).

Wenn ich da noch eine fehlende Funktion beisteuern kann, sag gerne Bescheid.

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.

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

Zitat von nightfury34

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)

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

Zumindest aus meiner Perspektive wäre dies viel mehr ein gewünschtes Feature.

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