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.
Beim Rangieren, also Lokwechsel, wär ich übrigens mit $DIR vorsichtig. Bei M=CHANGE beispielsweise fährt C2 immer vorwärts ins Bild. Wenn man jetzt seine Dampflokmakros alle fleißig mit $DIR so schreibt, daß sie Rauchkammer voraus fahren, und diese Makros dann als C2 verwendet, fahren die Dampfloks dann auch Rauchkammer voraus an den Zug und ziehen ihn Tender voraus aus dem Bild. (Sollte schon auffallen, wenn die Lok noch Wagen mitnimmt, die schiebt sie nämlich nicht, sondern sie zieht sie.)
Es empfiehlt sich also, z. B. fahrtrichtungsabhängige Dampflokmakros auch in Rückwärtsfahrt zu schreiben, wenn man rangieren will.
Allgemein gilt: $DIR schaut auf die erste Bewegungsrichtung, die der Fahrzeug machen wird (oder mindestens war mein Absicht).
Wenn man immer fahrtrichtungsabhängig etwas machen möchte (z.B. der Lokführer soll in die Fahrtrichtung vorne sehen - was man mit der Spiegelung eines kleines Bereichs, wo der Kopf des Lokführers sichtbar ist, lasst sich machen), hilft der $DIR alleine nicht. Was man mit $DIR steuert, wird ein mal bei der VOrbereitungen durchgeführt, vor dem der Fahrzeug auf dem Bildschirm erscheint. Wenn man etwas danach noch ándern möchte, bleibt nur eins: ein Animation zu definieren, worin beide Bilder enthalten sind, und mit Aktionen während der Wartezeiten muß man umschalten lassen.
Ein böser Bug scheint in Traffic (spätestens in Version 4.17, mit der ist er getestet) aufgetaucht zu sein. Er ist ziemlich leicht reproduzierbar mit M=GET oder M=PUT und einem beliebigen Vorder- oder Hintergrundbild, wenn die Züge nach rechts fahren sollen.
C,C1 taucht schlagartig am Gleis auf und rollt evtl. nach rechts ein Stück aus.
C1 steht fälschlicherweise rechts (statt links) von C.
Nach einer Wartezeit kommt C2 von rechts (statt links) angefahren, kuppelt an C1 an und schiebt (statt zu ziehen) C1 vor C vorbei mit defekter Transparenz.
Am linken Bildrand verschwindet C1, aber C2 bleibt schlagartig am Bildrand stehen.
C fährt wie gehabt nach rechts ab.
C kommt ganz normal von links auf den Bildschirm gefahren, bremst und hält an. C2,C1 kommt aber gar nicht, statt dessen friert Traffic ein, verursacht 100% Prozessorlast und muß mit dem Task Manager abgebrochen werden.
Wenn die Züge nach links fahren sollen, ist alles in Ordnung.
Martin
Edit: Diverse andere Rangierbewegungen (z. B. M=CUT oder M=PUSH) sind ebenso betroffen.Bearbeitet von MartinG am 10.04.2014 21:24
Beiträge: 158 Ort: Berlin Eingetreten: 25.07.12 Status: Offline
Eingetragen am 11.04.2014 20:03
Mmh, also bei mir kommt der Schienenbus von links, hält an und bekommt einen Güterwagen von
einer Köf (auch von links).
Die Köf fährt nach links zurück, und der Schienenbus fährt mit dem Güterwagen nach rechts.
Bei M=GET bekommt er ihn eben abgenommen. Alles ganz normal.
Grüße nach Hamburch
Ulrich
PS: Win7(32 bit) Traffic Version:4.17.0F (D11:4.17.0F Jan 8 2014)
Zuletzt habe ich's an einer zweiten Installation getestet.
Windows 7 (32 Bit)
Traffic Version: 4.17.0F (Dll: 4.17.0F Mar 2, 2014)
Da ist exakt derselbe Fehler aufgetreten. Getestet wurde sowohl mit vollen Adminrechten als auch mit eingeschränkten Benutzerrechten. Die Fahrzeugliste ist im Textformat und gegenüber der normalen traffic.stb um einige Bilder erweitert, aber anderweitig nicht modifiziert.
Den Fehler habe ich ermittelt unter Windows 7 (64 Bit); soweit ich weiß, sind die Traffic-Versionen identisch, ich kann das aber noch einmal überprofien.
In beiden Fällen (auch bei allen meinen anderen Traffic-Installationen) wurde Traffic 4.17 nicht neu installiert, sondern über ältere Installationen, um deren Daten (vor allem meine selbstgemachten) nicht zu löschen. Bei der Installation jeder Traffic-Version habe ich händisch die von Traffic in den Windows-Ordnern neu installierten Dateien – auf die hatten eingeschränkte Benutzer unmittelbar nach der Installation keinen Zugriff – mit Lesezugriffsrechten für eingeschränkte Benutzer versehen müssen, um Traffic nicht nur als Admin nutzen zu können. Ich hoffe, daß das darauf keinen Einfluß hat, aber man weiß ja nie.
Mir ist noch ein Fehler aufgefallen, der mit Vorder- und Hintergründen zusammenhängt:
Ich habe mit beweglichen Hintergründen (MBG=) experimentiert und dabei festgestellt, daß sie sich nicht mit Vordergrundbildern zu vertragen scheinen. Vor beweglichen Hintergründen sind Vordergrundbilder nur auf einem Streifen, der so hoch ist wie die Fahrzeuge (also 58 Pixel oder was auch immer als VH= eingetragen ist), klar zu sehen. Ober- und unterhalb dieses Streifens sind Vordergrundbilder im GDI-Modus "halbtransparent" und im DirectX-Modus überhaupt nicht zu sehen.
Als Beispiel habe ich mal den Fahrplan modifiziert, der in der Ankündigung von Traffic 4.14 zu finden ist und an sich perfekt funktioniert. Die einzige Änderung: Die Telegrafenmasten sind jetzt Vordergrund und 6 Pixel nach unten verschoben.
Beiträge: 158 Ort: Berlin Eingetreten: 25.07.12 Status: Offline
Eingetragen am 26.04.2014 21:02
Ich habe auf meinem Notebook die Traffic Version: 4.17.0F (Dll: 4.17.0F Mar 2, 2014),
und da sind die Fehler, die Martin beschreibt tatsächlich auch bei mir.
Entschuldige MatinG, dass ich Dir nicht geglaubt habe.
Das ist also ein Fall für Zoltan.
Es sperrt sie ja nicht, sondern es vergibt ganz einfach keine Rechte an normale Benutzer. Und bei jedem Update sind Traffic.scr und TrafScrB.dll wieder ohne Rechte für eingeschränkte Benutzer, die man nachträglich einsetzen muß. Bei kompletter Neuinstallation, wenn unmittelbar vorher kein Traffic installiert war, werden in System32 (oder einem vergleichbaren Ordner) mehrere *.ocx-Dateien installiert, die auch keine Rechte für eingeschränkte Benutzer haben.
Das sollte eigentlich ganz einfach nachvollziehbar sein. Mir ist es jedenfalls bei fünf unterschiedlichen Windows-Installationen (Windows XP Home 32 Bit Retail, zweimal Windows XP Professional 32 Bit OEM, Windows 7 Home 32 Bit System Builder, Windows 7 Professional 64 Bit System Builder) ausnahmslos jedes Mal passiert.
Beiträge: 158 Ort: Berlin Eingetreten: 25.07.12 Status: Offline
Eingetragen am 02.05.2014 23:39
Inzwischen habe ich mal ein wenig rumprobiert, und herausgefunden, dass es an der im Windows-Ordner
befindlichen „Traffic.scr“ liegt, weshalb die Fehler in den Fahrzeugbewegungen auftreten.
Unabhängig von der „TrafScrB.dll“, die ja auch im Windows-Ordner liegt.
Man kann sogar verschiedene Versionen der „TrafScrB.dll“ ausprobieren, funktionieren tut aber eine „Traffic.scr“, nämlich die vom 8.Januar, die aber auch eine Version 4.17 ist.
Das die Dateien eingeschränkte Benutzerrechte haben, spielt dabei keine Rolle. Alle Fahrzeugbewegungen
sind so wie sie sein sollen.
Leider ist nicht dokumentiert, worin die Unterschiede in den Versionen liegen, sicher ist aber,
dass die „Traffic.scr“ vom 8.Januar verbesserte Transparenzen hat,
und schon deshalb zu empfehlen ist.
Zur Zeit gibt es nun keinen funktionierenden Download von Traffic, und es wird wohl noch ein
bisschen dauern, bis sich Zoltan darum kümmert.
Daher biete ich allen, die die Version 4.17.0F (Dll: 4.17.0F Mar 2, 2014) haben,
eine „Traffic.scr“ zum Download an.
Die Datei entzippen und in den Windows-Ordner kopieren und ersetzen lassen.
Die dll-Datei braucht nicht verändert werden.
Dann geht wieder alles.
PS: Ein Feedback wäre nicht schlecht!Bearbeitet von Ulrich am 19.08.2014 21:54
Nicht zusammengehörende Traffic.scr und TrafScrB.dll manchmal funktionieren miteinander, manchmal nicht. Wenn der interne Datenstruktur sich ändert, was beide Komponente betrifft, werden alte und neue gemischte Komponente nicht mehr miteinander laufen - dass passiert meißtens ein Absturz.
Über den Fehler: es steht in der "Warteschlange" - nicht auf den ersten Platz.
Davor sind noch Probleme mit der Installation unter Windows7, und ein Abstrurz, wenn die zwischengespeicherte Fahrpalndateien eingelesen werden.
Also, ich bitte noch um etwas Geduld.
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 «
Hast Du schon für die
Eingetragen am 29.12.2006 09:50
Cookie-Control :