Beiträge von carlos

    Hallo,

    Alle Funktionen von TSUtil ekennen, wenn kein noch nicht erkannter Fehler vorliegt, automatisch den Packungsstatus von world, shape oder tile Dateien.
    Wenn nicht expliziert durch eine Option spezifiziert, wird die Zieldatei im selben Status abgelegt, wie sie auch aufgefunden wurde. dh. Wenn eine Datei komprimiert ist, wird sie dekomprimiert, bearbeitet und wieder komprimiert Genauere Informationen können in der LOG-Datei nachgelesen werden. So wird z.B. jede erkannte Dynatrax-Datei dort aufgelistet.

    Ein vorrausgehendes explizites entpacken ist somit NICHT notwendig und das Zielformat kann in den meisten Fällen durch Optionen beeinflusst werden (-c,-u)


    Mfg

    Carl-Heinz

    Hallo,

    Man kann ja auch die dynamischen Schienenstücke durch eine Kombination von statischen Schienenstücken ersetzen. Dann wird Dynatrax nicht benötigt und manche Probleme entfallen.

    Inzwischen sind ja nahezu alle kurzen Schienenstücke (ab o.3m) von XTrack auch für DB-Tracks vorhanden. (verschiedene Versionen)


    Wer diese noch nicht hat, kann sie unter http://www.carloshr.de herunterladen.

    Falls noch etwas fehlt bitte bei mir melden. (Die version 'Stadtbahn HH' habe ich noch nicht generiert.Kann ich jedoch nachholen, da ich eine entsprechende Prozedur habe)


    Mfg

    Carl-Heinz


    PS: Dies habe ich bei meinem Umbau von Ostsee2 nach Ostsee3 genutzt. Alle dynamischen Schienenstücke , die ich anfassen musste, wurden duch statische Kombinationen ersetzt. Hiedurch wurde die Anzahl um ca. 90% reduziert.

    Hallo,
    Bei mir funktioniert das aber AUCH wenn ich den Dateinamen benutze.


    Service-Datei "01e-Teil2.srv"


    Wie man sieht ist die Namenserweiterung "(OR)" NICHT in der Eventdefinition vorhanden. Die Funktion funktioniert jedoch einwandfrei.
    Gruß
    Carl-Heinz (Carlos)

    Hallo,
    das Problem wurde endgültig identifziert und gelöst.


    Bei der Einrichtung der alten Strecke wurden die Signaldefinitionen "optimiert". Dabei wurden auch in den Signaltype-Definitionen unbenötigte Einträge entfernt. Dies betraf auch den Eintrag 'Sinallighttexture' für Signale, die OHNE Lichter und nur mit Hilfe von Semaphoren funktionierten. MSTS hat mit solchen Definitionen kein Problem.


    Anders jedoch ORTS. Wenn im Systemtype-Eintrag keine Eintrag Signallighttexture vorhanden ist, funktionieren auch die Animationen nicht; unabhängig davon ob eine Lichttextur benötigt wird oder nicht.


    Nachdem ich bei allen Systemtype-Einträgen den Eintrag Signallighttexture nachgetragen hatte, funktionierten die Animationen auch unter OpenRail. Dabei war es völlig egal, welche Textur ich nachgetragen habe.
    Die Signaldefinitionen habe ich übrigens auf das Original zurückgesetzt (bezügl. Animationen)


    Viele Grüße
    Carl-Heinz

    Hallo,


    Die Route und den Ablauf des Gegenzugs ist etwas problematisch, da dieser Zug in mehreren Aktivities zu unterschiedlichen Zeiten eingesetzt wird.


    Ich habe dennoch den Service modifiziert und weitere Tests gemacht:


    Wenn ich den Wartepunkt soweit verlängere, dass der Spielerzug das Einfahrt-Vorsignal des Begegnungsbahnhofs erreicht hat, funktionirt die Begegnung und der Spielezug fährt in das richtige Gleis ein.


    Daraufhin habe ich einen weiteren Test gemacht:
    Während der Gegegnzug in den Begegnungsbahnhof einfährt, fährt der dem Spielerzug vorrausfahrende Zug in das untere Gleis ein. Nach kurzem Halt fährt dieser Zug weiter, so dass dieses Gleis nicht mehr belegt ist.
    Wenn ich nun das Erreichen des Ausfahrtsignals des Gegenzug durch den Wartepunkt soweit verzögere bis der zweite Zug den Bahnhof velassen hat und das untere Gleis nicht mehr belegt ist, funktioniert auch die Begegnung.


    Scheinbar ist die Belegung des unteren Bahhofsgleises bei dem ersten Routencheck des Gegegnzuges für OR wichtiger als die definierte Route. Die gilt obwohl der Spielerzug den Begegnungsbahnhof (Einfahrtsignal) erst dann erreicht, wenn das Gleis schon wieder frei ist.


    Viele Grüße
    Carl-Heinz

    Hallo,
    Hier weitere Informationen, die für die Analyse des Problems wichtig sein könnten:


    Die Strecke vor dem Begegnungsbahnhof ist durch ein Blocksignal in zwei Abschnitte unterteilt und der Spielezug fährt im Blockabstand einem weiteren Zug hinterher, der die gleiche Route besitzt( in diesem Bereich)


    Wenn der Gegenzug in den Begegnungsbahnhof einfährt, fährt gleiczeitig der vorausfahrende Zug in das untere Gleis ein(korrekt!) Währendessen hat der Spielerzug noch nicht das Blocksignal erreicht. Der vorrausfahrende Zug verlässt den Begegnungbahnhof wieder innerhalb von Sekunden, da der Gegengzug die Folgestrecke nicht mehr blockiert. Wenn der Spielerzug das Blocksignal erreicht(Fahrt), ist der Bahnhof wieder frei und der Gegenzug wartet vor dem (Gegen-)Signal.


    Dann nähert sich der Spielerzug dem Einfahrtssignal. Ungefähr in Höhe des Vorsignals, versucht das System den weiteren Weg freizuschalten (Jetzt entstehen im Signal-Debugmodus die weissen Striche) Dieser Weg ist jedoch inkorrekt und führt Richtung Gegenzug. So kommt der Spielerzug vor dem Einfahrsignal zum Stehen.
    Info: Die Signalreservierung des Gegegzuges zeigt NUR das rote Signal.



    Viele Grüße
    Carl-Heinz

    Hallo Hehl,
    Ich habe testweise einen Wartepunkt von 15 sek in den Gegegzug eingefügt. Dies hatte KEINE Wirkung.


    Zusätzliche Information:
    Der Spielerzug ist eigentlich ein KI-Zug, der vom Spieler übernommen wurde.
    Die Activity besteht aus drei Teilen. Zuerst fährt eine Diesellok den Zug aus dem Ragierbereich zu einem Bahhof. Dort kuppelt diese ab und fährt in die Abstellung. Kurz vor dem Ende entsperrt sie eine ELok(Wartepunkt verkürzen) Der Spieler wechselt in die ELok, kuppelt an den Zug an und fährt zum Zielbahnhof. Auf dieser Strecke liegt auch das Problem. Am Zielbahnhof kuppelt die ELok vom Zug ab und fährt in das Betriebswerk. Kurz vor dem Ende entsperrt sie eine weitere Diesellok. Der Spieler wechselt in die Diesellok und bringt den Zug zur Zielposition.


    Viele Grüße
    Carl-Heinz

    Hallo Hehl
    Das Ausfahrsignal des Gegenzuges ist im 3. Bild zu erkennen (rote Zeile) Es steht VOR der Weiche die nach links abgeht. Vor diesem Signal steht der Gegenzug.
    Das Einfahrsignal des Spielerzuges ist leider nicht zu erkennen. Vor diesem Signal steht der der Spielerzug. Es zeigt ebenfalls 'STOP' und ist am unteren Rand des 3. Bildes plaziert.


    Wenn alles richtig läuft, sollte der Gegegnzug eigentlich die Einfahrweiche NICHT blockieren, da die Gegenzugfalle nicht vollstänig eingerichtet werden kann. Der Spielerzug ist ja schon in der Anfahrt und der Bereich für die Falle reicht ja bis zur nächsten Weiche im nächsten Ort des Gegenzuges.
    Möglicherweise gibt es bei der Behandluntg der Fallen noch ein Problem im OR.
    Übrigens: Dieses Problem tritt nicht bei allen Aktivities auf, die diesen Begegnungsbahnhof nutzen. Ich weiss jedoch nicht, was bei dieser Aktivity so besonders sein soll, dass dieses Problem immer wieder auftritt.


    Viele Grüße
    Carl-Heinz


    Hinweis: Die ersten beiden Bilder wurden geändert. (ggf Cache löschen)

    Hallo
    Vielen Dank für die Antworten. Ich habe es mir gedacht als ich die Hinweise im OR-Manual gelesen habe.


    Wie bereits genannt, sind die Werte in der Shape-Datei die Originalwerte aus dem Signalpaket 'KN2004' von Hagen Knop. Ich denke, dass die Absicht hinter den vielen Stufen innerhalb der Rotation war, die Geschwindigkeit der Bewegung zu verlangsamen. Es kommt leider sehr oft vor, dass die Flügel eines Hauptsignals zwischen den Endpunkten springen.


    Wie kann man grundsätzlich die Bewegungsgeschwindigkeit verlansamen?


    Viele Grüße
    Carl-Heinz

    Hallo
    Ich habe ien Problem mit einer Zugbebegnung. Obwohl die Routen für beide Züge eindeutig bestimmt sind, versuch OR eine andere Route zu wählen und es kommt zum Stop.
    Route des Gegenzuges:


    Route des Spielerzuges:


    Es gibt keine Ausweichrouten und dennoch versucht OR folgendes mit dem Spielerzug:


    Weiss jemand was das Problem sein kann?
    Dieser Fall tritt übrigens mit allen drei Versionen don OR (1.4,1.4Entwicklung, OR-MG) auf.


    Viele Grüße
    Carl-Heinz


    Hinweis: Der Gegegzug steht bereits im Bahnhof, wenn der Spielerzug ankommt.

    Hallo,
    Ich habe mit eine alte Strecke herausgesucht, und versucht, diese mit OR zu fahren. Dabei fiel mir auf, dass alle Flügelsignale den HP0-Zustand zeigten auch wenn die Fahrt freigegeben war. (Flügel und Lampe) Wenn ich die Strecke mit MSTS befuhr, funktionierte alles einwandfrei.


    Daraufhin habe ich mir die Signaldateien genauer angesehen und es fiel mir auf, dass der Signaltyp 'info' benutzt wurde um den Signal-State auf die Subobjekte zu übertragen. Hier ein Ausschnitt aus den Dateien:
    SignalShape (
    "KNSig_Fo1DB.s"
    "Formsignal DB (HP0/HP1)"
    SignalSubObjs ( 8
    ...
    SignalSubObj ( 4 "Fluegel1" " "
    SigSubType ( SIGNAL_HEAD )
    SigSubSType ( "FoHP1" )
    )
    SignalSubObj ( 5 "Lamps1" " "
    SigSubType ( SIGNAL_HEAD )
    SigSubSType ( "FoHP1L" )
    )
    ...
    SignalSubObj ( 7 "" " "
    SigSubType ( SIGNAL_HEAD )
    SigSubSType ( "FoHP_Frwd" )
    )
    )
    )
    SignalType ( "FoHP1"
    SignalFnType ( Normal )
    SemaphoreInfo ( 0.35 )
    SignalFlags ( SEMAPHORE )
    SignalDrawStates ( 2
    SignalDrawState ( 0 "HP0"
    SemaphorePos ( 0 )
    )
    SignalDrawState ( 1 "HP1"
    SemaphorePos ( 4 )
    )
    )
    SignalAspects ( 8
    ...
    ) SignalNumClearAhead ( 4 )
    )


    SignalType ( "FoHP1L"
    SignalFnType ( INFO )
    SemaphoreInfo ( 0.35 )
    SignalFlags ( SEMAPHORE )
    SignalDrawStates ( 2
    SignalDrawState ( 0 "HP0"
    SemaphorePos ( 0 )
    )
    SignalDrawState ( 1 "HP1"
    SemaphorePos ( 4 )
    )
    )
    SignalAspects ( 8
    SignalAspect ( STOP "HP0" )
    SignalAspect ( STOP_AND_PROCEED "HP0" )
    SignalAspect ( RESTRICTING "HP0" )
    SignalAspect ( APPROACH_1 "HP1" )
    SignalAspect ( APPROACH_2 "HP1" )
    SignalAspect ( APPROACH_3 "HP1" )
    SignalAspect ( CLEAR_1 "HP1" )
    SignalAspect ( CLEAR_2 "HP1" )
    )
    )


    SCRIPT FoHP1L


    extern float def_draw_state();
    extern float this_sig_lr();
    extern float state;
    extern float draw_state;


    state = this_sig_lr(SIGFN_NORMAL); // Aktueller Wert holen
    draw_state = def_draw_state(state); // und Status setzen
    return;
    //



    Ich habe mir das Manual von OR angesehen aber keinen Hinweis gefunden, dass Signale vom Typ INFO anders behandelt werden als die anderen Signaltypen.


    Als zweite Fehlermöglichkeit, sehe ich die Wahl der Semaphoreposition an. Die Position die hier angegeben wird, kann unter OR anders interprtiert werden. Hier gibt es auch einen Hinweis im OR-Manual. Die Werte sind aber die Originalwerte aus dem Signalpaket von 'Hagen Knop'.
    Hier der entsprechende Ausschnitt aus der Shape-Datei:
    anim_node Lamps1 (
    controllers ( 1
    tcb_rot ( 6
    tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
    tcb_key ( 1 0 0 0 1 0 0 0 0 0 )
    tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
    tcb_key ( 3 0 0 0 1 0 0 0 0 0 )
    tcb_key (4 0 -1.58427E-8 -0.362438 0.932008 0 0 0 0 0 )
    tcb_key ( 5 0 -1.58427E-8 -0.362438 0.932008 0 0 0 0 0 )
    )
    )
    )


    Hat noch jemand eine Idee?


    Viele Grüße
    Carl-Heinz

    Hallo
    Manchmal benutze ich TSRE5 um die Abfahrtszeiten im Activity-Editor zu ändern. Dabei ist gelegentlich des Ergebnis in OR und MSTS nicht mehr korrekt nutzbar.Eine genauere Untersuchung hat folgendes Ergeben:
    Vor dem Sichern der Activity und der Traffic-Definition sind folgende Eintragungen vorhanden:
    Traffic:
    Service_Definition ( "18-spieler(E)" 67500 )
    Service_Definition ( "18-Spieler(R)" 75900 )
    Activity:
    Player_Service_Definition ( 18-spieler
    Player_Traffic_Definition ( 67080 )
    UiD ( 0 )
    )
    ...
    Service_Definition ( "18-spieler(E)" 67500
    UiD ( 30 )
    )
    Service_Definition ( "18-Spieler(R)" 75900
    UiD ( 31 )
    )


    Nach dem Ändern der Fahrzeiten eines beliebigen Serveice - wobei die oben genannten nicht betroffen sind - und dem Speichern unter TSRE5, sehen die Ergebnisdateien wie folgt aus:
    Traffic:
    Service_Definition ( 18-spieler 0 )
    Service_Definition ( 18-Spieler 0 )
    Activity:
    Player_Service_Definition ( 18-spieler
    Player_Traffic_Definition ( 67080 )
    UiD ( 0 )
    )
    ...
    Service_Definition ( 18-spieler 0
    UiD ( 30 )
    )
    Service_Definition ( 18-Spieler 0
    UiD ( 31 )
    )
    Damit ist weder die Trafficdefinition noch die Activity nutzbar. OR fährt die Activiy dann OHNE Traffic.
    Nach händischem Editieren der entsprechenden Einträge ist die Activity wieder nutzbar.
    Ich habe in entsprechenden Foren (onrails.eu) gelesen, dass der Activity-Editor-Teil viele Bugs haben soll. Ist dieser bekannt?


    Mfg
    Carl-Heinz


    PS: Die genannten Services sind Folgeservices des Players, die mit Hilfe eines Lokwechsels benutzt werden.

    Hallo,


    Gemäss Handbuch - und in den nicht-MG-Versionen ist es auch so - kann man, wenn man sich in der Aussenansicht befindet, durch EINEN Klick auf die Ausenansicht des gewählten KI-Zuges wechseln und diesen beobachten.(Der Aufbau des Bildes dauert ggf. ein paar Sekunden)


    Nur wenn man den Zug übernehmen will, muss man ZWEIMAL klicken (eventuell mit shift um den alten Zug zu deaktivieren).


    Wie funktioniert das Beobachten dann unter der MG-Version. Wohlgemerkt, ich will den selektierten KI-Zug NICHT übernehmen sondern nur beobachten.


    Viele Grüsse


    Carl-Heinz


    PS: Die Übernahme des gwählten Zuges durch zweimal klicken funktioniert auch unter MG-101; wenn auch nicht korrekt.
    (Wenn ich z.B. aus Ansicht 2 einen KI-Zug übernehme und diesen fahre und ich dann auf Ansicht 2 wechseln will, wird mir der originale Zug angezeigt und nicht der gerade aktive.)


    PSPS:
    Ich habe gerade festgestellt, dass ich zur Beobachtung eines KI-Zuges AUCH die Ansicht wechseln muss.
    Nach einmaligem Klick kann ich den gewählten KI-Zug NUR in einer ANDEREN Ansicht als die Ansicht des originalen Zuges beobachten.