Beiträge von MarkMcWire

Ich verweise mal auf die beiden Diskussion in den Foren DSO und ICE-T

-> https://www.drehscheibe-online…ren/read.php?002,11163009
-> https://www.ice-treff.de/index.php?id=717051

Kurz gesagt, hat DB Systemtechnik den neuen Siemens NOVO-Wagen (EWET) in den ICE-S eingereiht und ist damit Testfahrten zwischen Erfurt und Leipzig gefahren. Die Strecke ist aktuell wegen Bauarbeiten gesperrt, daher kann man in dem Streckenabschnitt, wo aktuell nix gemacht wird, Testfahrten durchführen. Bei der letzten Testfahrt Richtung Erfurt hat der Zug 405,0 km/h erreicht und ist damit 2 km/h am alten deutschen Rekord von 406,9 km/h vorbeigefahren. Es waren bis zu 410 km/h von der Behörde für die Testfahrt genehmigt, aber wegen Gegenwind hat man den alten Rekord nicht geknackt. Siemens wollte ursprünglich nur 400 km/h haben, da man für die Zulassung für 360 km/h nur 10% mehr braucht, also 396 km/h.

Es hat sich nicht ganz bewahrheitet, die 5 der 6 Fahrzeuggruppen sollen zumindest bis Ende 2028 weiter fahren und dann durch Desiro HC aus dem Hause Siemens ersetzt werden.

Bis Ende des Jahres sollen erstmal 4 Fahrzeuggruppen / Triebzüge für einen innerdeutschen Testbetrieb ausgeliefert werden -> https://www.schiene.de/news-92…es-Halbjahr-erwartet.html

Wie schon in den Eisenbahnforen ICE-Treff und Drehscheibe diskutiert, scheiden die meisten Triebzüge dieser Baureihe Ende dieser Woche aus dem Fahrzeugbestand der DB. Finde ich echt schade, da 1501 auf "Eisenach" getauft ist und somit mein "Heimatzug" war.

Unter https://www.drehscheibe-online…879,10670553#msg-10670553 habe ich ne Liste der bereits aktuell ausgeflotteten Triebzüge gemacht. Stand heute fehlen fünf Triebzüge (1501, 1502, 1505, 1506, 1522).

Bis Dezember sollen 4 Triebzüge als Reserve im Einsatz bleiben, daher wird es eine Abschiedsfahrt erst zum großen Fahrplanwechsel geben.

Zitat von VacuumTube

Der Vollständigkeit halber:

Die Änderungen von MarkMcWire wurden im November zunächst in Gregorys Fork ("1.3" auf Steam) gemergt, dann aber kurz darauf wieder rückgängig gemacht, aufgrund der Inkompatibilität mit bestehenden Fahrplänen, d.h. alle Einträge waren weg. Seitdem ist dort nichts mehr passiert. Im Discord wird gesagt man kann MarkMcWires Version (1.3.7) manuell installieren, wenn man vorher in der sav.lua eine Anpassung vornimmt, genauso wie auch von WernerK oben beschrieben.

Hab nochmal kurz über die Changes geschaut: in der Theorie könnte MarkMcWires das Auftreten eines bestimmten (zufälligen) Crashs verhindern. Im Code sind allerdings auch viele Änderungen drinnen, die erfahrungsgemäß keinen Unterschied machen sollten.

Weitere Infos zu Hintergründen und Testberichte der verschiedenen Versionen wären sicher hilfreich.

Alles anzeigen

Hallo, da ich gerade angesprochen wurde. Ich habe in TPF2 die letzten zwei Monate nix mehr gemacht. Ich wusste damals nicht, dass es Auslagern von Scripten in eine Datei mit anderen Namen Einfluss auf bestehende Spielstände hat. Ich hatte bei mir zum Testen einen relativ neuen Spielstand genutzt, wo ich die Fahrpläne von Grund auf neu gemacht hatte.

Ich bin nach wie vor der Meinung, dass GUI und Engine in getrennte Skripte aufgerufen werden sollten, damit das Debuggen einfacher ist.

Ich vermute, dass es ein Synchronitätsproblem gibt beim Aktualisieren der GUI und der anderen Spielelemente.

Hab es jetzt als Github-Repo veröffentlicht -> https://github.com/MarkMcWire/TPF2-Timetables

Zitat von V200.1

Ich benutze die Version 1.2 Station Fix und habe damit keinerlei Probleme, mit der 1.3 hatte ich dagegen auch Abstürze.

Ich habe jetzt die Version 1.3 gefixt, wobei ich nur relativ wenig am Code geändert habe. Im Endeffekt habe ich nur ein paar Vorschläge hier im Thread umgesetzt und habe zudem zwei getrennte Skripte für GUI und Engine gemacht. Das dürfte auch das künftige Debuggen erleichtern. So kann ich gezielt das GUI oder die Zugsteuerung ausschalten und sehen, von welchem Teil das Problem stammt.

PS: Die aktuelle Änderung aus Github ist in meinem Fix schon mit eingearbeitet.

Zitat von constantinr72

Also soweit ich weiß müssten alle IC1-Wagen die fahren druckertüchtigt sein.

Nein. Es gibt auch noch IC-Wagen die nur druckgeschützt aber nicht druckertüchtig sind. Die erkennt man am )p(.

Zitat von Sir Ludicrous

jetzt wäre hier meine Frage, wie das denn mit den original MNX-Wagen aussieht.

Die MNE-Wagen hatten (p) angeschrieben, waren also druckertüchtigt, die normalen IC-Wagen ohne Spezialübergänge haben nur )p(, also druckgeschützt.

Zitat von einsmensch

Um mal meinen Senf auch noch dazu zu geben ich finde es durchaus sinnvoll sich Wagen als Ersatz zu halten um sie dann dort einsetzten zu können. Einfach für den häufig eintretenden Fall das mit den Skodas was nicht passt

Thema Höchstgeschwindigkeit:

Ich kann mir zwei Lösungen vorstellen

entweder macht man es wie auf der SFS Bamberg Erfurt und reduziert die Geschwindigkeit dauerhaft auf 250 km/h (wäre ja eh nur temporär ob das Auswirkungen auf den ICE Fahrplan hat keine Ahnung)

Die Relativgeschwindigkeit darf nicht größer als 410 km/h werden. Das heißt die RE1 dürften dann auch nur noch maximal 160 km/h fahren.

Ich habe eine Lösung gefunden. Ich habe das Script res/config/game_script/timetable_gui.lua in zwei Dateien aufgeteilt. Die original-Datei verwaltet nur noch das Interface und dessen Eingaben.
Das neue Script res/config/game_script/timetable_engine.lua verwaltet die Ausführung des Fahrplans und die Steuerung der Züge.

Inhaltlich habe ich ansonsten nicht viel geändert und trotzdem verschwindet dadurch das Memory Leak teilweise. Zwar wird beim Laden des Spielstandes zusammen mit dieser Mod rund 35 GB an RAM belegt (ohne diese Mod sind es nur 13 GB), jedoch steigt der RAM-Bedarf nicht mehr ins Unendliche und das Spiel bleibt dauerhaft spielbar.

Nachteil der Lösung war nur, dass ich sämtliche Fahrpläne neu anlegen musste, da die Änderung an der Mod die gespeicherten Fahrpläne in der sav.lua gelöscht hatte.

Da stellt sich mir natürlich auch die Frage, ob nicht die Löschung der alten Fahrpläne und das Neuerstellen das Problem behoben haben und weniger meine Änderung am Script, die ja eher kosmetischer Natur ist.

Wenn ich im Spiel alle Checkboxen der einzelnen Linien raus mache, hört das Memory Leak auf. Er bleibt dann aber auf dem bisherigen RAM-Belegungsniveau stehen und es wird nicht weniger. Wenn ich die Checkboxen wieder rein mache, steigt der RAM-Verbrauch auch erstmal nicht weiter an. Nach einiger Zeit steigt der RAM-Bedarf aber wieder an.

Das Spiel zu pausieren ändert auch nichts und wenn man es in höherer Geschwindigkeit laufen lässt, steigt der RAM-Verbrauch nicht schneller. Er ist konstant so bei 200-300 MB/s.

Ich habe verschiedene Zeilen und Funktionen testweise auskommentiert im Code. Es ergibt sich kein konsistentes Fehlerbild. Mal verschwindet das Leak, mal kommt es wieder. Ich würde sehr stark vermuten, dass das Problem bei TPF2 liegt und nicht alleine an dieser Mod.

Für den NüMüX / NIM-Express sollte DB Regio einfach weitere 6-teilige Desiro HC von Siemens nehmen. Das hätte man für den RE1 und RE19/29 einen einheitlichen Fuhrpark, was auch die Wartung erleichtert.

Im aktuellen Lok-Report 11/2024, der gerade ins Haus geflattert ist, steht drinnen, dass zum Ende diesen Jahres alle 6 Wendezug-Garnituren und alle 6 Loks der Baureihe 102 abgestellt werden sollen. Damit hatte diese Splitter-Gattung ein recht kurzes Leben.

Okay, dann ist es doch besser die aktuelle GUI-Grundstruktur der Mod zu übernehmen mit komplett eigenem Fenster.

Im übrigen tritt das Memory Leak auch bei pausiertem Spielstand auf, wie ich gerade ausprobiert habe. Liegt also dann wirklich sehr wahrscheinlich am Grafik-Interface.

Ich bin zwar ausgebildeter Fachinformatiker, hab aber seit 10 Jahren nicht mehr in der IT-Branche gearbeitet. Ich werde mich trotzdem mal an dem Projekt versuchen. Kann ich einen positiven Fußabdruck in der Community hinterlassen. Statt ein kompaktes GUI für die gesamte Mod wäre es mir aber lieber, wenn man zusätzlich in jedem Bahnhof einen eigenen Reiter "Fahrplan" hätte, wo man die Fahrpläne für jede Station einstellen kann. Ich würde zudem auch lieber die Vanilla-Linienübersicht verwenden und auf ein eigenes Fahrplan-GUI verzichten. Eventuell spart das auch wieder etwas Speicher ein. Macht die Mod natürlich dann stark von künftigen TPF2-Updates abhängig, wenn das Linien-GUI bzw. die dazugehörige API mal geändert wird.

Auf Github, siehe Link, gab es noch keine Rückmeldung. Sollte ich das Problem behoben bekommen, kann ich den Fix gerne per private Nachricht teilen. Veröffentlichen über die üblichen Kanäle geht ja ohne Zustimmung von Celmi ja nicht. Aber da in Github seit mehr als 2 Jahren niemand mehr Änderungen committed hat, scheint das ganze Projekt wohl eher verwaist zu sein. Es läuft wohl darauf hinaus die Mod komplett zu neu bauen. Natürlich kann man einzelne Codeschnipsel aus der alten Mod dafür verwenden. Ich glaube nicht, dass man dafür die Zustimmung der Autoren benötigt.

Zitat von eis_os

Im Endeffekt heißt das:

Alle LUA->SpielAPIs anschauen. Nutzung von temporären nur auf dem Stack liegende Objekte vermeiden.

api.bla(api.blub.new()) vermeiden und daraus:

local blub = api.blub.new()

api.bla(blub)

Ich habe den Code dieser Mod entsprechend modifiziert. Löst natürlich nicht das zugrundeliegende Problem. Aber eine Änderung hat sich ergeben. Die RAM-Auslastung steigt nicht mehr linear mit der Spielzeit. Man hat einen RAM-Anstieg für einige Minuten, bis eine Art Plateau erreicht wird und erst wenn man das GUI für die Fahrpläne öffnet, fängt das Spiel wieder an neuen RAM zu belegen. Allerdings geht der Anstieg auch dann weiter wenn das GUI gleich wieder geschlossen ist.

Ich vermute mal, dass ein Problem im Code vorliegt, der bei kleinen Änderungen an den Fahrplänen oder dem öffnen des GUI neue Fahrplan-Instanzen für sämtliche Züge und Stationen erzeugt ohne die alten Instanzen zu löschen. So wird der Speicher nach und nach mit LUA-Objekt-Instanzen zugemüllt. Aber alleine schon das Vorhandensein dieser Mod im Spielstand erhöht die RAM-Auslastung von ca. 15 GB auf über 40 GB nach dem Laden des Spielstandes.

Ich habe die Version 1.3 aus dem Steam Workshop. Ist identisch mit der verlinkten GitHub-Version.

Der Autor der Mod hat nicht reagiert bisher, daher mache ich mich jetzt mal ans Debuggen. Laut Kommentare im Steam Workshop scheint es nur die Linux-Version von TPF2 zu betreffen. Also kann es durchaus sein, dass nicht der Lua-Code von der Mod das Memory Leak verursacht sondern ein Aufruf in der API. Denn diese Mod greift direkt auf die API zu um Züge anzuhalten und wieder zu starten.

Was ich aber bisher herausgefunden habe, dass die Mod ziemlich viele TimeTable-Instanzen erzeugt. Eventuell liegt hier das Problem. Hat noch jemand Memory Leak-Probleme in Zusammenhang mit der API bemerkt? Yoshi  WernerK  VacuumTube  Celmi  DH-106