Beiträge von HansVader

Willkommen in der Transport Fever Community

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


    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.

    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.

    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.

    gem. Anleitung müsste dies ja eben auf "emissive" geändert werden (die Grossschreibung habe ich beachtet).

    Das ist auch richtig.

    elektronikfreak hat auch nur darauf hingewiesen, dass es keinen 'material type' gibt der "TRANSPARENT" bezeichnet wird. "PHYS_TRANSPARENT" oder "PHYSICAL" sind ähnlich lautende Typen die es auch tatsächlich gibt.


    Weil der Fehler auf ein falscher 'material type' hinweist, würde ich dir empfehlen den Pfad Mododner\res\models\material\railroad\signal_sbb_typ_n aufzurufen und dort die drei unter Schritt 4 erstellten Dateien anzuschauen. Das ist die einzige Stelle in der Anleitung bei der ein 'material type' verändert wird.


    Wenn du bei Schritt 4 gemäss Anleitung noch die original Datei hast, könntest du auch versuchen die drei geschaffenen Dateien zu löschen und dann den Schritt mit drei neuen Kopien zu wiederholen.

    Erstmal bedanke ich mich für die Stimmen.


    Für das nächste Thema war meine erste Idee schlicht das Thema Untergrund. Bisher gab es immer nur Bilder von der Oberfläche, aber in Städten oder Bergen ist man auch darauf angewiesen Tunnel zu bauen. Wie es in diesen Tunneln aussieht spielt in den meisten Fällen keine Rolle, weil man nur von Oben auf die Oberfläche schaut. Wer aber häuffiger in der Cockpit Perspektive unterwegs ist, durchquert auch Tunnel welche oftmals kaum Beachtung finden.


    Ich möchte die Chance nutzen, diesem Thema mehr Beachtung zu schenken. Ich weiss, im Vergleich zu TPF1 wurde mit TPF2 der Bau im Untergrund wesentlich mühsamer, was aber nicht bedeutet dass es nicht möglich ist. Das Thema Untergrund ist buchstäblich eine neue Perspektive und kann eine neue Herausforderung darstellen.


    Ich bin mir bewusst, dass dieses Thema abschreckend wirken kann, deshalb möchte ich das Thema auf die U-Bahn erweitern. Entgegen dem Namen kann man eine U-Bahn auch an der Oberfläche antreffen. So gibt es für jene die mit dem Untergrund nichts anfangen können eine Alternativoption.


    Nächstes Thema: Untergrund und U-Bahn

    Schön dass mein Input dir helfen konnte.

    Nach weiterem herumtüfteln habe ich herausgefunden, dass schritt 1 nicht nötigt ist.

    Für die Darstellung der Drehgestelle ist dieser Schritt auch nicht nötig. Wenn aber der Wagen in engere Kurven fährt, sind dann die Drehgestelle noch auf den Gleisen, wenn du diesen Eintrag weglässt? Ich würde vermuten, dass ohne den Eintrag die Drehgestelle fix mit dem Wagen verbunden bleiben und sich nicht drehen.


    Zu deinem Code oben, da hast du zusätzlich logo_body.msh und interior.msh hinzugefügt. Ich denke diese Einträge bräuchte es nicht, zumindest gehören sie nicht zum Drehgestell. Ausserdem sollten die Wagen ein eigenes "interior" Mesh haben.

    Nach der Konvertierung musst du lediglich die .mdl Dateien mit einem Texteditor anpassen. Diese befindet sich im Pfad res\models\model\vehicle\waggon

    Nachdem du die Dateien der Mod und den vanilla Wagen geöffnet hast, kannst du die Daten vergleichen und das was bei der Mod fehlt hinüber kopieren. Dies wären vermutlich die Blöcke mit lod_0_w1.msh. Dazu müsstest du die Drehgestelle dann auch bei railVehicle = {configs = {{axles = ... eintragen, sodass diese auch funktionieren.


    Wichtig ich habe dies selber bei meiner Konvertierung so nicht gemacht, somit kann ich nur vermuten was zu tun ist, ohne Garantie dass es funktioniert.

    Vorschlag: Nutze Wagen die ausschliesslich ein Gütertyp laden können. Damit kannst du sicher stellen, dass ein Wagen immer nur Werkzeuge lädt. In der Konsequenz bedeutet dies aber auch, wenn keine Werkzeuge vorhanden sind, dass der Wagen leer bleibt, statt dass andere Güter geladen werden.


    In TPF2 kann man dies glaube ich nicht mehr einstellen, also müsstest du entweder eine entsprechende Mod finden oder selber erstellen.

    Könntest du mir das noch erklären?

    Was ich meine ist folgendes:

    Um bei einem Bahnhof den Bahnsteig zu trennen, muss in der Mitte ein Gleissegment heraus genommen werden. Diese Lücke kann man dann mit normalen Gleisen wieder schliessen.

    Die gleiche Mechanik kann man für modulare Haltestellen benutzen. Nur in diesem Fall nimmt man ein Bahnsteigelement heraus. Die in der Mitte entstehende Lücke lässt sich mit dem Element "Bahnsteigzugang" schliessen. Damit wird auf beiden Seiten die Rampe zum Abschluss des Bahnsteigs hinzugefügt.


    Die Sache mit den Nodes ist folgende:

    Strassen und Schienen sind nichts anderes als aneinander gereihte Segmente. Dort wo sich zwei Segmente verbinden ist eine Node.

    Pro Segment und Strassenseite kann nur eine Haltestelle gebaut werden. Wo auf dem Segment die Haltestelle plaziert wird, ist egal. Somit kann man diese jeweils ans Ende nahe bei der Node setzen. Also hast du in der Mitte die Node und auf den beiden Segmenten nahe bei der Node die Haltestellen.


    Im obigen Bild sind die farbigen Punkte welche durch weisse Striche verbunden sind Nodes. Also die Gerade blau - grün - grün - blau trennt das rechte und linke Strassensegment voneinander.

    Um die Darstellung zu aktivieren oder deaktivieren gibt es die Tastenkombination altGr+L. Damit dies funktioniert musst du aber zunächst in den erweiterten Einstellkungen den debug-Modus aktivieren.

    Meinst du sowas?

    Das kann man bereits mit der modularen Haltestelle erstellen.


    In jedem Fall, genauso wie bei den Zügen, braucht es in der Mitte ein Modul zur Trennung der Bahnsteige.


    Nachtrag

    Auch folgendes ist möglich, solange die Strassen-Node in der Mitte ist.


    Aber sonst glaube ich, ist es vom Spiel her notwendig, dass die Bahnsteige respektive Wartebereiche von einander getrennt sind.

    Mit ist etwas aufgefallen, nämlich die neue Darstellung von 'Neueste Nachrichten' auf der Startseite.


    Ich finde, dass die Darstellung überproportional gross ist. Diese sind gefühlt mindestens so gross wie 'Neues aus der Bildergalerie' und 'Ungelesene Themen' zusammen.
    Insbesondere wenn man die Seltenheit von solchen Nachrichten betrachtet (Dez21, Mär22, Mai 22, Sep22), dann steht dies in keiner Proportion zu den anderen beiden Elementen.

    Ich habe nichts gegen 'Neueste Nachrichten', aber ich finde die aktuelle Darstellung ist zu dominant im vergleich zum üblichen Alltag von neuen Beiträgen, Bildern und Mods.


    Man sollte auch bedenken eine solche Nachricht liest man einmal, vlt mehrmals wegen den Kommentaren, aber dann ist es einfach ein grosser Block am den man jeweils vorbei scrollen muss, um die wahren täglichen Neuigkeiten zu sehen.


    Das ist meine Meinung.


    Und wenn ich schon hier bin, nutze ich auch gleich die Gelegenheit ein DANKE zu hinterlassen für den Aufwand und Erhalt dieser Seite.

    Danke Stepke für deine Arbeit, und Danke an das Forenteam und allen die mit ihren Spenden die Seite am Leben erhalten.

    Ich habe schon einige UI-Bilder für Gleis- oder Signalmods erstellt. Ich empfehle eine Vorlage mit mehreren Ebenen zu erstellen (bspw. in GIMP). Auf jeder Ebene kommt ein einzelnes Element (Schwellentyp, Masttyp, Mastabstand, Textfeld für verschiedene Geschdindigkeiten, etc.), sodass diese einzeln ein- oder ausgeblendet werden können.


    Und dann muss man, in einer für sich sinnvollen Reihenfolge, alle gewünschten Kombinationen einblenden und abspeichern.


    Für Textfelder die ungefähr immer gleich gross sind, wie bspw Geschwindigkeiten, reicht eine Ebene, die man schlicht manuell anpasst.


    Der grosse Vorteil liegt darin, dass man sich genau einmal Gedanken über die Positionierung aller Elemente machen muss, um diese anschliessend für alle Bilder identisch beizubehalten.


    Wenn dies für Meterspur Fever Schweiz mit den Signalmasten von f1rnen ist, könnte ich dir meine dazu passsende GIMP-Vorlage zukommen lassen. Meld dich per PM wenn du Interesse daran hast sie anzuschauen oder auch zu verwenden. Dies gilt selbstverständlich auch, wenn es für eine andere Mod ist.

    Ich verweise auf diesen Download und diesen Thread von f1rnen .


    Die Typ N Signale stehen zwar in seiner Planung, das kann aber durchaus noch eine Weile dauern.

    Wie es um Typ L Signale mit Signalbrücke steht, muss auch er gefragt werden.


    Nach meinem Erkenntnisstand ist seine Mod und die Bauanleitung hier alles was es bisher zu den Typ L und Typ N Signalen für TPF2 gibt.

    Für Typ N wirst du dich vorerst hiemit abfinden müssen. Für Typ L hast du die Wahl für beides, oder jene Version die du lieber magst, zu nutzen.


    Weil bei mir kam ein unerfolgriche resultat.

    Wenn du mir hier beschreiben kannst, was genau nicht funktioniert, dann kann ich dir möglicherweise helfen.

    Der Funktioniert alleine ohne andere Mods

    Ich habe mir noch einmal die Fehlermeldung angeschaut. Es macht zwar in meinen Augen wenig Sinn, wenn der Fehler nur in Kombination mit anderen Mods auftaucht, aber dort steht key not found: materials. Wenn ich das richtig interpretiere, dann wurde in einer der Mesh Dateien der Eintrag materials nicht gefunden. Es wäre möglich dass dir bei Schritt 4 ein Fehler eingeschlichen ist, weil dort genau jener Eintrag bearbeitet wird. Eine falsch positionierte Klammer oder Komma kann schnell passieren und könnte zu einem Spielabsturz führen.


    Um in der Hinsicht sicher zu gehen, solltest du den ganzen Schritt 4 überprüfen. Aber wie schon erwähnt, ein solcher Fehler sollte meiner Meinung nach nicht nur in Kombination mit anderen Mods auftreten.

    Und bezüglich stdout siehe obigen Beitrag von elektronikfreak.

    Der Funktioniert alleine ohne andere Mods und mit dem Konvertierten L System aber sobald andere Mods mitdazu kommen schmeißt er mir einen Fehler raus. Sonst Funktioniert der Mod einwandfrei.

    Auch die transfer_log impliziert genau das. Ich wollte da kurz sicher gehen, um Fehler in der Konvertierung auszuschliessen.


    Ich denke, dass irgend ein andere Mod Probleme verursacht

    Hast du folgendes schon probiert?

    • Die Modauswahl welche zum Absturz führt ohne diese Mod zu nutzen. Ich würde vermuten, dass irgend eine andere Mod dann einen Absturz verursacht. Damit könnte man definitiv feststellen, dass eine andere Mod probleme verursacht.
    • Aktiviere die Hälfte deiner Mods und schaue ob es immer noch zum Absturz kommt. Anschliessend aktiviere die andere Hälfte und überprüfe das gleiche. Das sind zwei Tests und in einem Fall sollte das Spiel funktionieren im anderen nicht. Damit könntest du eingrenzen, welche Mod Probleme verursacht.
      Für die Menge an Mods mit dem Problem kannst du das ganze wiederholen. So kannst du relativ schnell eingerenzen, welche Mod das Problem verursacht.


    Allgemein würde ich auf eine Mod tippen, welche stärker in das Spiel eingreift. Sämtliche Fahrzeugmods könnte man wahrscheinlich ausschliessen.


    Könntest du auch noch die stdout Datei direkt nach dem Absturz hochladen. Vielleicht lässt sich darin erkennen, welche Mod Probleme verursacht.

    ich habe ein Problem. Ich habe beide Signalsysteme konvertiert und sie laufen auch ansich super solange ich sie alleine in einer Map lade aber sobald ich sie mit anderen Mods lade gibt es immer eine Fehlermeldung.

    Kannst du genauer umschreiben was funktioniert oder eben gerade nicht funktioniert?


    Funktioniert das exakt selbe Signal auch ohne andere Mods? Ich denke wenn da ein Fehler vorliegt, müsste dies generell nicht funktionieren.


    Könntest du die Datei transfer_log.lua aus dem Modordner als Dateianhang hochladen. Diese wird bei der Konvertierung erstellt und darin könnte ich erkennen ob da Dateien fehlen.