Zusi-Forum

Hallo in die Runde!

Ich bastle gerade an einem Fantasiemodul, welches nun auch endlich das Gelände "drumherum" bekommen soll.
Nun wollte ich also die st3-Datei im Geländeformer laden, da kam die Meldung, dass angeblich die Datei "DB_Ra12.lod.ls3" beim Einlesen der ls3-Datei nicht gefunden werden kann (siehe Screenshot).




Die Datei ist aber im offiziellen Bestand vorhanden:




Ich komme mit meinen Bordmitteln hier grad nicht weiter. Wer kann mir helfen?
Würde es als Workaround funktionieren, wenn ich die 30 Ra12 in meinem Modul lösche und nach dem GF-Lauf wieder aufstelle?


Gruß
Martin

Vor kurzem gab es ein Update der Ziegler-Tools auf Version 2.2.1.1, das die hier benoetigte Unterstuetzung fuer das zweite Datenverzeichnis nachruestet. Hast du das schon installiert?

Hallo Johannes,

die Updates sind alle auf dem neuesten Stand, hab das gerade noch mal geprüft. Oder ist hier was anderes gemeint als die normales Updates über die Dateiverwaltung?


Martin

Ich glaube, dass die Ziegler-Tools nicht ueber die Dateiverwaltung aktualisiert werden, sondern separat. Diese Version meine ich: viewtopic.php?f=74&t=15618" target="_blank

Hallo,

es lag tatsächlich am Update, jetzt läuft der Geländeformer.
Allerdings musste ich vorher auch noch das 2017er-Update der Ziegler-Tools von hier http://www.rolandziegler.de/StreckeUndL ... ansDEM.htm herunterladen und installieren. Das war irgendwie auch noch nicht aufgespielt :-/

Aber jetzt läufts. Danke für die Hilfe!


Gruß
Martin

Ganz 100%ig funktioniert die Unterstützung des zweiten Datenverzeichnisses im Geländeformer noch nicht: In meinem eigenen Datenverzeichnis liegen einige modifizierte lod.ls3, während die zugehörigen lod1/2/3-Stufen unmodifiziert im offiziellen Verzeichnis liegen. Der Geländeformer beschwert sich, er könne die untergeordneten lod-Stufen nicht finden. Offenbar erwartet er, dass ein 3D-Objekt gesamthaft im eigenen Datenverzeichnis liegen muss, wenn die lod.ls3 dort liegt.

Es gibt nur eine einzige Stelle im Code, wo Dateipfade aufgelöst werden. Jeder einzelne Pfad geht da durch. Weicht in diesem Fall der Pfad vom Üblichen ab?

Roland Ziegler hat geschrieben:Weicht in diesem Fall der Pfad vom Üblichen ab?

Ich würde sagen, nein:
Der Geländeformer bemängelt bei dieser Datei, dass er die lod0 und lod1-Datei nicht finden könne. Die sind aber im offiziellen Verzeichnis definitiv vorhanden, und die Zusi-Programme laden sie auch ganz fröhlich. Zur im selben offiziellen Ordner liegenden lod2 oder lod3-Datei wirft er hingegen keine Fehlermeldungen.

Ich vermute mal, dass mein ls3-Reader gar nicht weiß, was LODs überhaupt sind. Wird zu untersuchen sein, muss aber ebenfalls bis nach dem Urlaub warten.

Es gibt ja die Pfade "Routes/blub/bla/whatever.ls3" für Dateien, die in anderen Ordnern liegen, und die Pfade "blub.ls3", für Dateien, die im selben Ordner liegen. Möglicherweise kannst du ja mal darauf achten, ob das Problem dort irgendwie existiert.

Seit 3.3 werden Änerungern am Format durch eine neue Versionsnummer gekennzeichnet. Hier sollte es reichen, nur auf Version A unabhängig von der Folgenummern zu prüfen, da es hier i.d.R. um Werte geht, die nicht Zieglertool-relevant sind.


Carsten

Möglicherweise ein verwandtes Problem: Ich habe den Geländeformer dabei erwischt, dass er Dateien aus dem offiziellen Verzeichnis lädt, obwohl die Dateien auch in meinem privaten Verzeichnis existieren. Dort liegen sie in einer Fassung vor, bei der ich fehlerhafte GF-Kennzeichnungen korrigiert habe - deshalb kann man gut sehen, dass der Geländeformer intern die alten fehlerhaften Fassungen dieser Häuser aus dem offiziellen Verzeichnis für seine Berechnungen verwendete. Bei Bedarf kann ich Testdaten zur Verfügung stellen.

Konkretes Beispiel, gegen das ich den Debugger laufen lassen kann, wäre tatsächlich hilfreich.

Der ganze Mechanismus, wie .ls3-Dateien vom GF gefunden werden, wird neu geschrieben. Der bisherige Ansatz enthielt noch Elemente aus der langen Zusi3-Entwickungsphase, bei denen die Verzeichnisstrukturen anfangs noch nicht immer eindeutig waren. Einzelne jener Suchkriterien vertragen sich aber nicht mit der dieses Jahr eingeführten dualen Verzeichnisstruktur. Das führt zu dem beobachteten Fehlverhalten.

Ein Beispiel von Alwin scheint im ersten Versuch nach der Neuimplementierung nun fehlerfrei durchzulaufen, aber das werde ich noch genauer untersuchen. Es soll dann so sein, dass für alle .ls3-Dateien zuerst immer im benutzerdefinierten Baum geguckt wird, erst danach im offiziellen. Das gilt auch für lokale .ls3-Datei-Verweise, solche ohne Pfad. Voraussetzung natürlich, dass der benutzerdefinierte Baum genauso aufgebaut ist, wie der offizielle.

Bei .lsb-Dateien allerdings erwartet der GF auch zukünftig, dass sie im selben physikalischen Verzeichnis wie die zugehörige .ls3 liegen.

Ein Schmankerl aus der alten Zeit ließ sich erhalten. Ein komplett unabhängiger, dritter Verzeichnisbaum ist weiterhin möglich. Der wird bestimmt durch den absoluten Pfad der obersten .ls3-Datei. Der GF lässt ja die direkte Auswahl einer .ls3-Datei zu, ohne Verzeichniswurzeln zu prüfen. Auch bei Dateien aus diesem dritten Baum wird bei hier fehlenden in den beiden anderen Bäumen gesucht.

Anmerkung am Rande: Mit einer der jüngsten Entwicklungen in der C++-Standardisierung, C++17, steht nun auch unter C++ ein plattformunabhängiges komfortables API für das Dateisystem zur Verfügung, namespace std::filesystem, #include <filesystem>. Da kann man zum Beispiel mit einfachsten Funktionen feststellen, ob ein Dateipfad existiert, oder ob es sich um einen absoluten Pfad handelt. Erstaunliche/verblüffende Ähnlichkeit zu den entsprechende Framework-Klassen in .Net und C#. Treibende Kraft Microsoft? Die Gemeinde nimmt's dankend an.

Roland Ziegler hat geschrieben:Erstaunliche/verblüffende Ähnlichkeit zu den entsprechende Framework-Klassen in .Net und C#. Treibende Kraft Microsoft? Die Gemeinde nimmt's dankend an.

Es handelt sich hierbei um die Bibliothek Boost.Filesystem, die nahezu 1:1 in den C++-Standard uebernommen wurde.