[erledigt] DXFILEERR_FILENOTFOUND

[Herbertla]

Ich möchte aus Blender exportierte DirectX Dateien in der Demoversion des 3D-Editors anschauen.

Auf die Menüauswahl "x-Datei .... konvertieren" und Dateiauswahl kommt immer die Fehlermeldung, wie z. B.

11:37:02:096: .x-Datei nicht geladen (D:\Zusi\Strecken\Nuernberg_Ost\3D-Gebaeude\Tullnau\Tullnau.x) (DXFILEERR_FILENOTFOUND)

[AndreasBrandtner]

wurde in Blender zufällig irgend etwas mit einem "ä", "ü", "ö", oder "ß" benannt. Also z.B. die Materialien oder das Objekt selber. Solche Zeichen mag der exporter nicht.

[Johannes]

wurde in Blender zufällig irgend etwas mit einem "ä", "ü", "ö", oder "ß" benannt. Also z.B. die Materialien oder das Objekt selber. Solche Zeichen mag der exporter nicht.

Was Andreas gesagt hat, kann gut sein; ich dachte aber, dass dann die Fehlermeldung E_FAIL lautet. Ansonsten wäre noch zu prüfen, ob das Objekt irgendwo im Zusi-3-Datenpfad oder zumindest auf demselben Laufwerk liegt, sonst mag das der Objektbetrachter wohl auch nicht.

Grüße
Johannes

[Herbertla]

.... einem "ä", "ü", "ö", oder "ß" benannt.

Verwende ich prinzipiell nicht, ist noch alte UNIX-Schule!

Die Lösung scheint im Ablagepfad zu liegen. Wenn ich die Datei und die Texturdateien in die Partition lege auf der ...\Zusi3demo liegt, dann funktioniert es.

Ich erinnere mich, dass es mit ZUSI2 mit der Verwaltung ein ähnliches Problem gab. Woran hängt das?

[Mr. X]

Die Lösung scheint im Ablagepfad zu liegen. Wenn ich die Datei und die Texturdateien in die Partition lege auf der ...\Zusi3demo liegt, dann funktioniert es.

Das klingt ein bisschen so, als wäre die Handhabung von Pfaden in Zusi 3 genauso zerschossen wie in Zusi 2...

[Johannes]

.... einem "ä", "ü", "ö", oder "ß" benannt.

[…]

Ich erinnere mich, dass es mit ZUSI2 mit der Verwaltung ein ähnliches Problem gab. Woran hängt das?

Kleine Korrektur: Das Zitat stammt von Andreas Brandtner, nicht von mir

Wenn ich mich recht erinnere, versucht Zusi irgendwo einen relativen Dateipfad zu berechnen und scheitert an der Partitionsgrenze. Irgendsoetwas war es, jedenfalls wurde meines Wissens eine Datei im Pfad Z:\…\Zusi3Demo\C:\Irgendwas\… gesucht, was nicht funktionieren kann. Ist aber schon ein bisschen her. Vielleicht ist das in der finalen Version besser gelöst.

Grüße
Johannes

[Carsten Hölscher]

Ja, Zusi bezieht alles relartiv zu einem vorgegebenen Pfad. Bei Zusi 2 ist es das Installationsverzeichnis, bei Zusi 3 wird der Pfad in der Verwaltung eingestellt. Und da Windows keine "gemeinsame Basis" oberhalb der Laufwerksebene kennt, kommt man damit nicht auf andere Laufwerke.

Carsten

[Mr. X]

Ja, Zusi bezieht alles relartiv zu einem vorgegebenen Pfad.

Das klingt problematisch. Absolute Pfade in Windows sollten sich leicht erkennen lassen (*:\...), also könnte man sie doch eigentlich recht problemlos unterstützen?

[Johannes]

Ja, Zusi bezieht alles relartiv zu einem vorgegebenen Pfad.

Das klingt problematisch. Absolute Pfade in Windows sollten sich leicht erkennen lassen (*:\...), also könnte man sie doch eigentlich recht problemlos unterstützen?

Gibt sogar eine Windows-API-Funktion dafür: PathIsRelative (Edit: PathIsSameRoot scheint noch passender). Und wenn das nicht gehen sollte aus irgendeinem Grund, wäre eine aussagekräftigere Warnung statt DX_FILEERR_FILENOTFOUND mit einem augenscheinlich existierenden Dateipfad vielleicht wünschenswert

Andererseits ist das wieder so eine Sache, wegen der Zusi 3 vielleicht einen Tag später kommt

Grüße
Johannes

[Mr. X]

Andererseits ist das wieder so eine Sache, wegen der Zusi 3 vielleicht einen Tag später kommt

Wäre mir die Sache durchaus wert, wenn das Handling von Dateipfaden nicht so kaputt wie in Zusi 2 ist, und Meldungen wie "Das ändern des Streckenordners kann die Strecke unbrauchbar machen" verschwinden. Wäre nämlich auch schön, wenn die ganzen Pfade nicht immer relativ zum Zusi-Verzeichnis, sondern relativ zur aktuellen Datei wären (bzw. sein können).
Eine gute Implementation würde sowohl relativ zum Verzeichnis der aktuellen Datei suchen, als auch, falls dort nicht gefunden, relativ zum Zusi-Verzeichnis. Auf diese Weise kann auch Kompatibilität zur aktuellen Implementation hergestellt werden.

[AndiS]

Krieg ich es 3 Tage früher, wenn ich gelobe, alles in derselben Partition zu speichern?

Nichtverwendung von Umlauten und fast allen Sonderzeichen setze ich sowieso voraus, als langjähriger Computerbenutzer. Da kann ich nichts dafür fordern.

Auf den Aufkleber "Gute Implementierung nach Mr. X" würde ich auch verzichten. Aber das sollte mehr als 3 Tage Vorsprung bei der Release rausholen.

[F(R)S-Bauer]

Tach,

ich halte in heutiger Zeit die Beschränkung auf Strikten Unix-Zeichensatz für einen Anachronismus, Unicode sollte schon drin sein. Zumal das Minimum XP ist und mir per See auch kein Modernes Linux ohne Unicode einfällt.
In dem Bereich kommt mir Zusi manches mal wie Clipper vor, die hielten auch Ihren Textbasierenden DBASE-IV Compiler hoch währen der Rest der Welt in Windows angekommen war. Aber z.B. die Soundproblematik in Wine lässt wohl vermuten das noch einige UrAlt-Dos 1.0 Kompatible Systemfunktionen im Spiel sind, die bei allem über 8.3 abrauchen. (Wobei Delphi, ex TurboPascal nun auch nicht gerade für Innovationen an der Stelle bekannt ist...)

mfg

Ralf

[Carsten Hölscher]

Zusi selbst ist mit Umlauten usw. gar nicht das Problem. Die treten vielmehr in der Umgebung auf, z.B. bei zip-Programmen usw. und dann sucht man als ZPA wie bekloppt nach den Ursachen in den angelieferten Daten und hat ruckzug ein paar Stunden sinnlos verheizt.

Dateipfade relativ zur Datei selbst bringen aber auch wieder genug andere Probleme mit sich. Das wird so bleiben wie es ist. Die wenig aussagefähige Meldung bei DX_FILEERR_FILENOTFOUND müßte man bitte in Redmond vortragen - da bringt Zusi nur die Meldung, die DirectX liefert.

Carsten

[Johannes]

Die wenig aussagefähige Meldung bei DX_FILEERR_FILENOTFOUND müßte man bitte in Redmond vortragen - da bringt Zusi nur die Meldung, die DirectX liefert.

Es zeigt aber den falschen Dateinamen daneben an. Wenn ich versuche, die Datei „C:\test.x“ zu laden und Zusi auf „Z:\Zusi“ liegt, wird die entsprechende DirectX-Funktion mit dem Pfad „Z:\Zusi\C:\test.x“ aufgerufen. Den gibt es nicht, also liefert sie DXFILEERR_FILENOTFOUND zurück, was völlig korrekt ist.

Zusi sagt dann „.x-Datei nicht geladen (C:\test.x) (DXFILEERR_FILENOTFOUND)“. In den Klammern sollte aber statt „C:\test.x“ der Dateiname stehen, der an die DirectX-Funktion übergeben wurde – die Datei C:\test.x existiert ja. Alles andere ist höchst verwirrend.

Oder aber Zusi würde vorher überprüfen, ob das mit dem relativen Pfad auch klappt, und andernfalls etwa „Die Datei kann nicht geladen werden, da sie nicht auf derselben Partition wie Zusi liegt“ ausgeben.

Warum wird beim .x-Import überhaupt versucht, einen zum Zusi-Verzeichnis relativen Pfad zu erzeugen? DirectX kann ja mit absoluten Pfaden sicher genauso umgehen. Liegt es an den verknüpften Dateien in der .x-Datei (Texturen), die Zusi sonst nicht findet?

Grüße
Johannes

[Carsten Hölscher]

Ah, okay, die Meldung habe ich mal schnell geändert.
Zusi arbeitet grundsätzlich bezüglich Arbeitsverzeichnis. Wenn ich da jetzt anfange, über Ausnahmen nachzudenken und wann die wie und unter welchen Bedingungen zulässig wären, dann prost Mahlzeit.

Carsten

[F(R)S-Bauer]

Zusi selbst ist mit Umlauten usw. gar nicht das Problem. Die treten vielmehr in der Umgebung auf, z.B. bei zip-Programmen usw. und dann sucht man als ZPA wie bekloppt nach den Ursachen in den angelieferten Daten und hat ruckzug ein paar Stunden sinnlos verheizt....

Carsten

Die Frage ist ob man auf die letzte Pappnase mit dem Dos-Zip für MS Dos 5 Rücksicht nehmen muss.
Zumindest das Windows eigene Zip, als auch 7 Zip oder Win.rar haben die Probleme m. E. nicht.
Oder es werden halt Updates nur noch im Windows-Zip oder noch besser zad Format angenommen.

Außerdem ins Windows 7 zu mindestens in der Pro-Version Multisprachen fest, somit lassen sich solche Probleme wesentlich leichter feststellen als unter XP.

mfg

Ralf

[Max Senft]

Hi,

also ich kann auch nur sagen: Finger weg von Umlauten! Zwar sollte heute alles über UTF8/Unicode machbar sein, aber meistens siehts dann doch anders aus. Wenn dann irgendeine Software an die man überhaupt nicht denkt nicht mitspielt hat man verloren. Die Einhaltung von rein "normalen" Zeichen und Ziffern, also [a-z], [A-Z] und [0-9] und meinetwegen noch [-_] sollten dahingegen immer funktionieren, egal was für ein Zeichencode verwendet wird. So ists nunmal, leider.

Gleiches gilt auch für die "freien" eMail- und Web-Adressen. Ich will mal einen Ami sehen, der Martin.Müller@größüstär.com in sein eMail-Programm eingibt.

Gruß
Max

[Johannes]

Wenn dann irgendeine Software an die man überhaupt nicht denkt nicht mitspielt

Das erste Beispiel liegt direkt vor der Haustür: Der .x-Import von DirectX (den auch Zusi verwendet) scheitert an Umlauten in Mesh-Subset-Namen. Da fängt es also schon an …

Da ist die Grundregel „Im Zusammenhang mit Zusi grundsätzlich keine Umlaute verwenden“ doch einfacher zu merken (wobei man das Problem hier noch umschiffen kann, indem man direkt aus Blender nach .ls3 exportiert). Ist ja auch im deutschen und englischen Sprachraum nicht sonderlich schwer zu handhaben. Nur falls die chinesischen Add-ons für Zusi 3 kommen, muss man sich vielleicht etwas einfallen lassen – Pinyin mit Zahlen ist nicht sonderlich toll zu lesen

Grüße
Johannes

[F(R)S-Bauer]

E-Mail, Web Adressen und Urls sind nicht die gleiche Baustelle wie Dateinamen im Dateisystem.

mfg

Ralf

[Christian Gründler]

ich kann auch nur sagen: Finger weg von Umlauten! Zwar sollte heute alles über UTF8/Unicode machbar sein, aber meistens siehts dann doch anders aus. Wenn dann irgendeine Software an die man überhaupt nicht denkt nicht mitspielt hat man verloren. Die Einhaltung von rein "normalen" Zeichen und Ziffern, also [a-z], [A-Z] und [0-9] und meinetwegen noch [-_] sollten dahingegen immer funktionieren, egal was für ein Zeichencode verwendet wird. So ists nunmal, leider.

In der Tat, aber das "leider" kann ich nicht unterschreiben. Das Problem ist halt, daß die Verwendung weiterer Zeichen keinerlei Vorteile bringt, aber manchmal Probleme. Dateinamen sollten hinreichend sprechend sein, aber das geht auch mit einem eingeschränkten Zeichensatz. Wenn dieser vom ZPA vorgeschrieben wäre, gäbe es ein Weilchen Gemaule, und danach hätte sich jeder dran gewöhnt.

M.f.G. Christian