Fahrzeugantrieb-dll

[F. Schn.]

Hi,

zum Zusi-Treffen hat Carsten die Fahrzeugantrieb-dll vorgestellt. Die Folien sind jetzt hier abgelegt: viewtopic.php?p=349368#p349368

Ich bin die Folien noch mal durchgegangen, und wollte jetzt zu dem Thema noch mal was anreißen.

Daher habe ich mal hier ein allgemeines Thema zur Fahrzeugantrieb-dll aufgemacht.

Zur Frage:
Zur procedure VorspanntraktionsdatenSetzen(speed, leistung) steht da:
// wird für Fahrzeuge einmal pro Rechenschritt aufgerufen, die im eigenen
// Zug im Modus "eigener Tf" fahren und für alle Fahrzeuge im Autopilotmodus
Das heißt, diese Methode wird für verschiedene Fahrzeuge aufgerufen, die jeweils dieses Antriebsmodell besitzen.

Wie genau kann ich jetzt bestimmen, für welches Fahrzeug diese Methode aufgerufen wird?
Im weiteren Verlauf der Beschreibung steht ja sogar geschrieben, dass es sehr performant seien muss. Für eine große Performance wäre es ja eher schlecht, wenn ich z.B. eine Zugnummer und einen Index bekomme. Ich habe ja im Regelfall eine Klasseninstanz, in der irgendwelche Daten gespeichert werden. Das heißt, ich müsste Zugnummer und Index erst mal in einem Dictionary/HashTable/... auf meine Klasseninsatz übersetzen.
Besser wäre es, wenn Zusi das Fahrzeug bei der DLL anmeldet, und ich Zusi dann einen Pointer zu meiner Klasse gebe. Und Zusi gibt diesen Pointer dann der procedure VorspanntraktionsdatenSetzen mit, und ich kann den Pointer dann direkt in der procedure VorspanntraktionsdatenSetzen dereferenzieren, ohne irgendwas nachschlagen zu müssen.

Hast du das Thema auf dem Schirm, Carsten? Thema ist in Version 3.4.5.1 berücksichtigt worden.

[Wolfgang E.]

Ich konnte ja leider nicht bei dem Treffen dabei sein, so dass ich nur die Folien gesehen habe.

Dort ist die Rede von einem Demo-Sourcecode für die Antriebs-DLL. Kommt der noch, oder habe ich den jetzt nur übersehen?

Viele Grüße Wolfgang

[Carsten Hölscher]

Über die Verwaltung ist jetzt ein erster Testumfang verfügbar (exe als beta und ein kleines Paket unter "weiteres"), der sich an diejenigen richtet, die selbst dlls programmieren wollen. Für alle anderen ist es irrelevant.
Als Einleitung sollte man sich einmal die Folien zum Zusitreffen anschauen.

Es wird sicherlich noch nicht alles gehen und es dürften auch noch ein paar Ausgabewerte fehlen.
Aber das grundlegende sollte funktionieren.
Zu testen wären u.a. die verschiedenen Fälle (Fahrzeug an der Spitze, weiter hinten als Mehrfachtraktion und mit eigenem Tf), jeweils manuell gefahren und Autopilot.
Hab das auch noch nicht alles durchgespielt mit dem Testfahrzeug.

Carsten

[F. Schn.]

Hi,

das ging aber schnell.

Ich habe aber noch Probleme mit dem Fzg-Editor:
Ich bekomme in der 64-Bit-Version die DLLs im Fzg-Editor nicht zum laufen. Er zeigt weder den Varianten-Knopf noch den Einstellungs-Dialog an.
(Die 32-Bit-Version hatte zwar zunächst auch Probleme gemacht, aber das lag an mir. (Hätte mir klar sein müssen, dass die nie benutzt und daher völlig ungeupdated war...) )
Im Simulator (64) scheint auf den ersten Blick erst mal alles zu gehen.

Eigene Test-DLLs kann ich vmtl. erst übernächste Woche anfangen zu schreiben.

NB Kleinkram:
Ich würde als Ordner eher RollingStock\_Docu vorschlagen, weil die Streckenbau-Tutorials auch unter Timetable\_Docu sind, nicht unter _Docu\Timetable

[F. Schn.]

Okay, doch nicht so ganz... Ich habe mir eine Zwangsbremsung "1000 Hz-Überwachung (max. 45 km/h)" eingefangen, und das wurde mit einer Nulligen Zugriffsverletzung quitiert.

[Wolfgang E.]

Die Beispiel-DLL ist in fahrzeugdll_demo1.za7? Das wird bei mir trotz der installierten Beta-Versionen vom Fahrzeugeditor (3.5.4.1), Simulator (3.5.4.1) und Dateiverwaltung (3.5.5.1) als nicht passend zur Installation angezeigt. Mache ich was falsch?

Viele Grüße Wolfgang

[F. Schn.]

Nachdem das bei der 64-Bit-Version ja genauso war, geht Carsten sicherlich davon aus, dass wir Programmierer schon wissen, was wir tun und es einfach manuell herunter laden.

[JuRa]

In der 64-Bit Version des Fahrzeug Editors stimmt in der Tat etwas nicht. Es klappt aber mit einigen Kniffen:

Stutzig gemacht hat mich, dass es nicht Möglich war, im Fahrzeug-Editor die "Demodll_Antrieb.64.dll" auszuwählen. Tut man es, bekommt man im Fenster trotz dem die "Demodll_Antrieb.dll" angezeigt. Es ist auch nicht Möglich, die Variante einzustellen. Erst wenn man händisch den Dateinamen mit .64 ergänzt. Man kann jetzt zwar die Variante einstellen, jedoch meckert der Editor dann, dass die Datei "Demodll_Antrieb.64.64.dll" nicht gefunden wird. Abhilfe: die "Demodll_Antrieb.64.dll" im Explorer kopieren und zusätzlich eine "Demodll_Antrieb.64.64.dll" herstellen.

Damit geht dann auch etwas in der 64-Bit-Sim, jedoch nach kurzer Zeit:

und das wurde mit einer Nulligen Zugriffsverletzung quitiert.

Das passiert nicht nur bei der erwähnten Zwangsbremsung, bei mir nach kurzer Fahrt.

Habe inzwischen auch den Source-Code fehlerfrei in 32Bit und 64Bit compilieren können. Das mit Delphi 10.4 Community Edition. Mit welchen Editoren arbeitet ihr. Ist es sinnvoll, diesbezüglich eine einheitliche Basis (Editor) zu haben. Ich liebäugel ja mit dem freien Programm Lazarus, da Embarcadero die Community Edition immer nur für ein Jahr freischaltet - wer weis wie lange noch. Habe jedoch bis auf einige wenige Beispielanwendung noch keine Erfahrung damit.

Gruß
Jürgen

[Carsten Hölscher]

Am Ende des Tage sollen die Demodateien mal in das Installationsverzeichnis neben die TCP-Demos. Darauf ist die Struktur schon vorbereitet.
Die ".64" wird immer rausgefiltert und von der 64-bit-Version bei Anwendung wieder intern reingepackt. Ich schau mal, wo es da noch hakt.
Könnte mal wer einen Fahrplan schicken, bei dem es abstürzt?

Ich hatte ja in Braunschweig schon angeregt, das wir eine gemeinsame Codebasis erstellen, aus der man dann ein konkretes Fahrzeug ableiten kann. In der Demo sind dafür ja schon entsprechende Klassen angelegt. Daraus könnte man sowas entwickeln.

Carsten

[F. Schn.]

Leider gerade nicht downloadfähig da, aber: Streckenbaututorial die Demo-Lok als Vorspannlok vor die Üg hängen und sich dann bei 45 km/h eine Zwangsbremsung einfangen.

[JuRa]

Habe noch mal alles auf Anfang gesetzt.

Den Absturz sofort nach Fahrbeginn kann ich zwar nicht mehr nachvollziehen, jedoch jegliche Zwangsbremsung - auch Sifa - beschert der Sim ein Ende.

Kleiner Testfahrplan ist per Mail unterwegs.

Gruß
Jürgen

[Carsten Hölscher]

Hab beide Abstürze behoben (einer im Sim, einer in der dll bei Rückwärtsfahrt, da schlägt das sqrt() natürlich fehl).

Carsten

[lipkegu]

Wird der Autopilot dann in der Lage sein, durch eine Antriebs-DLL auch Hebel und Schalter zu nutzen? Momentan kann er das ja noch nicht

[Thomas U.]

Welchen sinnvollen Mehrwert hätte das für den Spieler, wenn der Autopilot das könnte?

[HaraldB]

Wird der Autopilot dann in der Lage sein, durch eine Antriebs-DLL auch Hebel und Schalter zu nutzen? Momentan kann er das ja noch nicht

Nein, dafür ist die Schnittstelle nicht vorgesehen. Es geht m.E. darum. die Physik spezieller Fahrzeuge auf spezielle Weise zu berechnen.
Der Autopilot stellt nur Zugkraft, im einfachsten Fall nur Beschleunigung.

Die Antriebs-DLL sollte keine direkte Rückwirkung auf die Bedienelemente im Führerstand haben.
Force Feedback bei der Eisenbahn gibt Aufschrei, würde ich vermuten. Schon die Sprachausgabe "Störung" dürfte noch mehr Schreikrämpfe auslösen als jedes Navi im Auto. Ganz zu schweigen von "Zuck-B Ein-Flussung".

Edith meint: Bei Dampfloks wäre es aber vorstellbar, dass Fehlbedienungen mit einem wüstem Ruck am Hebel quittiert werden.

Welchen sinnvollen Mehrwert hätte das für den Spieler, wenn der Autopilot das könnte?

Dann wäre er bester Fahrlehrer der Welt. Fast.
Jedenfalls hätte es mehr Realismus, wenn der AP an die diskreten Steuerelemente gebunden wäre und z.B. beim Bremsen eines Gz "einen" raus lassen muss.

[F(R)S-Bauer]

Hallo,

also in Zusi 2 hat dieses Konzept sehr viel Probleme gemacht. Die Fahrplanbauer konnten ein Lied davon singen und AFB am Autopilot war nie ganz fehlerfrei, sodass es am Ende abgeklemmt wurde.
Und damals war das Streckennetz und die Fahrpläne wesentlich begrenzter.

Gut, nun war das Ganze in Zusi 2 komplett anders umgesetzt, aber ich trauere diese Funktion nun wirklich nicht nach.

Gruß

Ralf

[Wolfgang E.]

Die Bedienung durch den Autopiloten in Zusi2 ist ja eher ruppig. So sollte niemand fahren.

Was dem Zusi3-Autopiloten fehlt, ist die Möglichkeit sich bei der PZB90 aus der Überwachung zu befreien. Deswegen schleicht er den ganzen Überwachungsweg. Aber das hat ja nichts mit dem Antrieb zu tun und man muss die Autopilotfunktion auch von dem selbstständigen Fahren der nicht gespielten Fahrzeuge unterscheiden.

Viele Grüße Wolfgang

[jonathanp]

Ich habe die Schnittstelle in C++ übersetzt(*) und eine DLL geschrieben(Download), mit der ich erfolgreich fahren konnte - super
Sie ist noch einfacher als die mitgelieferte Demo, schreibt aber eine Log-Datei, um die Eingaben von Zusi anzuzeigen.

Was mir aufgefallen ist:

• Der 64-Bit-Fahrzeug-Editor lädt genau die angegebene DLL, ohne 64-Bit-Suffix, aber der Fahrsimulator fügt das Suffix hinzu. Um also mit der aktuellen Version erfolgreich zu sein, muss die 32-Bit-DLL tatsächlich eine Kopie der 64-Bit-Version sein.
• Für Nicht-Delphi-Sprachen wäre es hilfreich, wenn die Enums die Größe 4 hätten(*Der grund, warum es als C++ und nicht C zählt)
• Wenn ein Fahrplan geladen wird, wird VarianteAktivieren sofort für jedes Fahrzeug in der Simulation aufgerufen, aber wenn der Benutzer einen Zug auswählt und die Simulation tatsächlich startet, wird es erneut aufgerufen, und die erste Instanzgruppe wird nicht verwendet.
• Entweder eine VarianteDeaktivieren(Instanz: Pointer) Funktion pro Fahrzeug oder ein globales Zuruecksetzen(), das immer dann aufgerufen wird, wenn ein neuer Fahrplan geladen wird, ist notwendig, da sonst alle in VarianteAktivieren pro Fahrzeug zugewiesenen Ressourcen nicht freigegeben werden können und immer weiter wachsen werden bis der Fahrsimulator endgültig geschlossen wird.

[lipkegu]

Welchen sinnvollen Mehrwert hätte das für den Spieler, wenn der Autopilot das könnte?

Weil der Autopilot, nicht das antriebsmodel, der Lok verwendet. Wenn der Autopilot das Antriebsmodel der Tfz kennt, so könnte man die Schalter syncronisieren.
oder auch wenn man zb Mühlheim - Veddel mit dem ICE 888 beginnt, da liegen die Fahrschalter auch auf 0% obwohl er fährt.

Ich denke mal das könnte man allgemein lösen, indem man aktuelle aufgeschaltete Fahrstellung der Hebel, mit den Hebeln syncronisiert.
Wenn Jedes Tfz, solch dynamisches Antriebsmodel hat, dann wäre es ja problemlos möglich, das anzugleichen.

viewtopic.php?p=342245#p342245

[F. Schn.]

Welchen sinnvollen Mehrwert hätte das für den Spieler, wenn der Autopilot das könnte?

Sinnvolle Soundkulisse, sowohl bei Fahrten mit Autopilot als auch bei Fahrzeugen mit geöffneten Fenstern oder schlecht gedämmten Fenstern im 3D-Sound; sowie nahtlos(ere) Übernahmen von und zum Autopilot.

Ich würde das aber soherum angehen, dass der Autopilot aus dem vereinfachten Antriebsmodell eine Schalterstellung zurückrechnet, nicht so, dass der Autopilot mit vollem Antriebsmodell rechnet.