Beiträge von Hehl

    Hallo EugenR,


    der bei mir betroffene Zugverband hat Ende Dez. '23 auch ohne TripleValveRatio noch reibungslos funktioniert. Der Standardwert ist m. W. auch lt. dem Tutorial von Rudolf RichterTripleValveRatio ( 2.5 ) gewesen. Mittlerweile dürfte der Initialwert bei TripleValveRatio=0 liegen. Ich kann das versuchen noch genauer einzugrenzen.


    Gruß Hehl

    Hallo EugenR, Du kannst unter Deinem Benutzerkonto und dann unter Benachrichtigungen ( Symbol Glocke) auf das Arbeitsrädchen (Einstellungen) klicken, und dann erscheint ein großes Auswahlmenue. Dort lässt sich unter Konversationen festlegen, ob Du auf eine Rückantwort z.B. eine Email-Nachricht erhalten wirst.

    Es kann sein dass die Funktionstaste <F6> durch das WIN-System blockiert wird. Das war mal in irgendeinem Forum ein Thema. Ich bin da aber kein Fachmann. Vielleicht weiß jemand Rat...


    Wie sieht es in den Tastaturbelegungen in den Optionen aus unter Anzeigen>Stationlabels ?

    Bloss nie diesen Eintrag "TripleValveRatio()" in einer WAG oder ENG Datei vergessen, die ein Triple_Valve im Bremssystem aufweist. Das ist relativ neu. Bis dato war davon auszugehen, dass der Standardwert TripleValveRatio( 2.5 ) genutzt wird, aber das gilt nicht mehr.


    Fehlt der Eintrag kann eine Lok die Bremsen nicht mehr lösen, kuppelt man an Waggons an, die den Eintrag missen lassen, kommt es zum Berechnungsfehler mit Geschw.=NaN und Absturz mit dieser Fehlermeldung:


    Code
    Error: System.ArithmeticException: Die Funktion akzeptiert keine nicht numerischen Gleitkommawerte.
    bei System.Math.Sign(Single value)
    bei Orts.Simulation.Physics.Train.LogTrainSpeed(Double clockTime) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\Orts.Simulation\Simulation\Physics\Train.cs:Zeile 2904.
    bei Orts.Simulation.Physics.Train.Update(Single elapsedClockSeconds, Boolean auxiliaryUpdate) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\Orts.Simulation\Simulation\Physics\Train.cs:Zeile 2034.
    bei Orts.Simulation.Simulator.Update(Single elapsedClockSeconds) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\Orts.Simulation\Simulation\Simulator.cs:Zeile 864.
    bei Orts.Viewer3D.Viewer.Update(RenderFrame frame, Single elapsedRealTime) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Viewer.cs:Zeile 783.
    bei Orts.Viewer3D.Processes.GameStateViewer3D.Update(RenderFrame frame, Double totalRealSeconds) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Processes\GameStateViewer3D.cs:Zeile 119.
    bei Orts.Viewer3D.Processes.UpdaterProcess.Update() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:Zeile 131.
    bei Orts.Viewer3D.Processes.UpdaterProcess.DoUpdate() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:Zeile 108.


    Es ist leicht zu überlegen, dass TripleValveRatio in den Berechnungen als Teiler fungiert, und duch Null zu teilen geht nicht. Vermutlich daher der Absturz.


    Also: "TripleValveRatio()" nie vergessen!

    Das war es, mit der markanten Signalbrücke in Romanshorn am schönen Bodensee


    Open-Rails-NewYear-MG-2024-03-10-02-46-40.jpeg

    Wieso, da ist sie doch die Signalbrücke. 8)


    In meiner Gegend war die Signalbrücke in Eutin Ausfahrt Richtung Lübeck auch immer sehr makant, aber dank der neuen KS-Signale seit 20 Jahren Geschichte.


    Andere Frage: Gibt es die Strecke irgendwo als Download? Ich besitze nicht eine Schweizer Strecke. Habe ich da etwas verpasst?


    Gruß Hehl

    Wie Du schon gesehen hast, funktioniert es bei einigen KS-Signalen und bei anderen nicht.

    nein, es wird bei allen KS-Signalen funktionieren, wenn ich damit fertig bin.


    Ich habe die Probe auf Exempel gemacht. Ein Signal aufgesucht, dass bereits im -cfg und script verändert wurde, aber in der Schienendatenbank noch den alten Eintrag KS_OPTIK_ROT ohne den Zusatz _HS aufweist.


    Das Ergebnis hat mich verblüfft. Es wird das Rote Licht als echtes Licht dargestellt und nicht das Semaphore-Klapplicht. Damit ist eine Änderung in der Schienendatenbank völlig überflüssig. Meine obigen Befürchtungen hinfällig.

    Bereits aufgestellte Signale brauchen also nicht verändert werden!


    Boris, wenn ich mit den KS-Lichtern vollständig fertig bin, werde ich Dir die geänderte sigcfg.dat und sigscr.dat zukommen lassen. Das Problem mit nicht sichtbaren Lichtern in der Testing-Version ist bereits gelöst.


    Gruß Henning


    P.S. Die beiden Lichter in meinem obigen Nebel-Bild wären noch viel fulminater, wenn ich den Standard Light Glow =3 nicht nach unten verändert hätte auf ORTSDayGlow ( 2.0 ). Ich empfand den Lichtschimmer als zu krass, aber das ist Geschmackssache.

    Die Lichter eigentlich ganz gut sichtbar trotz des Nebels...

    Scheint sich um zwei Signale zu handeln...

    Ahh, sind doch drei und zwar KS-Signale vom kshp. Typ.

    Das mittlere wurde mit dem Feature noch nicht ausgestattet (auch zwecks Vergleich).


    Bei den Signalen von DennisK gibt es nur wenige echte Lichter.

    Die meisten Lichter sind Shapes (Parts natürlich), die per Semaphore nach oben geklappt werden.

    Die lassen sich nicht heller oder dunkler schalten und mit 'Signal Light Glow' keine verbesserte Signalsichtbarkeit erzielen.


    Damit das aber geht (s. o.), müssen die Signallichter in echte Lichter umdefiniert werden.

    Das Probelm nun, alle KS-Signale verwenden z.B. für das rote Licht ein und denselben

    SignalType ( "KS_OPTIK_ROT" ). Die Signalschirme sind aber bei den einzelnen Bautypen unterschiedlich.

    Hier ein Licht zu definieren würde dann nur bei einem Schirm passen, bei einem anderen an der falschen Stelle sitzen. Daher muss das Script erweitert werden. Und das braucht etwas Zeit und ist zu testen.


    Alle Signale vom Kshp? Typ (KS-Hauptsignal) verwenden einen einheitlichen Signalschirm, sodass hier nur ein zusätzlicher SignalType ( "KS_OPTIK_ROT_HS" ) notwendig wurde. Genau damit habe ich deshalb begonnen.


    Weiteres Problem: Sind auf der Strecke nun KS-Signale bereits platziert, gibt es nach geändertem Script und sigcfg zwei Möglichkeiten.

    - Signale löschen und neu setzen (umständlich)

    - Schienendatenbank per Editor bearbeiten und an den richtigen Stellen Wortergänzungen wie "_HS" anfügen. (schwierig)


    Letztere Variante bevorzuge ich, geht viel schneller, ist auch nicht so schwer, aber es ist alles richtig zu machen, um seine Strecke nicht zu schrotten.


    Hallo Boris,


    dies alles als Erklärung, warum ich mich per PN noch nicht gemeldet hatte. Aber wie schon geschrieben, die Änderungen sind über Nacht nicht zu schaffen.


    Gruß Hehl

    Die Testing Version nutze ich eigentlich selten, habe sie mir wegen der neuen Lichtkonfigurationen heruntergeladen. Soweit so gut.


    Den Zugverband mit den neuen Lichtern wollte ich mit CC bzw. AFB ausstatten mit Kombihebel zur Geschwindigkeitsvorwahl. Beschleunigen tut er richtig, aber nicht bremsen, obwohl die CC-Konfiguration von einen bereits funktionierenden Fahrzeug übernommen wurde. Abändern einiger Werte führte nicht zum Erfolg....


    Rettender Gedanke: Mit ORNYMG gefahren, da klappt die CC wie sie soll, nur die neuen Lichter fehlen. Problem liegt also bei der Testing_Version.

    Bei mir 'pumpt' die Grafik überhaupt nicht, und das bei ausgeschaltetem Reduce Memory usage und Run at 32 bit. Hängt vielleicht doch mit der CPU zusammen?


    Boris, auf dem Testpfad schalten die KS-Signale korrekt. Ich muss das Problem mit roten Signalen bei Abzweigungen nachvollziehen können. Das Angebot mir die Scripts genau anzusehen bleibt.


    Gruß Henning

    Hallo Boris,

    deine Strecke Version 1.1 läuft bei mir unter der OR-Version 1.5.1 und ORMG Version 139 ohne "Pumpen" wie Du schreibst....

    Ich empfehle auch immer das 'Advanced adhesion model' abzuschalten, da es sehr rechenintensiv und praktisch immer fehlerhaft ist. Ob es das 'Pumpen' beeinflusst weiß ich nicht.

    Hallo Boris,


    hänge doch einmal ein paar Test-Pfade Deiner Strecke OR_Mannheim-Karlsruhe_V1_1 an, wo das Problem mit den KS-Signalen typischerweise auftaucht. (entweder hier oder besser per PN)


    Es liegt definitiv nicht an OpenRails, da die SignalLogik deutlich besser ist als im MSTS, sondern an den Scripts von DennisK, diese sind teilweise nicht OR tauglich. Kann man also lösen.


    Das ist aber eine Aufgabe nicht von Tagen, sondern von Wochen, da das Signal-Script sehr umfangreich ist; und mir fehlt auf ein wenig die Zeit.


    Gruß Henning

    Ich vermute der Ordner_Name mit den vielen Leerzeichen ist zu lang.

    UVAV SBB RABe 512 kiss

    Außerdem ist die mitgelieferte .con Datei leer.


    Habe ihn abgeändert nach SBB_RABe_512_Kiss und einen CON neu erstellt, danach ging es.


    Bei mir stürzte der TSRE5 ConsistEditor übrigens nicht an. Verwende einen älteren der Version 0.698. OpenRails sah sich aber außerstande den Zugverband zu laden <load error>. Nach Änderung des Ordner-Namens ist das Problem behoben.

    Kapitaen13 hat bereits weitere entdeckt...

    Zu dem Paket vom 14.01. gibt es ein Update vom 08.02. mit Hinweis das alte Paket zu ersetzen. Ein paar krasse Fehler bei den Weichen wurde behoben.

    Ich schaue mir das noch genauer an...

    Dynatrax_v0.52 gibt es bei https://www.digital-rails.com/dr_tools.html , v0.62 habe ich nur auf meinem Rechner gefunden. Ebenso wie DynaTrax_v1.0.1.1_beta und DynaTrax_v1.0.1.2_beta.


    Gruß Jan

    DynaTrax V0.52b. gibt es auch auf trainsim.com.

    DynaTrax_v1.0.1.1_beta gibt es auf der Seite von #pwillard railsimstuff.com. Da habe ich es auch her, aber bis jetzt noch nicht verwendet. Ob sich damit dpp-Profile nutzen lassen, weiß ich nicht.


    DynaTrax_v0.62 ist ja diejenige für die DBTracks-Profile.

    Danke Jan für Deine Antwort. Genau das Profil meine ich; das Standardset habe ich, da sind nur alle Shapes der Original MSTS Geraden und Bögen enthalten.


    Dennoch sorry, man sollte lieber einmal nachdenken, bevor man etwas schreibt.

    Meine Entschuldigung: Ich habe mich ca. zwei Jahre nicht mehr mit DBTracks befasst.

    Nun wollte ich noch Abschnitte in DBTracks umwandeln, wo ich füher keine Lust mehr zu hatte, und stand vor der gleichen Fragestellung schon einmal. Aktuell brauchte ich DB23 für a1t190r10d.s


    DB23_a1t190r5d.s hatte ich aber schon. Wie war ich seinerzeit vorgegangen?

    Ganz einfach, einen Dynamischen Bogen erzeugen mit exakt den erforderlichen Koordinaten, und ihn dann mit DynaTrax_v0.62 ins entsprechende Profil umwandeln.


    Werden abweichende Geraden benötigt, ist es keine Hürde, aus vorliegenden 10m, 50m oder 100m Shapes durch editieren der Koordinaten von points und uv_points diese herzustellen. Dadurch gewinnt man zugleich einen Einblick in den Aufbau der DBTracks.


    Mein Anliegen ist damit zunächst einmal geklärt.

    Ich finde es aber gut, dass der Gedanke die DBTracks bereit zu stellen, aufgegriffen wurde.

    Es gibt hier auch jüngere Mitglieder, die haben von DBTracks gehört, wenn es aber nirgends mehr zu haben ist, ist der Zug ganz einfach abgefahren.


    Gibt es für DynaTrax_v0.62 überhaupt noch eine alternative Download Quelle, bzw. für die DBTracks dpp-Profile zu DynaTrax?


    Gruß Hehl

    Das ist ja jammerschade.


    Kann nicht jemand der alles besitzt die Inhalte bei TT zum Download bereitstellen?


    Mir fehlen z.B. die Texturen zum DB23 Profil

    ( Schotter DB2 mit Holzschwellen, Schrauben statt Klammern ). Außerdem besitzt das Standardset zu diesem Profil nicht alle Bogenstücke. Ich bin mir nicht sicher, ob es dazu noch eine Ergänzung gab.


    Außerdem hatte ich mir nie Straßen-Shapes heruntergeladen. Die fehlen mir nun gänzlich.


    Gruß Hehl