Ohne jetzt potentielle neue Traffic-User abschrecken zu wollen: In diesem Thread soll es mal um Bugs, Macken und dergleichen gehen, die Traffic ab und an an den Tag legt. Das könnte zukünftige Bugfixes und schnelle Workarounds erleichtern.
Ein Problem, das bei mir speziell bei speicherintensiven Fahrplänen mit Vorder- und Hintergrundbildern auftritt, sind gelegentliche Programm-Freezes zweierlei Natur, die aber beide Windows dermaßen überlasten, daß manchmal nicht mal der Task-Manager zu öffnen geht. Die einen treten auf, wenn man den Schoner an sich (also nicht das Konfigprogramm) beenden will. Seit V 4.5.6 loggt Traffic zumindest einen Fehler (Index is out of bounds, wenn ich mich recht erinnere) das aber so oft und so intensiv, daß das ganze System blockiert wird, bis man das Programm per Task-Manager killt.
Noch größere Speicherfresser tendieren dazu, mitten im Betrieb zu freezen, weil Windows der Speicher ausgeht. M?glicherweise l??t sich dies lindern, indem der virtuelle Arbeitsspeicher bis zum Gehtnichtmehr vergr??ert wird (oder mehr RAM eingebaut wird). Was aber definitiv eine Erleichterung bringt, ist, auf den DirectX-Dreifach-Modus zu verzichten, denn Traffic l?uft auch im Doppelt-Modus geschmeidig ? und besitzt dann bei Speichermangel meistens den Anstand, sich einfach mit einer Fehlermeldung zu schlie?en. Zumindest einen Fahrplan kann ich jetzt wieder gefahrlos nutzen, der vorher zu schweren Freezes neigte.
Was Traffic im GDI-Modus gar nicht mag, ist, Fahrzeuge mit Phasenbildern mit [CO:]-Befehlen zu kuppeln. In meinem Fall hab ich eine achtphasige P8 von Jürgen Hoffmann ihres Tenders beraubt und den Tender dann separat angekuppelt. (Vorteil: Ich brauche weniger Lok- und Tendervarianten unterm Strich.) Jetzt hängt das Führerhausdach aber ein Stück über den Tender, also mußte ich einen Kupplungs-Offset einstellen, und zwar [COR:5].
Wenn die Lok solo fährt, ist alles in Ordnung. Im Vollbild-Modus mit DirectX auch. Aber ohne DirectX ist die Darstellung der Lok in dem Bereich, den der Tender nicht überlappt, bei allen Phasen außer einer seitlich verschoben (Teile des Führerhauses tauchen auf einmal vorne auf usw.).
Bei M=CUT: Wenn als Fahrtrichtungen D1=R;D2=L;D=L angegeben wird, fahren C1 und C2 nach der Trennung beide nach links weiter. Eigentlich müßte C2 als erster nach rechts weiterfahren und dann C1 nach links. Ähnlich im umgekehrten Fall, also D1=L;D2=R;D=R, dann fahren beide nach rechts weiter.
Man kann sagen, daß M=CUT es nicht erlaubt, den hinteren Zugteil zuerst abfahren zu lassen. D1 ist also wirkungslos, wenn es ungleich D ist.
Oder war es wirklich so vorgesehen, daß D1 für C1 ist und D2 für C2? Das wäre ziemlich unpraktisch, weil der Zugteil, der als erster abfährt, ja nur in eine Richtung fahren kann. Wenn D1 und D2 chronologisch abgefragt werden, kann man damit auch auswählen, welcher Zugteil zuerst fährt.
Edith merkt an, daß es bei M=CUT2 genauso ist. Nur fährt nach dem Anhalten dann erst der hintere Zugteil ein Stück zurück, dann fährt der vordere vorwärts ab, dann der hintere vorwärts.
es ist aber wirklich so, D1 gehört zum C1, D2 gehört zum C2.
Sind die angegebene Richtungen unmöglich - also die rechte Teil muß nach Links, und die linke Teil nach Rechts - dann greift Traffic ein, das eine mögliche Situation herauskommt. Ich könnte mal nachschaun, was ich da genau mache, aber sowas sollte man nicht ausnutzen - unmögliche Bewegungen bitte lieber nicht setzen.
CUT und CUT2 verhalten sich sehr ähnlich. Der einzige Unterschied ist, wie sie die animierte Kupplungen behandeln. Versuch mal die kölner TW 4100, 5100, oder solche ICE, TGV, bei denen man die Bugklappe öffnen kann, mit beide Bewegunsbefehlen zu verwenden.
Ah ja. Dann finde ich es aber merkwürdig, daß C1 immer links fährt und C2 immer rechts. Mir würde dann eher eine Lösung gefallen, bei der z. B. C1 immer der Zugteil ist, der als erstes weiterfährt, auch wenn er dann rechts laufen würde.
Ist schon klar. Es sieht nur ein bißchen komisch aus, wenn der hintere Zugteil ein Stück zurück fährt, bevor beide nacheinander vorwärts weiterfahren.
Die Stromabnehmersteuerung mit PFU und PBU ist bei Loks mit nur einem Stromabnehmer fehlerhaft. Mit PFU bügeln sie nur an, wenn sie nach links fahren, mit PBU nur, wenn sie nach rechts fahren.
warum brauchst Du überhaupt PFU oder PBU bei Loks mit einem Stromabnehmer ?
Und über welchen PFU reden wir hier ?
Über den [PFU] - den Modifikatior, der in dem Fahrzeugmakro oder in dem Zugdefinition steht,
oder über den Aktion, des bei den Wartezeiten oder Streckenelementen vorkommt ?
Um sie in derselben Umgebung einsetzen zu können wie Loks mit mehreren Stromabnehmern. Zum Beispiel Bahnhofsszenen in Frankreich (die BB 15000 hat ja nur einen Stromabnehmer) oder mit meinen "frisierten" Mehrsystemloks, bei denen die Stromabnehmer länderweise zuschaltbar sind – wenn die eh nur in Deutschland fahren, haben sie nur einen ansteuerbaren Stromabnehmer.
Letzteres. Genauer gesagt soll die Lok mit einem Zug in einem Kopfbahnhof ankommen, abbügeln, und wenn die Wagen abgezogen worden sind, soll sie wieder anbügeln. Und da sollen in derselben Bewegung wahlweise Loks mit einem und zwei Stromabnehmern eingesetzt werden.
Übrigens scheint der ESC-Freeze wirklich noch nicht ganz "gebannt" zu sein. Inzwischen weiß ich zumindest ungefähr, was da passiert. Vorhin ist mir der Schoner als Schoner (also nicht im Testbetrieb) fast eingefroren, als ich ihn schließen wollte. Das war kurz nach dem Systemstart, und ich hatte noch nicht mal das Konfigurationsfenster auf. Zum Glück hat er sich dann doch noch geschlossen, aber die Fehlerdatei war voll mit einigen zigtausend Zeilen:
Die Sache mit dem PFU und PBU ist gar nicht so eindeutig.
Die selbe Problem gilt auch für PHU und PTU - wenn der erste / letzte Lok nur einen Stromabnehmer hat, dann geht es genau so schief, wie mit PFU / PBU bei allen Loks im Zug.
Aber dann kann man schon fragen: was soll passieren, wenn ein Lok mit ein oder zwei Stromabnehmern einen P3U / PMU Befehl bekommt ? Soll irgendeine hochgehen, oder nicht ?
Was sollen die PFIU und PBIU Befehle machen, wenn der Lok nur 3 Stromabnehmern hat ?
Und wenn nur 2 ?
Noch einfacher: ein P2U (oder PRU) soll den einzigen Stromabnehmer heben ?
Welches Verhalten ist logischer ?
Oder braucht man einen allgemeinen Schalter, der steuert, ob eine nicht vorhandene Stromabnehmer mit einem vorhandenen ersetzt werden soll, oder nicht ?
Oder lieber getrennte Aktionsnamen für "Stromabnehmer 2 hoch, wenn vorhanden, sonst nichts" und "Stromabnehmer 2 hoch, wenn vorhanden, sonst Stromabnehmer 1 hoch" ?
Ich habe die Stelle gefunden, wo es verarbeitet wird, und ich weiss, wie ich alles ,achen kann. Aber was alles soll ich machen ?
Das ist jetzt nur eine Idee von mir, aber ich würde sagen:
PFU, PBU, PHU und PTU heben bei Loks mit nur einem Stromabnehmer immer diesen einen Stromabnehmer an.
In dem Fall gar keiner. P3U/PMU spricht ja ausdrücklich den dritten Stromabnehmer an, den die Lok dann nicht hat, also passiert nichts.
Bei drei Stromabnehmern immer den inneren anlegen, denn dann gibt es ja einen inneren Stromabnehmer.
Den jeweiligen äußeren. PFIU und PBIU sind ja fahrtrichtungsabhängig, also entscheidet die Fahrtrichtung, welcher Stromabnehmer angehoben wird – der in Fahrtrichtung vordere oder hintere innere. Gibt es keinen inneren Stromabnehmer, werden die entsprechenden äußeren genommen. So kann man ganz elegant 185er mit zwei und vier Stromabnehmern durcheinander einsetzen, denn bei der 185 sind die "deutschen" Stromabnehmer innen.
Damit ist dann wieder ein bestimmter Stromabnehmer gemeint, unabhängig von der Fahrtrichtung. Also sollte hier gar keiner angelegt werden.
Für mich wäre logisch, wenn bei fahrtrichtungsunabhängiger Auswahl (also über laufende Nummer oder links/rechts) Stromabnehmerbefehle nicht umgeleitet werden, bei fahrtrichtungsabhängiger Auswahl sollten sie dann auf logische Art und Weise umgeleitet werden.
Wenn das ginge, das wäre auch nicht schlecht. Würde Traffic zwar noch ein bißchen aufwendiger machen, aber es wäre nicht schlecht.
Diese Webseite verwendet Cookies für die techn. Funktionalität und um Inhalte zu personalisieren und deiner Erfahrung anzupassen. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du den Einsatz von Cookies. » Hier mehr lesen zum Datenschutz «