Vanhinten Timetables Testing- Der Info Faden

Du willst einen Stellwerksimulator, aber so funktioniert TPF2 halt nicht. Das ist halt eine komplett andere Herangehensweise, vielleicht kommt daher das Missverständnis.

Im Spiel gibts weder einen Schaffner, Fahrdienstleiter oder Stellwerk überhaupt. Züge agieren selbständig für sich. Sie planen ihre Route von Bahnhof zu Bahnhof. Sie fahren immer wenn frei ist. Sie reservieren den Weg vor sich bis zum nächsten Signal oder Bahnhof (an dem sie halten). Wenn der Bremswegabstand vor ihnen ein Signal erreicht, "meldet" sich der Zug an diesem Signal. Dann prüft das Signal ob der vom Zug geplante Weg bis zum nächsten Signal frei ist (nicht der Block, es gibt keine Blocksignale, nur Pfadsignale). Wenn ja schaltet es auf Grün und der Weg wird reserviert, wenn nein bremst der Zug. So gesehen stellt der Zug die Weichen.

Zitat von Capraio

ich glaube halt unerschütterlich an eure Fähigkeiten ...

glaub doch lieber das was wir sagen. Wenn es keine Schnittstelle gibt, ist es so.

Zitat von Capraio

Man müsste die Sache mal mit den Signalmoddern besprechen. Die bauen Signale die auf den Zustand der Blöcke mit Farbwechsel reagieren.

Signalmodder (wenn man es so nennen will) sind keine Scripter sondern bauen Modelle und setzen dann in den metadaten "signal=true". Die Signalbilder werden als Animationen definiert. D.h. nur das Spiel steuert intern diese Wechsel.

Zitat von Capraio

Ich sag nun nichts mehr zu diesem Thema

Ich glaubs irgendwie nicht

Zitat von eis_os

Und das mit der sauberen und dauerhaft verfügbare Lösung von api.* von UG ist auch so ne Sache für sich.

Es gibt einige wenige Bugs in der Api. Von denen ich einige gemeldet hab, die leider nicht alle gefixt sind.

Aber man muss ehrlicherweise sagen, dass 99% der api verlässlich funktionieren und Updatesicher sind. Ich greife mit Advanced Statistics auf nicht gerade wenig Funktionen zu und musste letztes Update 1 Zeile ändern.

Die Dokumentation ist halt an manchen Stellen sehr dürftig. Und für die alte api game.interface existiert keine. Das dumme ist nur, dass manche Sachen nur hiermit möglich sind. Jedenfalls muss man sich keine Sorgen machen, dass diese geändert/entfernt wird - die Kampagnen verlassen sich darauf.

Mein letzter Satz zu diesem Thema:

UG, ich finde es schade, lässt sich das nicht verwirklichen!!!

UG, die Arbeit der grossartigen Modder tragen zu eurem Erfolg bei!

Denkt daran!

Schluss.

[video]

[/video]

Zitat

Dieses Video zeigt die komplizierten Zugbewegungen im Bahnhof Haicheng, dem Abzweig der Haizwang Linie von der Peninsula Main Line, durch den Fahrplan geordnet. Das erste Mal mit Rail Route Streckenplänen.

In einem vordefinierten Fahrplan müsste man für jeden Zuglauf. Ein Zugumlauf definieren dann das entsprechende Rollmaterial hinterlegen. Zuerst für ein Tag mit 24 Stunden und für eine Woche. Falls man am Samstag und Sonntag mit dem alten Rollmaterial unterwegs sein möchte.

Der nächste wünsch wäre Signale mit entsprechenden streckenbezogen Fahrweggeschwindigkeit in den Bahnhof bzw. auf die Strecke und dazu die passenden Vorsignal Bilder.

Um das Umzusetzen zu können müsste man ein neues Programm Schreiben. Und für die das möchten würde dann erweiterte Version verkauft.

Zitat

Der nächste wünsch wäre Signale mit entsprechenden streckenbezogen Fahrweggeschwindigkeit in den Bahnhof bzw. auf die Strecke und dazu die passenden Vorsignal Bilder.

Das wäre schon sinnvoll, aber nicht ganz einfach zu programmieren. Vor allem die Signalbilder, weil sie von Land zu Land unterschiedlich sind. Es gibt ja auch noch Dunkelschaltung usw. Aber wo wir schon beim Wünschen sind: Schön wäre es auch, wenn es echte Selbstblocksignale mit Grundstellung Fahrt gäbe.

Je nach Land gibt es im grossen und ganzen meines Wissens Nach eine Kombination von Zwei Signalsystemen: "Geschwindigkeitsbilder", wo das Signal sagt wie schnell du jetzt fahren darfst und "Blockbilder", wo das Signal zeigt, was das nächste Signal zeigt... (Ich hab keine Ahnung wie das professionell heisst, daher die Anführungszeichen)

Blockbilder sind von der Logik her wahrscheinlich relativ einfach, da sie "nur" eine Verknüpfung zum nächsten Signal auf der Strecke brauchen (Die müsste wahrscheinlich UG zur Verfügung stellen und daraus könnte man sich das Bild ableiten.

Geschwindigkeitsbilder sind da schon schwieriger, da sie eine Geschwindigkeitsbegrenzung von einem Signal zum nächsten (und Teilweise bis zu einer gewissen Stelle im Gleis, aber da könnte man einfach ein fakesignal hinstellen) erstellen. Da müsste zum einen der Zug seine Höchstgeschwindigkeit und die erlaubte Geschwindigkeit kennen (Der Parameter existiert sicher irgendwo, da die Gleise mit ihrer Höchstgeschwindigkeit schon einen ähnlichen Effekt haben) und dann irgendwie dem Signal kommunizieren, mit welcher Geschwindigkeit er wohin vorbeifahren will, woraufhin das Signal ihm eine Höchstgeschwindigkeit auferlegt, die bis zum nächsten Signal nicht überschritten werden und alle gültigen Infrastrukturbedingten Geschwindigkeitsbeschränkungen nicht übertreffen darf. Da der Zug aber noch bis zum Signal auf ein gültiges Signalbild herunterbremsen können muss, stell ich mir diese Evaluation programmiertechnisch am schwierigsten vor.

Bei allen Systemen kommt noch dazu, dass man typischerweise Freie Fahrt und Langsamfahrt zeigen können will, aber das kann der Modder wahrscheinlich mithilfe der anzeigbaren Geschwindigkeiten lösen.

Je nach Signalsystem kommt dann noch das Vorsignal hinzu, welches eine Funktion benötigt, ein Geistersignal zu sein, also auf das nächste Signal und seine Geschwindigkeitsvorwahl zuzugreifen, ohne selber unbedingt ein Signal zu sein...

Gewisse Signalsysteme haben auch noch weitere Hinweise, wie die Weichenlagen (sodass man erkennen kann wo man hingeleitet wird), aber die sähe ich als relativ unmachbar.

Meine Hypothese ist, dass Blockbilder theoretisch machbar sein sollten, wenn man das Signalsystem von UG unter die Lupe bekäme und der Grünschaltung folgt bis man zum Fahrweg des Zuges kommt und entlang diesem weitere Signale findet. Aber so tief in den UG Code kommt man wahrscheinlich als modder nicht rein. Und für die änderung der Signalbilder müsste man wahrscheinlich auch noch einen Signalersetzer schreiben, der fortlaufend vor jedem Zug jedes Signal ersetzt gegen eines, welches das erwünschte Signalbild als "grün" hat...

Alles andere kannste gleich knicken. Es sei denn UG kann die benötigten Variabeln in eine API packen...

Ein Fahrplan Tool wo nicht von Anfang nicht alle abschreckt, ist kein leichtes unterfangen zu entwickeln. Wenn die Eingabemasken selbsterklärend wirken sollen.

Ich habe mir mal das hier unten angesehen auf der Seite von LOTUS Simulator.

Fahrpläne erstellen mit LOTUS

Was mir dort fehlt, ist eine Grafischer Aufarbeitung der Zeit-Weg Übersicht von Eisenbahnstrecken um Konflikte so zu erkennen. Für so etwas müsste UG sehr viel offen legen und anpassen.

Auf der andre Seite haben es die ARTDINK Entwickler aus Japan mit ihrem A-Train auch geschafft. Dass man dort Züge trennen und vereinigen kann wie auch umfahren kann. Auch eine Drehscheibensteuerung ist in den Fahrplan mit integriert. Wenn man die Filme von ihnen ansieht. Hier in Europa könnte man so die wechsel Funktion E- Diselbetrieb von Loks und Triebwagen so simuliert werden. Bzw. der Trolleybus fahrt ein kurzes Stück ohne Fahrdraht z.B. Strassenbaustellen oder zur Endstation.

An und für sich verschenkt ihr UG Potenzial wie auch in der Immobilienentwicklung.

Also bei mir funktioniert die Mod leider nicht. Ich habe die andere Timetable Mod installiert und wollte mal gucken was diese besser oder schlechter macht, aber weder in einem gespeicherten Spielstand noch in einem neuen Spiel ist vanhinten's Timetable aktiviert.

Es steht auch in der Modliste das sie wohl veraltet wäre. Hab Ich da irgendwas übersehen???

Den richtigen Ordner (vanhinten_timetables_04_1) ins Modverzeichnis geschoben?

Natürlich .......................................... Nicht!!!

Danke . Werd es dann morgen mal antesten, schade ist nur das ich ein neues Spiel starten muss da mein savegame abstürzt wenn ich die Mod hinzufüge.

Nachtrag zum absturz beim hinzufügen in ein savegame

Ich verstehe bis heute nicht, was diese Mod macht, und wofür sie gut sein soll. Wenn ich mir die Kommentare so durchlese, bin ich nicht der Einzige. Und stabil scheint sie nie gewesen zu sein.

Das Problem ist, dass sie nicht wirklich gut beschrieben wurde bzw. die Unterschiede zur bekannten Timetable Mod erklärt wurden. Deshalb haben nur wenige sie ausprobiert (für die meisten ist eine Fahrplanmod überfordernd genug). Daher gibt es eben auch nur wenige (aussagekräftige) Testberichte. Ich hab mir es auch nie genauer angeschaut.

D.h. nicht, dass die Mod schlecht ist, wir können es einfach aktuell nur nicht bewerten.

Ich finde die Fehlermeldung und manche Bezeichnungen im Code amüsant...

Es kommt zu einem Lua Fehler den er aber erstmal abfängt. Und nach mehreren Versuchen, Informationen zu den Linien Stops auszulesen, wirft er selbst einen Fehler ("Der kakk Bug geht ned weg").

Davor in der stdout müsste was relevantes stehen (debugPrint(ug_stops))

Leider können wir durch das Abfangen nicht die originale Fehlermeldung sehen.

Ich sehe direktes Indizieren von getComponent:

 api.engine.getComponent(id, api.type.ComponentType.LINE).stops

Das ist gefährlich! Siehe dazu diese Info, die ich mal von UG bekommen habe.

Man kann ihm keine Schuld geben, sondern UG, da das nirgendwo dokumentiert ist.

Ich bin mir gerade aber nicht ganz sicher, ob das den Fehler verursachen könnte, da er ihn mit pcall abfangen kann. Ich meine es kam in diesem Fall zu einem "Error occured", welche man Lua seitig glaub ich nicht fangen kann.

Er hat auch Probleme den Linien Typ (Carrier) zu bestimmen. Vielleicht hätte er gern gewusst, dass das (wie manche andere Sachen) mit der alten Api game.interface viel einfacher geht.

Zitat von OpenSource

Ich würde diese Modifikation aber nicht mehr testen, bringt nicht mehr wirklich was und ich bin mir auch nicht sicher ob das noch so halbwegs funktionieren kann mit der aktuellen Version von Transport Fever 2.

Heißt das der Mod funktioniert nicht in der aktuellen Version und du willst nichts mehr dran machen? Dann wäre es gut wenn du den Webdiskeintrag entweder löscht oder eine entsprechende Bemerkung drantackerst das der nicht geht und nicht mehr weiterentwickelt wird (ggf auch hier am Thread).

Einen neuen Webdsikeintrag erstellen falls sich was ändert geht ja immer.

Zitat

Manchmal kam da tatsächlich ein Array das aber fälschlicherweise leer war. Manchmal kam da ein Array das auch Sinn machte welches aber paar Zeilen Code weiter wieder leer war.

Sieht in der Tat nach dem Garbage-Collection-Problem aus. Bestimmte Userdata-Strukturen der API (ich schreibe bewusst nicht Tabellen) werden nach einer gewissen Zeit "abgetötet", wenn sie nicht mehr vom Hauptprogramm benötigt werden, um im Speicher Platz für neue Daten zu schaffen. Wenn du auf so eine Struktur zugreifst, enthält die Variable dieser Struktur lediglich einen Zeiger auf deren Speicherbereich. Ist die Struktur gelöscht, kann an dieser Stelle plötzlich Datenmüll stehen bzw. irgendwelche neuen Daten. Nicht nur das: Auch, wenn du die Variable in andere Variablen übernommen hast, ist und bleibt es immer noch derselbe Zeiger, und dein Problem bleibt erhalten - sogar, wenn du die Variable als lokale Variable in eine Funktion übernimmst! Um das zu verhindern, musst du die Inhalte der Struktur Parameter für Parameter in eine echte Tabelle kopieren, die du selber angelegt hast, und die somit "Eigentum" deiner Mod ist. Du kannst das mit vielen vielen Zeilen "von Hand" machen, aber es gibt auch nette Hilfsprogramme hierzu. Vacuum Tube hat sowas mal geschrieben, ich weiß aber nicht, ob es zur offiziellen Benutzung freigegeben ist.

Was nicht heißt, dass dieses Prozedere jetzt bei jeder getComponent-Abfrage notwendig wäre. Genaue Regeln habe ich auch noch nicht herausgefunden.

Zitat von OpenSource

Die "Info" hatte ich aber schon damals gelesen, und auch ausprobiert. Ergebnis war das gleiche, somit flog das wieder raus.

Du verhinderst damit aber seltene, zufällige, also unerklärliche, nicht reproduzierbare Abstürze.

Zitat von OpenSource

Da kam von der Api manchmal wirklich Müll. Manchmal kam da tatsächlich ein Array das aber fälschlicherweise leer war. Manchmal kam da ein Array das auch Sinn machte welches aber paar Zeilen Code weiter wieder leer war. Und ich weiß nicht mehr was noch alles, ganz schlimm jedenfalls.

Kann gut sein. Ich habe auch schon meine Erfahrungen mit der Api im userdata Universum gemacht. Da passieren teilweise Sachen, die man beim besten Willen nicht erklären kann. Und man muss sich stundenlang mit trial und error dem Problem annähern.

Wenn du aber wirklich nach einer Lösung suchst oder zumindest dass das Problem bekannt wird, dann sag doch um welche Funktion genau es geht. Das hätte man ja auch damals hier im Forum einfach fragen können.

Zitat von WernerK

Bestimmte Userdata-Strukturen der API werden nach einer gewissen Zeit "abgetötet"

Problematisch wirds weil userdata kein unabhängiges Standard Lua ist, sondern direkt auf Objekte im normalen Speicher zeigt. Es ist alles andere als Tabellen. Wie sich das mit der Lebensdauer verhält weiß keiner so genau, nicht mal UG. Siehe der genannte Bug. Außerdem wurde mir mal gesagt, bitte versuche nicht die Objekte von getComponent schreibend zu benutzen (ich glaub es macht aber nichts). Es gibt leider keine Informationen, wie man mit userdata umgehen sollte.

Das habe ich bei Build with Collision bemerkt. Hier war es während der guiEvents. Beim Callback der Lua Funktion war alles super mit dem param Element (userdata der proposal Daten). Schreibt man aber p=param und will sich dann p in der Konsole anschauen, wird man teilweise mit "Error occured" verabschiedet.

Daher habe ich mir copy_userdata geschrieben.

Damit funktionierte in der 1.1 auch der bulldozer sowie das Upgraden ohne dass man noch auf dem Segment sein musste.

https://github.com/Vacuum-Tube…ld_with_collision.lua#L91

[OT] Irgendwo hab ich sogar ein Skript gesehen, wo vor einer kritischen Operation eine Garbage-Collection per Lua-Befehl erzwungen wurde, offensichtlich, um der Automatik zuvorzukommen. Ob das aber eine wirkliche Alternative ist und Einfluss auf Userdata-Bereiche hat - keine Ahnung.

Wo es bei mir schon einmal nach getComponent gerummst hat, war die Abfrage von Userdata, nachdem ich zuvor eine längere debugPrint-Ausgabe getätigt hatte.

Ein Userdata via sol API ist nur ein Pointer und darf niemals über die Funktionsgrenze der game_script callbacks weiter bestehen. Es ist möglich das sich ein Speicher Pointer zu Daten einer Entity ändern, bzw. in den jeweiligen Systemen.

Gerade Daten, die als Pointer zu weiteren Strukturen in einem Entity Component gespeichert werden sind da mehr betroffen. sol2 ist auch nicht gut darin, verschachtelte Daten bzw. Referenzen aufzulösen, wenn die Daten noch LUA "gehören" und nicht gespeichert sind.

Beispiel:

Man erstellt ein Objekt via api, speichert aber dazu keine Referenz via Userdata, sondern nutzt nur direkt eine verschaltet Struktur.

erstelleObj().irgendwas.bla

(Hierbei kann UserData<obj> von erstelleObj() ggf. schon wieder freigegeben werden, obwohl UserData<irgendwas> noch einen Pointer auf obj hält, um obj.irgendwas auszulesen)

vs.

obj = erstelleObj()

obj.irgendwas.bla

Solange Userdata<obj> im Scope ist, kann UserData<irgendwas> noch benutzt werden.

Sie können oder wollen mir nicht sagen wie Sie Ihre States syncen, sprich was passiert wenn die GUI noch läuft (weil sie viel zu tun hat), aber die beidem Daten der ecs::Engines im GameThread gesynct werden.