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.
Hallo, ich habe mal eine Frage zum Grafikmodus von Traffic.
Meist verwende ich den Modus DirectX, tripple frame. Aber ab einer bestimmen Anzahl von Zügen die durch das Bild fuhr, sind die Züge nicht mehr durchsichtig. Bei den anderen DirectX Modussen ist das das selbe Problem.
Ich habe es in diesem Thread schon mal angemerkt, will es aber hier auch noch mal schreiben:
Ich habe versucht, Güterzüge zu programmieren, die aus tausenden (!!!) unteschiedlichen Waggons zufallsgeneriert zusammengestellt werden. Bei dieser Programmierarbeit ist mir ein sehr lästiger Fehler im Bildschirmschoner aufgefallen: Anfangs habe ich versucht, sämtliche Güterwagen in ein einziges $DEF-Kommando zu packen. Das Ergebnis war die Fehlermeldung Nr. 11611 "Timetable line too long". Bisher habe ich das "umgangen", indem ich die Wagen in viele $DEF's aufgeteilt habe. Das funktioniert zwar, ist aber doch sehr umständlich. Vielleicht kann Zoltan/Godeny in der nächsten Traffic-Version das Problem mit der Zeilenlängen-Begrenzung beheben, also dass das Programm BELIEBIG lange Fahrplandatei-Zeilen verarbeiten kann (ich habe ihm das Problem bereits gemailt, es kam jedoch bisher keine Antwort). Ich vermute, diese Beschränkung stammt noch aus der Zeit der PC's vor 10 Jahren. Heutige Rechner mit mehreren Gigahertz und mehreren Gigabyte Arbeitsspeicher dürften damit aber kein Problem mehr haben. Diese Zeilenlängen-Begrenzung ist meiner Meinung nach im Moment der größte "Bug" in Traffic.
Nach eine weile ohne Internet "zu Hause" melde ich mich zurück (bis Herbst bin ich in Braunschweig, es hat gedauert, bis das eingerichtet wurde).
Ich freue mich, Andreas, dass Du dich mit Deiner Meinung gemeldet hast, aber einverstanden bin ich damit nicht.
Im Moment der größte "Bug" in Traffic ist es, was so aussieht, als Traffic abgestürzt hätte. In Vollbildschirm-Modus können auch Fehlermeldungen kommen, die einen MessageBox anzeigen. Der Bildschirmschoner-Fenster ist über allen anderen, der Fehlermeldung hat in Augenblick diesen Eigenschaft nicht - also die Fehlermeldung ist versteckt hinter dem anderen Fenster. Was man davon sieht: alles hält an, nichts geht weiter. Man drückt vergeblich Tasten auf seinem Tastatur: die Fehlermeldungs-MessageBox ist ja unsichtbar, hat den Focus nicht.
Genau so "tödlich" ein Fehler in der Analyse der Zugdefinitionen (zwei auswahl-Möglichkeiten mit leeren Einheiten hintereinander, wie C=A,|B,|C; ) - eine kurze Endloßschleife sorgt für den Abgestürzt - Gefühl.
Die beiden habe ich inzwischen gefunden und korrigiert. Eine neue Version ist in wenigen Wochen zu erwarten (zusammen mit verbesserten Multi-Monitor Behandlung).
Was die begrenzte Auswahl-Länge betrifft: ich denke nicht, dass man jede Begrenzung abschaffen sollte. Es gibt inzwischen über 10.000 normalspurige Güterwagen aus Europa - zählen wir nur das zusammen, was miteinander in einem Zug theoretisch laufen könnte. Aber es ist sehr unwahrscheinlich, dass eine Epoche 1 oder 2 Wagen mit hochem Brenshäuschen in einem Zug mit einem modernen Habins fahren wird. Zufallsgesteuerte, doch authentische Züge zusammenzustellen ist eine harte Arbeit, nicht alles passt zueinander.
Genau so passen vor 10 Jahren gezeichne, 16-Farben Zeichnungen nicht zu den heutigen Zeichnungen. Güterwagen sind nicht so sensibel, wie Personenwagen (man merkt schon wenn IC-Wagen von Daniel Hentschel, Florian Albers oder Marc Le Gad in einem Zug gemischt fahren). Also: was sowohl historisch, als auch zeichnerisch zusammenpasst, soll in Handarbeit ausgewählt werden.
So nebenbei: es mag schon sein, dass die heutige Rechner deutlich schneller sind, als vor 10 Jahren, und entsprechend mehr Speicher besitzen, aber für eine lange Güterzug 10.000 Namen etwa 50 mal durchforsten zu lassen - das bitte lieber nicht. Das wird sich bestimmt im Laufzeit bemerkbar zeigen (Züge werden während der Vorbereitung rückeln). Den Auswahl auf mehrere $DEF-Anweisungen aufzuteilen heißt: Traffic trifft mehrere, aber deutlich kürzere Entscheidungen.
Ich habe schon Pläne in eine ähnliche Richtung (also Auswahl aus größeren Mengen machen zu lassen), aber ganz anders: es sollte in eine zukünftige Version möglich sein ein Auswahl unter einem Label in der Fahrzeugliste zu machen. Vorteil: wenn in der Zukunft unter der selbe Kategorie mehr Zeichnungen hinkommen, dann werden die neue Bilder auch in dem Auswahl berücksichtigt. Nachteil aber, das die Unterschiede in Zeichnungsqualität dabei nicht berücksichtigt werden können. Dazu sollte man noch eine "Qualitätskriterium" einfügen (was eigentlich schon vorhanden ist, es sind die "Code1", "Code 2" farbige Märker) - aber die mehr, als 100.000 Bilder zu bewerten, ob sie zu einander passen, und diese Farbige Märker entsprechend zu setzen wäre eine Sisyfos-Arbeit.
Den Fehler habe ich auch schon bemerkt. Schön, dass das jetzt korrigiert wird.
Das mit der Vorbildgerechtigkeit würde ich nicht ganz so verbissen sehen. Denn mit dem Traffic-Schoner hat man - ähnlich wie bei einer Modelleisenbahn - die Möglichkeit, die Fantasie spielen zu lassen und auch Züge "bunt gemischt" zusammenzustellen, auch wenn es sie beim Vorbild nicht unbedingt gegeben hat. Und dann kann es durchaus nett sein, wenn Traffic für einen einzelnen Zug aus Tausenden Loks und Waggons zufallsgeneriert auswählen kann.
Du sagst ja, in ein paar Wochen soll es eh eine neue Version geben. Nimm doch da einfach mal (wenn es programmiertechnisch geht), diese Zeilenbegrenzung (timetable line too long) raus, und man kann dann mal schauen, wie sich das Programm damit in der Praxis verhält. Ich würde das schon gerne mal testen... Wenn es dann Probleme geben sollte, kann man die Beschränkung ja wieder reinmachen, bzw. kürzere Fahrplanzeilen schreiben. Aber einen Versuch fände ich mal gut.
Andreas WeiseBearbeitet von AndreasWeise am 07.05.2011 11:30
Diese Aussage ist jetzt 5 Monate alt, also deutlich mehr als "einige Wochen". Mich interessiert mal der aktuelle Stand der Dinge, also wann tatsächlich mit einer neuen Version zu rechnen ist.
Es ist ein bischen mehr geworden, als geplant: es gibt auch neue Funktionen, die interessanteste: bewegte, breite Hintergrundbilder, sogar mit mehreren Ebenen, die mit unterschiedliche Geschwindigkeiten bewegen.
Die Neuheiten werde ich morgen beschreiben, entschuldigt, heute bin ich viel zu müde (ich habe 1200 km gefahren). Ich wollte nur kurz reinschauen, was los ist ...
ich habe mir die neue Version runtergeladen. Da Zoltan/Godeny gesagt hat, dass er die Zeilenlängenbeschränkung aufgehoben hat, habe ich mal versucht, die von mir letztens hier gezeigte "Griechische Güterbahn" mit den aus tausenden Wagen zufallsgenerierten Güterzügen umzuarbeiten.
Die gute Nachricht vorneweg: Es geht schon um einiges besser; ich habe nun schon eine größere Anzahl Wagen in weniger $DEF-Gruppen unterbringen können. Im Anhang habe ich den überarbeiteten Fahrplan drin: "Griechische Güterbahn.ttt" ist die Hauptdatei, die in den Traffic geladen wird, und "Güterwagen.ttt" ist mit $INC in die Hauptdatei eingebunden.
Ich habe die Güterwagen-Datei allerdings auch mal in einer Version programmiert, wie ich sie mir eigentlich vorstelle - also ohne die lästigen $DEF-Gruppen. Diese Datei führt allerdings direkt beim Start von Traffic zum Programm-Absturz (der jetzt wenigstens nicht mehr mit einem System-Neustart verbunden ist). Ich habe diese Datei mal als "Güterwagen (ABSTURZ).ttt" mit hochgeladen. Ihr könnt die ja mal testen (einfach in Güterwagen.ttt umbenennen, dann passt sie auch zur Griechischen Güterbahn.
Der Sinn dieser jetzt zwar verbesserten, aber immmer noch bei weitem nicht ausgemerzten Zeilenbeschränkung erschließt sich mir nach wie vor nicht; zumal Traffic an sich keine besonders hohen Anforderungen an den PC stellt (selbst bei Prozessobelastung 1% läuft er sauber durch).
Andreas WeiseBearbeitet von AndreasWeise am 18.09.2011 00:26
An die oben genannten Stellen ist eine korrigierte Version von Traffic. Jetzt läuft auch Deine riesenlange $DEF - Zeile.
Ich halte es trotzdem nicht ratsam so lange Textzeilen zu schreiben. Wenn Traffic die nächste Zeile verarbeitet, könnten die Züge, die schon auf dem Bildschirm sind, rückeln.Mehrere kleinere Zeilen werden deutlich schneller verarbeitet.
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 «