Beiträge von HansVader

Hier mal wieder eine Teilnahme von mir.

Ich habe mich mal im Internet umgesehen. Da ich kein italienisch kann, weiss ich nicht ob es sich auch hier um einen Scherz handelt, aber ich würde einmal auf eine Swiss Express Version tippen. Vielleicht hast du ja noch ein altes Projekt in der Hinterhand .

Bezüglich TPF1 worin bestehen da die Anpassungen? Wenn es nur Script-Anpassungen sind, dann hängt da möglicherweise bereits jemand am Hacken.

Hast du es nur im Model Editor getestet oder auch im Spiel? Fallst du möchtest kannst du mir eine spielfahige Testversion (=ich kann nur testen, was auch im Spiel genutzt werden kann.) per PM zukommen lassen, ich würde einmal einen Blick darauf werfen.

Aber dass die Lampen beim umschalten einmal flackern, sollte kein Problem darstellen, solange dass sie danach tatsächlich umschalten.

Wenn red und green verauscht sind, hast du es schonmal probiert richtig herum ausprobiert?

Fehler Korrektur in der Anleitung:

Ich habe heute durch einen erneuten Hinweis auf die Datei signal_sbb_typ_n_lampe_orange_rt.msh von bluespere einen Fehler in der Anleitung gefunden und korrigiert. Ich habe die Anleitung um folgenden Satz ergänzt.

Für die Datei signal_sbb_typ_n_lampe_orange_rt.msh muss der Eintrag zu materials = {"railroad/signal_sbb_typ_n/signal_sbb_typ_n_lampen_orange.mtl",}, angepasst werden.

Beim Erstellen der Anleitung ist habe ich vergessen, dass die Typ N Signale auch zwei verschiedene Mesh-Dateien für die orangen Lampen haben. Es ist mir nicht aufgefallen, weil die Datei gar nicht von der TrainFever Mod kommt.

Wenn in dieser zweiten orangenen Mesh-Datei auch auf das neu erstellte orangene Material verwiesen wird, sollten nun auch die orangen Lampen der Vorsignale leuchten, welche bisher nicht geleuchtet haben.

Berlinkeyx und Tomiiin haben auch schon darauf hingewiesen:

Zitat von Berlinkeyx

Schaue ich in die Mod-zu-Mod da gibt es nur die MSH und BLOB-Datei signal_sbb_typ_n_lampe_orange_rt wo ein solcher Eintrag drin ist.

Diesen habe ich rauskopiert und in die konvertierte Mod in der jeweiligen Msh Datei eingefügt. Aber sie leuchten immer noch nicht...

Es tut mir leid für meine Antwort, aber die Datei kommt tatsächlich in der Mod-zu-Mod vor. Und genau diese Datei muss noch angepasst werden, damit die restlichen Vorsignale auch noch leuchten.

Zitat von Tomiiin

Das Problem tritt eigentlich bei allen Signalen auf, ausser bei ein paar einzelnen Vorsignalen.

Es tut mir leid für meine Antwort bezüglich den Vorsignalen. Für die Vorsignale, welche gar nicht leuchten, muss stattdessen die Datei signal_sbb_typ_n_lampe_orange_rt.msh zusätzlich angepasst werden.

Für sowas empfiehlt es sich in die Signalmods anderer zu schauen. Im Grunde brauchst du ein mesh für die Lampe, dies mesh muss muss animiert werden und dieses mesh braucht ein leuchtendes material.

Für die Animation gibt es zwei Methoden:

Für TPF 2 kann man mit einer Animationsdatei das Signal umschalten. Diese Datei wird direkt in der mdl aufgerufen. Dazu braucht es einfach für das konkrete mesh einen zusätzlichen Parameter animations = {} in welchem die Animation entsprechend der Schaltung ausgelöst wird.

Weiterhin funktioniert es auch wie in TF und TPF1, dass die Animation selber in der mesh Datei definiert wird. In der mdl es braucht dafür zusätzlich einen events = {} Parameter, welche diese Animation auslöst.

Soweit ich weiss funktionieren aber beide Animationen (für Lichtsignale) gleich. Es wird jeweils das Licht nach vorne, respektive nach hinten verschoben. Das vordere Licht wird angezeigt, dass hintere Licht wird durch den Signalschirm verdeckt.

Damit die Lampen leuchten, musst du dem mesh ein entsprechendes material zuweisen. Dieses braucht einen "EMISSIVE" Eintrag. Der passende Lexikoneintrag dazu ist wohl jener um die helligkeit von Scheinwerfer anzupassen.

Wie anfangs geschrieben, am hilfreichsten ist es in das Script anderer Signal-Mods zu schauen. Aus diesem Grund verzichte ich darauf hier Beispiels-Codezeilen aufzuführen.

Ob es aber noch irgendwelche Besonderheiten für das erstmalige erstellen gibt weiss ich nicht, ich habe immer nur an bereits vorhandenen Mods gescripted.

Ergänzung zum oberen Post:

Ich habe mich noch ein wenig mehr mit dem Script der Steammod auseinander gesetzt.

Dank der starken Modularität der Mod wäre es möglich folgendes zu erstellen (Bilder sind nur Testversionen):

Man kann das Hauptsignal verbreitern und so auch die Signalversion mit 7 Lampen erstellen. Wegen der Modularität könnte man aber auch auf der linken Seite eine Linse weglassen, so dass man Signale mit 6 Lampen kriegt, wie man sie in der Realität antreffen kann. Es ist möglich eine andere Lichtreichenfolgen zu erstellen, um somit andere Versionen zu kriegen.

In gleicher Weise kann man auch ein kleines Vorsignal mit nur 3 Lampen erstellen.

Des weiteren ist es möglich auch Kombisignale zu erstellen. Leider fehlt dafür aber die notwendige Zusatztafel.

Und natürlich könnte man die Zugsicherung passend hinzufügen oder die Signale passend in die Signalkörbe verschieben.

Und um gewissen Fragen vorzubeugen:

Dieser und der vorherige Post dienen nur als Überblick über die Möglichkeiten, welche die Steammod schafft.

Nein ich plane nicht die Signale (in einer Mod-zu-Mod) oder eine Bauanleitung zu erstellen.

Ich nutze kein Steam, also ist es mir nicht möglich den Modersteller f1rnen zu kontaktieren. Somit kann ich weder Vorschläge oder Scripting-Mitarbeit anbieten oder um Erlaubnis für eine eigene Veröffentlichung erfragen.

@f1rnen

Falls du hier einmal zufällig vorbei kommst: Deine Mod hat Potenzial für einen weitaus grösseren Signalwald als nur GR, GRO, GROG und GRGOG. Wenn ich Zeit habe, würde ich va. beim Scripting durchaus Hilfe anbieten, um weitere Varianten zu erstellen.

Zitat von HundertDampf

Auf Steam gibts jetzt auch L-Signale, scheinbar (?) eine komplette Neuentwicklung, welche einfach aktiviert werden kann

Ich habe mal einen Blick auf die Mod geworfen.

Zumindest im Vergleich zu den TrainFever Signalen worauf meine Mod zu Mod und diese Bauanleitung basieren, kann ich sagen, dass es eine völlig neue Mod ist.

Zusammenfassung dieser neuen Mod:

Aktuell basiert die Steammod auf zwei Teilen:

Basismod

Signalversionen: GR, GRO, GROG, Vorsignal mit 4 Linsen

Erweiterung

Signalversionen: GRGOG, Vorsignal mit 5 Linsen (gibt es bei der Mod zu Mod nicht)

Signale gibt es rechts und links, haben aber keine Zugsicherungselemente und keine Signalbrücke.

Und die wahrscheinlich intelligenteste Idee dieser neuen Mod ist, dass Signal und Vorsignal für gemischte Signale separat gebaut werden müssen. Damit entfallen sämtliche Varianten für gemischte Signale.

Wer weder Zugsicherungselemente noch Signalbrücke braucht, und wer mit den angebotenen Signalversionen zufrieden ist, für dem ist die neue Steammod definitiv die bessere Entscheidung. Für ein Vorsignal mit 5 Linsen ist diese Mod ebenfalls verpflichtend. Ausserdem muss man dann die Mod nicht erst noch selber konvertieren.

Ergänzung:

• Weil die Mod keine Signalversion mit zwei Orangen Lampen hat, fehlt natürlich auch der Fahrbefehl 6.
• Die Vorsignale sind so konfiguriert, dass die Vorsignale bei "rot" immer Warnung anzeigen und nie ausgeschaltet werden.
• Die Signale werden nicht als Wegpunkte angeboten, und müssen dafür selber modifiziert werden.

Da der Release erst gestern war, ist es spannend zu beobachten ob und was noch kommt.

Zitat von kroki307

Jetzt stehe ich vermutlich auf dem Schlauch, weil ich es nicht schaffe, die gewünschten Signale zu aktivieren. Ich möchte nur die Fahrbegriff 1, 1vor, 2, 2vor, 3 und 3vor zu Verfügung haben.

Zitat von HansVader

Wenn du die settings.lua öffnest, hast du eine vielzahl an Einstellungen die du vornehmen kannst.

Einzelene Fahrbegriffe lassen sich nicht aktivieren oder deaktivieren. Ausserdem lassen sich die reinen Vorsignale nicht separat aktivieren.

Die reinen Vorsignale bekommst du, in dem du mind. eine Signalversion aktivierst und zusätzlich auch Vorsignale aktivierst. Damit werden aber auch die gemischten Signale aktiviert.

Die reinen Vorsignale befinden sich immer bei den Wegpunkten in einer eigenständigen Kategorie.

Wenn die gemischten Signale wirklich störend sind, könnte man diese durch Umstripten oder Löschen aus der Auswahl entfernen.

Falls das Problem der Umgang, respektive die Aktivierung über die settings.lua ist oder falls es etwas anderes ist, dann bitte ich um eine Konkretisierung des Problems.

Es ist noch nicht einmal 2021 und die Ae 8/14 sind praktisch fertig. Und erstnoch werden sie auch für TPF1 angeboten.

Danke Seamon

In einem kurzen Testlauf habe ich entdeckt, dass die Version Ae814_11851d das hintere Licht dauerhaft (egal ob vordere, mittlere oder hintere Position im Zug) eingeschaltet hat.

Ich habe mir heute deine Busse für TPF2 angeschaut. Zunächst möchte ich dir ein Kompliment für die Vielfalt und die üblich gute Qualität machen.

Mir sind aber zwei Dinge aufgefallen.

Zunächst kriege ich durch den Bus "NAW BGu-5 der ZVB" einen Spielabsturz, sobald ich ihn versuche auf eine Linie zu setzen. Die beiden anderen "NAW BGu-5" funktionieren. Ich kriege vom Spiel die Meldung: "Internal Error: An error just occurred." In der stdout steht nichts.

Und dann finde ich, dass die Zielanzeige oftmals undeutlich dargestellt wird.

Zitat von Tomiiin

Ich werde einfach nicht schlau warum die Signale so extrem hell sind. Habe alle Werte so eingestellt wie beschreiben.

Das Problem tritt eigentlich bei allen Signalen auf, ausser bei ein paar einzelnen Vorsignalen.

Dies kann mehrere Fehlerursachen haben. Ich würde dir empfehlen den ganzen vierten Schritt zu überprüfen.

Wenn die Lampen noch so weiss leuchten, dann sieht der Eintrag in einer der material Dateien vermutlich immer noch so aus: emissive_scale ={emissiveScale = { 0, 0, 0, }, },

Die drei Nullen musst du aber entsprechend der Lichtfarbe noch abändern. Mein Vorschlag steht oben, elektronikfreak hat einen anderen Vorschlag gepostet. Die Ziffern sind RGB-Werte [Rot-Grün-Blau], und die kannst du variieren, bis du mit der Farbe und der Helligkeit zufrieden bist.

Für das Vorsignal, das gar nicht leutet, hast du entweder in der Datei signal_sbb_typ_n_lampe_orange.msh nicht auf das neue material (signal_sbb_typ_n_lampen_orange.mtl) verwiesen, oder aber dieses nicht (oder nicht vollständig) bearbeitet. Wobei dann das andere Typ N Vorsignal genau das gleiche Problem haben sollte.

Falls dies nicht hilft, teste einmal ob die Signale ohne leuchtende Lampen funktionieren. Dazu verweist du in allen mesh-Dateien auf die entsprechend ursprüngliche material-Datei (signal_sbb_typ_n_lampen.mtl und signal_sbb_typ_l_lampen.mtl)

Falls diese funktionieren sollte zumindest ein Fehler vor oder durch die Konvertierung ausgeschlossen werden können.

Zitat von YnotAlucard

thank you for taking the time to respond in french

I hadn't noticed that I copied the wrong text. I wanted to write in English.

[...]

I really appreciate what you’re doing. Especially your YouTube series on Transport Fever 2, it allows me to find quite a lot of ideas to keep it as realistic as possible.

You asked in French, so there was no reason to not answer in French aswelll. As long as I understand it, it doesn't matter for me. But certainly I understand English much better.

Concerning YouTube you confuse me with someone else. Maybe it is Hans Dampf, who has his own account on this site.

Zitat von Berlinkeyx

Vielen Dank für die tolle Anleitung. Ich habe die N-Signale gleich beim ersten Versuch zum laufen gebracht.

Ich habe allerdings ein Problem sie leuchten zu lassen.

Wenn ich die MSH-Datei signal_sbb_typ_n_lampe_orange öffne befindet sich kein Eintrag mit materials = ... .

Wenn ich die BLOB-Datei signal_sbb_typ_n_lampe_orange.msh mit Notpad++ öffne, kommen nur komische Symbole und nichts strukturiertes.

Schaue ich in die Mod-zu-Mod da gibt es nur die MSH und BLOB-Datei signal_sbb_typ_n_lampe_orange_rt wo ein solcher Eintrag drin ist.

Diesen habe ich rauskopiert und in die konvertierte Mod in der jeweiligen Msh Datei eingefügt. Aber sie leuchten immer noch nicht...

Ich bin kein Moddingexperte wie ihr

Alles anzeigen

Meine Vermutung ist, dass bei der Konvertierung etwas falsch gelaufen ist. Sowohl vorher wie auch nacher müsste der Eintrag vorhanden sein. Wie ich gerade sehe, ändert sich scheinbar an der msh-Datei bei der Konvertierung nichts. Sogesehen könnte das blosse Hinzufügen des Eintrags reichen, was aber wohl nur ein Teil des Problems ausmacht, da es bei dir nicht funktioniert.

Jedenfalls an der blob-Datei sollte nichts geändert werden. Der Grund warum nur komische Symbole erscheinen, liegt darin dass diese wohl das eigentliche 3D-Modell beinhaltet und kein Scriptcode.

Was ich komisch finde ist, dass in der Mod-zu-Mod überhaupt eine Datei signal_sbb_typ_n_lampe_orange_rt.msh vorhanden ist. Die dürfte da nicht sein. Könnte es sein, dass du irgendwann in einen falschen Pfad kopiert hast? Ich könnte mit vorstellen, dass du die TrainFever-Signalmod (oder bloss ein Teil) in die Mod-zu-Mod kopiert hast, statt sie in den Modordner zu kopieren. Und weil dann die Datei gefehlt hat, hat der Konverter eine erstellt.

Meine Empfehlung wäre es das Ganze nochmal zu versuchen. Falls du TPF1 hast, könntest du die Standalone auch dort testen, bevor du die Mod konvertierst. Du müsstest dafür aber bereits vorher die vier Dateien (sh. Schritt 3) aus dem Mod-zu-Mod Ordner in den Modordner kopieren.

Zitat von YnotAlucard

Pouvez-vous m'aider?

Serait-il possible de convertir et de mettre le mod sur TPF. ne pas?

Excuse mon français, je ne suis pas entrainé de français.

Si il serait possible, je l'avait fait. Mais je peut te donner une courte explication des instructions. Je pense que il est pas mal auto-explicative.

La couleur rouge est seulement pour le type L et la couleur bleu est seulement pour le type N.

2.1 Ces sont les parts nécessaire.

2.2 C'est la création d'un dossier de la mod. Je la nomme "Modordner" dans l'instruction.

2.3-2.6 C'est seulement copier (=kopieren) un dossier et coller (=einfügen) lequelle dans la mod. Le gros texte sont les chemins (=Pfad) et les dossiers (=Ordner).

Pour 2.3 tu peut fair attention. En premier il est copier-coller. Après il est effacer (=löschen) des dossiers inutile [alles ausser= tout à part de]. En dernier c'est l'objective. Dans chaque chemain le dossier ETCS et le dossier PZB_Schweiz soient rester dans le dossier Zugsicherung.

3 C'est l'utilisation de la mod conversion. Après ça la mod soit fonctionner.

4 C'est l'éditer des fichier (=Datei) pour ajouter des lamps lumineuse. En premier tu dois fair trois copies et ensuit les nommer comme proposée. En seconde tu dois éditer ces nouveau fichier. Le gros texte dis-te ce que tu doit éditer. Finalement le text coloré sonst des ajustements des autres fichiers. Le paragraphe au-dessus dis-te quel chemins et quel fichier. Le paragraphe au millieu dis-te quelle l'entrée. Et le paragraphe en base dis-te comme tu dois les ajouter.

Si tu as encore des problemes, tu peut poser des autre questions.

Et si mon français est trop dròle, je n'ai pas the problem avec l'anglais.

Zitat von dt8_fan

Wäre es sinnvoll da Urbangames zu fragen?

Ich glaube nicht, dass sie da etwas tun werden. Sie haben besseres zu tun, als ihre Spielmechanik komplett zu überarbeiten. Hiermit muss man einfach leben, es ist schliesslich keine Eisenbahnsimulation.

Ich könnte mir sogar vorstellen, dass eine Änderung das komplette Spiel verhunzen könnte.

Zitat von dt8_fan

Also wäre dies dann eine Script Mod? Und einerseits aufändig aber trotzdem denkbar?

Wenn überhaupt, dann würde es wohl eine Script Mod sein. Aber ich vermute, dass es irgendwo "hard coded" ist und somit nicht über eine Mod veränderbar ist. Schliesslich geht es hier um die Kermechanik, wie Züge agieren und interagiren.

Zitat von WernerK

Der eingleisge Haltepunkt wäre ganz simpel zu realisieren. Signalfunktion der Bahnhöfe/Bahnsteige optional abschaltbar machen und gut is.

Bahnhöfe haben keine Signalfunktion, jeder durchfahrende Zug wird nicht durch einen Bahnhof beeinflusst. Wenn aber an Bahnhöfen gehalten wird, so markiert dieser das Ende des reservierten Pfades. Aber natürlich wenn der Zug wieder losffahren möchte, so tut er dies erst wenn der nächste Pfad wieder frei ist.

Vielleicht habe ich mich zuvor unglücklich ausgedrückt.

Zitat von HansVader

Das widerspricht aber genau der Funktionalität von Pfadsignalen, welche eben nur bis zum nächsten Halt geht und nicht weiter.

Ich meine nur bis zur nächsten Haltemöglichkeit. Damit meine ich jede Haltestelle der Linie und alle Signale auf der Linie. Ein Signal ist in der Hinsicht eine bedingte Haltemöglichkeit, weil der Zug dort hält, wenn der nachfolgende Pfad nicht frei ist.

Wenn kein Signal dazwischen ist, so ist der nächste Bahnhof auf der Linie immer das Ende des reservierten Pfades. Das hat aber nichts mit dem Bahnhof selbst zu tun, das ist lediglich die Konsequenz des verwendeten Signalsystems.

Wenn ein Bahnhof jetzt plötzlich nicht mehr als das Ende eines Pfades angesehen werden sollte, so müsste im Signalsystem selbst etwas verändert werden. Ob man dann die Pfadberechnung ändert, oder ob man schlicht ein anderes Signalssystem verwenden möchte, beides ist ein tiefer Eingriff in die Grundfunktion des Spiels.

Zitat von Bauer33333

Das ist auch mit Pfadsignalen umsetzbar, allerdings dürfte die Pfadberechnung nicht am nächsten Halt, sondern erst am nächsten Signal aufhören.

Das widerspricht aber genau der Funktionalität von Pfadsignalen, welche eben nur bis zum nächsten Halt geht und nicht weiter. Alles was weiter geht könnte zwar im gleichen Signalblock sein, ist aber nicht mehr im aktuellen Pfad.

Es macht keinen Sinn bis zu einem möglichen Haltepunkt und bereits zum nächsten Haltepunkt zu berechnen. Wozu bräuchte man den ersten haltepunkt, wenn man bereits zum zweiten rechnet? Gar nicht.

Um vielleicht einmal das Problem zu benennen, worum es eigentlich gehen sollte. Das Signalsystem im Spiel sind Pfadsignale. Dies bedeutet, dass ein Zug nur dann fährt, wenn der Weg, zur nächsten Haltestelle oder dem nächsten Signal auf dem Weg dahin, frei ist.

Das was aber hier gewünscht wird sind Blocksignale. Das ist eine völlig andere Herangehensweise. Innerhalb eines Blockes kann ein Zug beliebig fahren. Aber er fährt nur in einen anderen Block, wenn dieser kein anderer Zug beinhaltet. Signale dienen hier nur um Blöcke abzutrennen und die Einfahrt zu verwalten. Es ist aber eine weitaus stärkere Restriktion.

Natürlich sind Blocksignale vorteilhaft für das dargelegte Problem. Aber sie sind die Pest, wenn es um mehrspurige Verzweigungen geht. Jede Überkreuzung von parallelen Gleisen müsste mit Signalen getrennt werden, sodass zwei Züge aneinander vorbeifahren könnten. Zusätzlich müsste es ein Signal geben, welches das nächste Signal auf dem Weg kopieren könnte, so dass ein Zug nicht auf der Kreuzung wartet, um in den nächsten Blockabschnitt zu fahren.

Ich habe in Locomotion und Factorio genügend mit Blocksignalen handtiert, sodass ich mehr als froh bin in TF, TPF und TPF2 nicht diese Probleme zu haben. Würde man diese aber wollen, so wäre dies vermutlich ein tiefer Eingriff in die Spielmechanik.

Zitat von HundertDampf

Ich habe mir kurz die Mod angeschaut und das stimmt nicht, bei der Re 450 ist nach wie vor alles gespiegelt und das Mapping ist das selbe wie bei der Vanilla Version.

OK stimmt, ich hatte jetzt nur kurz das ganze Triebfahrzeug angeschaut. Ich bin eigentlich auch davon ausgegangen, dass das Mapping überall identisch ist. Aber es stimmt die kleinen Details (bsp Wappen) an der Re 450 haben auch das Problem.

Zitat von Banshee7

Dasselbe Problem hat auch die Re 450

Da du die Re 450 erwähnst, hat sich denn das Mapping von TPF nach TPF2 grundlegend verändert? Wenn nicht würde ich einmal einen Blick in die TPF-Repaints empfehlen. Beispielsweise condor-hm hat es in seinen Re 450 Repaints geschafft, dass die Beschriftung stimmt und nicht spiegelverkehrt ist. Falls also das Mapping mehr oder weniger unverändert geblieben ist, wären diese Repaints hilfreich um die Lösung zu finden.

Ich selber habe noch nicht geschaut ob die Repaints, welche vom vanilla Fahrzeug abhängen konvertiert werden können. Wenn aber das Mapping identisch (zumindest ähnlich, Problem: Zugzielanzeige) wäre, müsste dies dann auch funktionieren.