Beiträge von HansVader

Ich bin jetzt verwirrt und habe keine Ahnung was hier vorgeht.

Zitat von MaikC

Wenn die konvertierung funktioniert hätte würde in den msh datein von mtl nichts mehr drin stehen.

Du möchtest sagen, dass nach der Konvertierung die mdl Dateien wie eine übliche mdl Datei aus TPF2 aussehen sollte.

Jedes Element in der mdl sollte also wie folgt strukturiert sein:

{
materials
mesh
name
transf
}

Das war hier NOCH NIE der Fall.

Ich habe kurz einmal ein paar TPF1 und TPF2 Dateien (jeweils von meiner Signalmod) verglichen. Scriptweise gab es bei der Konvertierung hier nur Anpassungen bei den mtl Dateien. mdl und msh sind unverändert geblieben.

Trotzdem scheint es aber bei mir und auch anderen so zu funktionieren.

Wenn in der transfer_log Datei der Eintrag Used Files = {} alle Dateien auflistet, die korrekt kovertiert wurden, dann wurde bei mir und vermutlich allen die eine funktionierende Version haben nur die Signalbrücke korrekt konvertiert.

Bei der transfer_log Datei von CookieChiara wiederum ist der Eintrag Used Files = {} komplett leer.

Dass dies bloss der Versionsunterschied des Konvertors (ich hatte noch 0.16, CookieChiara hat 0.17) ist, glaube ich zwar nicht, kann ich aber auch nicht ausschliesen.

In den mtl konnte ich einen weiteren Unterschied feststellen.

Bei mir habe ich folgenden Eintrag:

map_metal_gloss_ao = {
            fileName = "models/converter/default_mga.dds",
            type = "TWOD",
        },

Bei CookieChiara steht folgender Eintrag:

map_metal_gloss_ao = {
            fileName = ".tga",
            type = "TWOD",
        },

Ich habe dementsprechend auch folgende Datei res\textures\models\converter\default_mga.dds bei mir gefunden.

Ich habe dir eine PM zukommen lassen, ich würde da kurz in die Dateien reinschauen.

Wenn MaikC recht hat, dann werde ich zwar keinen Fehler finden, aber ich hätte die Gewissheit, dass es nicht nur ein simpler Fehler ist.

Gab es denn einen Fehler bei der Konvertierung? Sowas wurde mir zuvor noch nie gemeldet, aber darauf hat MaikC hingewiesen.

Zitat von CookieChiara

Als Beispiel hier die signal_sbb_typ_n_lampen_orange.mtl:

Ich würde einen Fehler auch eher in einer .msh Datei wie beispielsweise signal_sbb_typ_n_lampe_gruen.msh erwarten, weil dort der Eintrag 'materials' bestimmt wird.

Zitat von MaikC

... damit dürfte auch die Konvertierung nicht geklappt haben.

Könnte man dies aus der transfer_log auslesen?

Ausserdem müsste ein solcher Fehler, dann nicht wesentlich häuffiger auftreten, weil an der Länge der Dateipfade hat sich seit der Veröffentlichung für TPF1 nichts geändert?

Grundsätzlich würde ich empfehlen Schritt 4 der Anleitung erneut durchzuführen, respektive zu überprüfen.

Die Fehlermeldung weisst auf eine fehlerhafte Semantik hin. Ich vermute dies kann ein fehlendes Komma, eine fehlende Klammer oder sogar ein Rechtschreibfehler sein.

Bei deiner Fehlermeldung wurde 'materials' nicht gefunden, somit würde ich zunächst den letzten Teil zu Schritt 4 überprüfen.

Zitat von van Dusen

Kann ich mir den Dateipfad irgendwie anzeigen lassen, ich find da nichts? Oder muss ich jede einzelne Mod im Dateiordner wirklich suchen?

...

Hoffe, ich übersehe was...

Wenn du im Spiel dort bist, wo du die Mods aktivierst und deaktivierst, dann kannst du die Maus auf den Modnamen schieben und da sollte ein Tooltyp auftauchen. Hinten in der Klammer steht der Name des Modordners.

Damit sollte die Mod im Modverzeichnis dann einach auffindbar sein.

Korrektur:

Der Eintrag funktioniert, aber nur bei Bahnhöfen welche diese Funktion integriert haben. Zuvor hatte ich die Module nicht bei einem fremden Bahnhof getestet. Damit der Bahnhof selber auch funktioniert, muss diesem die Funktion in der con-Datei hinzugefügt werden.

Ich glaube hier gibt es aufgrund der Spielmechanik keine Lösung.

Das Signalsystem basiert auf Pfadsignalen. Das bedeutet, der Zug reserviert sich immer den Pfad bis zum nächsten Signal (oder Halt). Das nächste Signal wiederum wird nur dann auf grün geschaltet, wenn sowohl der nächste Pfad frei ist, als auch der Zug so nahe und so schnell ist, dass der Bremsweg über das Signal hinaus geht.

Die realistische Distanz vom Signal das Warnung zeigt, bis zum Signal das halt zeigt, ist logischerweise immer grösser (zumindest ein paar Meter) als der benötigte Bremsweg. Somit wird bei einem normalen Signal der Bremsweg nie darüber hinaus gehen und dementsprechend wäre jedes Signalbild das im Spiel nicht Warnung anzeigt falsch (insofern sie in einem realistischen Abstand stehen).

Damit die Signale bei grösserer Distanz auf freie Fahrt schalten können, ist es notwendig, dass der Bremsweg eines Zuges grösser ist als die Distanz zum übernächsten Signal.

Alternativ müsste man mit Wegpunkten arbeiten, denn solange diese im Pfad zum nächsten Signal (oder Halt) liegen, zeigen diese grün.

Wenn die Herangehensweise über eine niedrige Bremsbeschleunigung nicht ausreicht, müsste man vermutlich die ganze Signalmechanik umschreiben oder neumachen. Anders gesagt, man bräuchte ein Signalsystem mit Blocksignalen.

Es macht aber generell kaum Sinn mehr Weg zu reservieren als gebraucht wird. Damit limitiert man nur die sonst schon knappen Kapazitäten auf den Gleisen.

Zitat von oberhausener68

Für Bahnhöfe: res_construction und dort Dateien suchen, die was mit Plattformen zu tun haben. Entweder gibt es dort "metadata", dann Beitrag #7 die grüne Zeile eintragen. Wenn kein "metadata", dann Beitrag #17 die grüne Zeile eintragen.

Bei den "metadata" sehen Passagiere so aus: moreCapacity = { passenger = 10 }. Ohne "metadata": local passengerCapacity = 20

Prinzipiel ist das auch für Bahnhofsgebäude möglich.

Was braucht es noch?

Ich habe bei den ÖBB Bahnhöfen von Doschi (ex DomTrain) in den Dateien domtrain_oebb-bahnhoefe_1\res\construction\station\rail\modular_station\oebb_bhf1850_hauptgeb.module und domtrain_oebb-bahnhoefe_1\res\construction\station\rail\modular_station\oebb_bhf1850_nebengeb.module jeweils den metadata Eintrag ergänzt, aber das Bahnhofsgebäude liefert denoch keine zusätzliche Kapazität. (Sowohl gebaute wie neu gebaute Gebäude)

Zitat von nightfury34

Ich habe zwar nicht viele Bilder zu dieser Tafel finden können, auf den wenigen die ich gesehen habe, war sie jedoch unterhalb des Signals angebracht. Kann ich aber auch noch ändern falls gewünscht.

Dann wird es wahrscheinlich so sein, dass sie tatsächlich unterhalb angebracht ist. (Du hast mit deinen Bildern mehr Informationen gefunden als ich. Korrektur: Ich habe ein Bild gefunden, mit der Tafel unterhalb des Signals) Auf den ersten Blick erschien mir dies komisch und deshalb habe ich die Vermutung angebracht. Aber ich kann mir durchaus Gründe ausdenken, warum unterhalb mehr Sinn machen würde.

Edit_2: Ich habe auch kurz ins Gesetz geschaut und dort habe ich nichts zur Position der Tafel gefunden.

Zitat von nightfury34

Es sind auch noch Rangierstop-Schilder dazu gekommen.

Ich würde vermuten, dass diese Tafeln wie alle anderen Tafeln oberhalb des Signals platziert werden.

Eigentlich wollte ich damit auf eine spätere Version warten, aber ich habe mal ein wenig experimentiert. Ich habe mir ein extremes Typ L Kombisignal, welches in diesem Ausmass vermutlich in der Realität nicht existiert, zusammengebastelt. Nachfolgend sind ein paar Bilder dazu.

Die hinteren Signale kann man vielleicht nicht so gut erkennen, aber mit der aktuellen Testversion kann man ein kombiniertes System, dass nicht zwischen Haupt- und Vorsignal unterscheidet (was genau dem Typ N System entspricht), relativ einfach umsetzen, insofern man bereits eine fertige Signalmod als Ausgangslage hat.

Eine Umsetzung für das "normale" Typ L System mit Haupt- und Vorsignalen habe ich noch nicht getestet. Ich wollte aber mal Eindrücke liefern, dass das Script genauso gut mit einem anderen Signalsystem als das Typ N funktioniert.

Eine kleine Unschönheit die ich gerade kürzlich gefunden haben ist, dass bei den rechtsseitigen Signale nicht nur das Signal sondern auch das Icon auf der Karte verschoben wird.

Es ist nichts gravierendes, aber in grösseren Gleisvorfeldern könnte es für Verwirrung sorgen. Blau sind linksseitige Signale mit ihren Icons korrekt in der Mitte der Gleise. Rot sind rechtsseitige Signale bei denen das Icon eine ganze Gleisbreite weiter aussen steht. Gelb ist der Problemfall, bei dem das Icon genau auf der gegenüberleigenden Seite liegt. Die Icons wäre am richtigen Ort (Gleismitte), sie sind aber nicht auf dem korrekten Gleis.

Ich wollte dies einfach einmal erwähnt haben, damit dies anderen auch auffällt, respektive dass sie daran denken, wenn sie rechtsseitige Signale bauen. Ein Update deswegen ist vermutlich zu aufwändig.

Was gemäss deinem Bild definitiv noch fehlt ist das Wiederholungssignal.

Für meine Mod zu Mod hatte ich auch noch eine Tafel für Rangierhalt erhalten, ob es die aber im Spiel braucht weiss ich nicht.

Für die Ziffernanzeige gäbe es auch noch ein paar zusätzliche Signalbilder, falls diese noch nicht dabei sind.

Zum einen gibt es ein V für Vorwarnung. Zum anderen gibt es einen Strich für kurze Fahrt (blinkend) oder besetztes Gleis (konstant leuchtend).

Ob es die Blinkanimation im Spiel unbedingt braucht weiss ich nicht.

Bezüglich der Namen, stellt sich die Frage wieviele, respektive welche Funktionen damit einhergehen sollen. Hierzu lässt sich bis zur ersten Version kaum etwas sagen.

Wenn der Bahnsteig ein bischen kürzer ist als der Zug, dann fährt der Zug bis an ans Ende des Bahnsteigs. Mit Assets kann man den Bahnsteig nach hinten verlängern sodass auch der Rest des Zuges zumindest visuell am Bahnsteig hält.

Zitat von nightfury34

Gibt es festgelegte Regeln, wann beim Typ N System Geschwindigkeitsankündigungen verwendet werden, oder geschieht das nach Bedarf?

Ich bin nicht vom Fach, also wer es besser weiss darf mich hier gerne korrigieren.

Ich würde sagen, dass grundsätzlich jede Abweichung von der Streckengeschwindigkeit, welche das obere Maximum bildet, signalisiert werden muss.

Jede Ausführung einer tieferen Geschwindigkeit impliziert, dass der Lokführer vorgängig informiert werden muss, sodass er rechtszeitig abbremsen kann. Ergo sollte es für Geschwindigkeitsreduktionen immer vorher eine Ankündigung geben.

Zugleich braucht aber nicht jede Abweichung von der Streckengeschwindigkeit ein Lichtsignal. Beispielsweise ein Kurve die nicht mit voller Streckengeschwindigkeit befahren werden darf, wird wohl mit 3 Tafeln signalisiert werden (Ankündigung der Reduktion > Ausführung der Reduktion > Aufhebung der Reduktion = Ausführen der Streckengeschwindigkeit). Genauso erfolgt, im Bild meines letzten Beitrages, die Ausführung der Streckengeschwindigkeit nach dem Bahnhof durch eine Tafel.

Das Signalbild halt braucht nicht besonders zu erwähnt zu werden, weil dies im Grunde eine Ausführung der Geschwindigkeit 0 km/h entspricht, und somit entsprechend angekündigt werden muss.

Bei einer dynamischen Ausgestaltung bräuchtest du wohl eine Unterscheidung, ob vorher eine höhere oder tiefere Geschwindigkeit ausgeführt wurde. Wenn sie tiefer war, reicht eine Ausführung der neuen höheren Geschwindigkeit. Wenn sie höher war, dann muss vorher diese tiefere Geschwindigkeit angekündigt werden.

Oder andersrum wenn am dem nächsten Signal eine tiefere Geschwindigkeit gilt, dann muss das aktuelle Signal diese tiefere Geschwindigkeit ankündigen. Sonst kann die aktuelle Geschwindigkeit ausgeführt werden.

Möglicherweise bräuchtest du da irgendwo eine Definition was die Streckengeschwindigkeit ist, sodass ein Signal zwischen freier Fahrt und Ausführung einer tieferen Geschwindigkeit unterscheiden kann.

Zitat von nightfury34

Diese unterscheiden sich aber wohl in der Funktion, da sie diese - verbessert mich gerne - das folgende Signal widerspiegelt, ...

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.

Ich kenne mich mit internationalen Sysgnalsystemen nicht aus, aber das Typ N Signale ist ein besonderes Signalsystem. Im Grunde gibt es keine Unterscheidung zwischen Vorsignal und Hauptsignal. Das "Vorsignal" unterscheidet sich lediglich darin, dass es nicht halt anzeigen kann.

Vereinfacht könnte man sagen, dass orange mit der Geschwindigkeitsankündigung eine Vorsignalfunktion ist und grün mit der Geschwindigkeitsausführung eine Hauptsignalfunktion ist. "Vorsignale" und "Hauptsignale" können beim Typ N System beide Funktionen wahrnehmen.

Siehe nachfolgendes Beispiel:

(Bildquelle: https://de.wikipedia.org/wiki/…ten_Geschwindigkeiten.png Am Bild besteht kein Urherberrecht nach Art. 5 URG.)

Die angekündigten 90 km/h gelten zwar am "ersten Hauptsignal", aber dieses wiederum kündigt bereits die Geschwindigkeit für das nächste Signal an. Hier spiegelt das "erste Hauptsignal" das nächste Signal wider, wobei das "Vorsignal" gerade nicht das folgende Signal widerspiegelt.

Im Vergleich dazu hat beispielsweise das Typ L System zwei Signalschirme, einen länglichen Signalschirm oben für das Hauptsignal, und einen quadratischen Signalschirm unten für das Vorsignal. Das gleiche Szenario würde beim "ersten Hauptsignal" somit zu einem gemischten Signal führen, bei dem man aber klar zwischen Vorsignal- und Hauptsignalfunktion unterscheiden kann.

f1rnen hat deine Frage bereits beantwortet. Für das bessere Verständnis möchte ich aber noch folgendes anfügen.

Wenn keine Fahrsterasse gestellt ist oder wenn im folgenden Abschnitt ein Zug vorhanden ist, dann zeigt das Signal halt. Das vorherige Signal muss dann wiederum diesen Halt ankündigen, insofern es nicht selber halt anzeigt. Weil das "Vorsignal" kein halt anzeigen kann, wird stattdessen der folgende halt angekündigt.

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.

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.

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.

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.