Zusi-Forum

Carsten Hölscher hat geschrieben: ↑24.08.2022 00:06:00 Könnte mal jemand ein Video vorher/nacher machen? Ich finde im Moment keinen Unterschied.

Hier ist es zu sehen: https://youtu.be/NNIFw8Ce5L8
Zuerst das Verhalten im 3D-Editor 3.4.5, dann in der Beta 3.5, beide Male mit Strg + rechte Maustaste und mit der Maus nach links und rechts bewegen.

An diesen Thread anknüpfend möchte ich noch erwähnen, dass sich Zusi 3.5 die Verzeichnisse nicht mehr korrekt merkt wie in Zusi 3.4.

Beispiel:
Objektimport Drag&Drop -> Neue Datei hinzufügen -> "Terrain\General\Trees\Beech\Beech01-15m.lod.ls3" aus dem offiziellen Datenverzeichnis auswählen (das Verzeichnis "Terrain\General\Trees\Beech" darf nicht im eigenen Datenverzeichnis existieren)

Nochmal neue Datei (im Objektimport) hinzufügen:
In Zusi 3.4 öffnet sich jetzt das Verzeichnis "Terrain\General\Trees\Beech", so wie es sein sollte.
In Zusi 3.5 öffnet sich dagegen das Stammverzeichnis im eigene Datenverzeichnis (mit den Ordner Routes, Terrain etc.). Wenn man jetzt auf Abbrechen drückt und zum dritten mal auf neue Datei hinzufügen geht, dann öffnet sich das Verzeichnis "Terrain\General\Trees\Beech"


Zusi 3.5 kehrt also erst wieder ins gemerkte Verzeichnis zurück, wenn man den Vorgang einmal abgebrochen hat...

Wenn man Dateien aus dem eigenen Datenverzeichnis aufruft, passiert das übrigens nicht. Dann springt er sofort wieder ins gemerkte Verzeichnis (wie in 3.4).

Hallo!

Zusi 3.5 kehrt also erst wieder ins gemerkte Verzeichnis zurück, wenn man den Vorgang einmal abgebrochen hat...

Das Verhalten hatte ich immer schon in Zusi 3.4 - und auch jetzt in 3.5.

Markus

Hat eigentlich schon jemand mal die Englische Spracheinstellung probiert? Oder wurde vielleicht irgendwo sogar schon etwas dazu geschrieben und ich hab's vergessen und nicht wieder gefunden?

Warum ich nachfrage: Ich habe wegen des Themas drüben versucht, Zusi auf Englisch umzustellen, aber lediglich die Intro-Datei hat da mitgemacht, das Menü war nach wie vor Englisch. Mit der 3.4 geht's.

Ja, ich war davon ausgegangen, dass das einfach noch nicht implementiert ist und hatte nichts geschrieben. Aber bei mir ist auch alles auf Deutsch trotz englischer Spracheinstellung.

Ich habe ein ziemlich dubioses Problem gefunden: Und zwar stelle ich auf der Bremsenteststrecke Bremswegverlängerungen fest, die zwischen Version 3.4.99.20 und .22 reingekommen sind. In den alten Zusi-Versionen kommt mein Testwagen mit KE-GPR-Klotzbremse nach 640 Meter zum Stillstand. Ab Version 3.4.99.22 oder neuer erst nach 710 Meter. Es tritt sowohl im 32- als auch 64-Bit-Simulator auf. Die im Fehlersuchfenster ausgewiesene Bremsklotzkraft ist gleich.

Tritt das in allen Bremsstellungen auf?

Carsten

Wenn man sowas hat, fängt man an alles zu hinterfragen. Dadurch wurde alles noch viel merkwürdiger. Es gibt bei der KE-GPR-Klotzbremse keinen Unterschied im Bremsweg zwischen den Bremsstellungen P und R. Und die Kurve "Faktor Bremsenkennung" aus dem Fahrzeugeditor hat auch keinerlei Wirkung. Ich hätte erwartet, dass diese Kurve eine geschwindigkeitsabhängige Änderung der Bremskraft bewirkt. Stattdessen ist die Kraft während der gesamten Bremsfahrt konstant. Das ist auch nicht erst seit Version 3.4.99.22 so, sondern schon länger. Ich kann noch bis Version 3.4.0.0 zurückgehen. Auch dort ist kein Unterschied zwischen Bremsstellung P und R. Unter diesen Umständen fange ich echt an, an mir zu zweifeln...

Also ich sehe folgende Bremswege bei meinem Testwagen:
Version 3.4.99.20 und 3.4.0.0:
G: 720 Meter
P: 670 Meter
R: 670 Meter

Version 3.4.99.22 und 3.4.99.37:
G: 770 Meter
P: 710 Meter
R: 710 Meter

Alwin Meschede hat geschrieben: ↑21.10.2022 09:20:51 Wenn man sowas hat, fängt man an alles zu hinterfragen. Dadurch wurde alles noch viel merkwürdiger. Es gibt bei der KE-GPR-Klotzbremse keinen Unterschied im Bremsweg zwischen den Bremsstellungen P und R. Und die Kurve "Faktor Bremsenkennung" aus dem Fahrzeugeditor hat auch keinerlei Wirkung. Ich hätte erwartet, dass diese Kurve eine geschwindigkeitsabhängige Änderung der Bremskraft bewirkt. Stattdessen ist die Kraft während der gesamten Bremsfahrt konstant. Das ist auch nicht erst seit Version 3.4.99.22 so, sondern schon länger. Ich kann noch bis Version 3.4.0.0 zurückgehen. [...]

Hallo Alwin,
der letzt zitierte Satz hat mich aufhorchen lassen. Drum frage ich aus reiner Neugier: Hat sich diese Geschichte eigentlich inzwischen geklärt, und wenn ja, wie?

Grüße, Gerald

Folgender Sachstand zu 3.5-EInführung:
- Es gibt noch etliche kleinere Fehlermeldungen die ich mir anschauen muss, hab dazu auch etliche Forenbeiträge vorgemerkt, die ich abarbeiten muss (hab die letzten Wochen aber erstmal andere Themen an der backe gehabt), dazu wird es noch ein paar beta-Versionen geben.
- Der Umbau des Gleisplaneditors durch Jens ist noch nicht kurz vor der Fertigstellung.
- Die dlls für Buchfahrplan usw. stehen auf neuer .NET-Basis vor der Tür.

Ziel war ja, das alte .NET-Gerümpel loszuwerden, was MS zunehmend weniger unterstützt. Das geht vollständig aber erst mit dem neuen Gleisplaneditor.

Folgenden Plan habe ich jetzt: Das neue 3.5-Setup kommt erstmal ohne den neuen Gleisplaneditor, stattdessen gibt eine Gleisplaneditor-exe als Dummy. Damit ist das normale Setup allein auf neuerem .NET unterwegs.
Wer den Gleisplaneditor braucht, kann die bisherige Version mit einem kleinen Zusatzsetup dazu installieren. Sobald es ihn dann in der 3.5er Version gibt, kann die Dummy-exe mit er ganz normalen Update-Funktion auf die neue Version gebracht werden.

Das nächste Paket werden Stefan und ich dann parallel angehen. ich denke, wir verschaffen uns in den nächsten Tagen mal einen Überblick und können dann einen Plan zu den Einreichungsterminen machen. Mehr dazu dann in eigenem Thema.

Carsten

Hab Alwins Bremsfahrplan inzwischen getestet, bei mir kommt (über die Zugvorgabe im Fahrplan eingestellt) raus mit meinem aktuellen Entwicklungsstand:
G ca. 900m
P ca. 700m
R ca. 450m

Auch der Reibwert wird m.E. korrekt reingerechnet (das hatte ich die Tage in anderem Zusammenhang schon durchgecheckt.)
Konkret hab ich da in der ketzten Zeit aber auch nichts geändert.

Carsten

Frage an die .NET-Experten - bislang rief der Gleisplaneditor die Funktionen der in Win32 erstellten z3strbie.dll auf wie unten zu sehen. MIt der Umstellung will er die neue z3strbie.dll nicht mehr und stürzt beim Ausführen der Funktion TempSpeichern_st3 mit Nullpointer ab. Tauscht man gegen die alte dll, geht's. Ich könnte für die Übergangsphase der Weiternutzung des alten Gleisplaneditors einfach die alte dll umbenennen und weiternutzen, aber vielleicht hat ja wer ne Idee, warum die neue dll nicht läuft? Carsten

Das klingt so, als sei die DLL Schuld. Können wir das irgendwie mit der aktuellen z3strbie.dll Version 3.4.99.21 testen? Wie wird denn die Funktion in der DLL exportiert? Verwendet die DLL einen Nullterminierten ANSI-String, wie durch LPStr angegeben, oder einen anderen String wie z.B. LPWStr (UTF16/0) oder BStr (UTF16/Prefix)? Hier hat es ja wenn ich mich richtig erinnere mit der neuen Delphi-Version Änderungen am Delphi-Internen Stringdatentyp gegeben.

Wild guess, aber könnte es sein, dass das Stack alignment der string pointer nicht passt? Also die 64bit DLL erwartet insgesamt 128 bit als Funktionsinput und der Gleisplaneditor spuckt aber 2*32 bit Pointer aus (64bit) und dadurch ist eins der Argumente null.

So sieht das in der dll aus:
Wir reden erstmal nur von der 32bit-Welt.

Carsten

Sieht erst mal gut aus. Was für ein Nullpointer ist es denn? Eine .Net Nullreference-Exception, eine native SIGSEGV, eine .Net AccessViolationException oder etwas anderes?

Edit: Nachtrag: Es gab ja mal in der Buchfahrplan-DLL ein Problem mit falschem casting von PAnsiChar. Das hast du aber vermutlich schon geprüft?

Mit der aktuellen z3strbie.dll Version 3.4.99.21 und dem Gleisplaneditor 3.4.0.0 habe ich erst mal nur eine andere Ausnahme bekommen. Evtl. habe ich da aber auch irgendwas falsch gemacht.

Ich kann den Fehler jetzt reproduzieren, aber nicht wirklich entdecken. Ich kann auch keine andere Methode der DLL ohne Zugriffsverletzung aufrufen (was aber erst mal nichts heißen muss). Mit .Net scheint es zumindest nichts zu tun zu haben, und weder die Aufrufkonventionen noch die Stringdarstellungen scheinen einen Einfluss zu haben.

Hi,

das Problem besteht weiterhin? Wie war das "Setup" nochmal?

64bit (oder "Any" Target?) Delphi .Net Gleisplan-Editor will die 32-bit Native-Delphi DLL aufrufen und stürzt ab?

Gibt es aus der .Net Gleisplan-Editor Welt nicht noch ein bisschen mehr Fehlermeldung? Stack Trace oder sonstiges?

Gruß
Max

Beliebige 32-Bit-EXE-Datei ruft in der 32-bit- z3strbie.dll Version 3.4.99.21 die Methode TempSpeichern_st3(Arbeitsverzeichnis, DateiName:PAnsiChar); stdcall; auf. In der Version 3.4.0.0 geht es noch, in der Version 3.4.99.21 gibt es eine AccessViolationException. Weder das Marshalling der strings noch die calling-Convention hilft, auch die Übergabe eines Nullpointers hilft nicht. Der .Net-Stack (ich habe mit einem eigenen .Net-Programm getestet) endet an der Grenze zum Nativen Aufruf. Die DLL wird aber noch geladen, der PE-Header wird folglich korrekt als x86 erkannt und es wird keine MissingMethodException ausgelöst, also stimmt auch der Export-Eintrag.

Ich habe versucht, andere Methoden, insbesondere die Methode dllVersion aufzurufen (wozu ich natürlich die Signatur erraten musste), aber das klappt weder in der alten noch der neuen DLL. Vermutlich habe ich da die Signatur falsch geraten. Also kann ich es nicht damit verifizieren. @Carsten: Hast du da zufällig die Signatur dieser Methode(n)?

F. Schn. hat geschrieben: ↑20.12.2022 11:59:53 Vermutlich habe ich da die Signatur falsch geraten.

Die waren hier mal dokumentiert worden: viewtopic.php?p=335006#p335006