WED-801

It looks like the operating system did not allow WED to create a new, empty file in the location reported. It could be that WED was unable to create the needed subdirectories inside the scenery folder because of permissions or the .DSF file itself is write protected for some reason - for examples its being in use by another program.

Please check if that path exists, then delete the DSF file at the reported desitnation by hand, then re-export in WED.

If that fails, I would need operating system and WED version info.

Wait a second - just noted the error message you quote seems to be missing directory separators ? The path should be something like Earth Nav Data-40-080-34-071.dsf.
I definilely need to know the WED version, exact OS version, exact absolute path to the DSF being written, exact path set in WED for the X-plane installation.

Ah - think its a software thing on our side here - my own post above also has stripped the separators,. But please still confirm.

I'm also having this issue, but I think is related to the encoding of strings (have a look at the screenshot). The name is actually Bragança but internally the 'ç' is not being properly encoded.

Good report, pedromagueija. I think it points to a possible root cause that wasn't clear to me from the original report:

Your choosen directory name for the scenery pack has a non-ASCII letter in there. This is likely the reason that your operating system (which, by the way ?) refuses to create a new + empty DSF file. And the improper diisplay of that non-ASCII character in the error message is due to the (OS specific) font used for the error message not supporting non-ASCII characters either.

For now, please rename the directory to use ASCII charcters (like A-Z, 0-9 and _ ) only.

@bsupnik @tgreene I wonder if its a viable idea to allow all UTF-8 chars in filenames. I'm sure there are some filesystems in the 3 OS we need to worry about that are not UTF-8 clean. In this case here its just the choosen scenery pack directory name, so its not affecting the gateway or other users using that scenery (as they can or their OS will rename it for them). But if a subdirectory or filename in that scenery pack were to use some non-ASCII UTF-8 char, there is real trouble and IMO there's just too many file systems to fully test this out.

Also, don't we need to upgrade the text printing subroutine and font in WED to UTF-8 - since the airport name and other meta-data tags are the real reason to support UTF-8, right ?

Hi Guys,

I think this may be a loose end?

• Ted wrote unicode wrappers around the file APIs - Michael, you can see
  this by searching on x_fopen for example, in the code.

• These require xdefs.h to be included.

• xdefs.h is not included in DSFLib. (Sad trombone sound plays.)

So I think this user got as far as he did because every part of WED is
now Windows UTF8 happy except the DSF encoder, which expects ASCII.

If this is the case, a cheap fix is to include xdefs.h in DSFLib, get
the macro redirection, and things should "just work".

In terms of printing: WED's UI layer is UTF8-ready already, but the font
we use may not have a fantastic set of characters. The one place where
we are really weak is keyboard input. I can confirm that copy-pasting
ISO-Latin-1 extended characters into text fields works.

cheers
Ben

@tgreene Ted, my theory is that this is because xdefs.h is not included in DSFLibWrite.cpp, causing the x_fopen macro to not work. You can repro this by trying to do a "build scenery" to a scenery pack with non-code-page characters; the apt.dat should work but the DSF should fail. If you fix the #define it should work for both.

IF any part of that expectation is wrong (e.g. it fails even iwth the #define, please assing this back to me!

I created a scenery pack called: "WED-801_ДЛąęźż你ᠥç", which has (from left to right) Russian, Polish, Chinese, Mongolian, and ç from Bragança's name and got it to export without any crashes, as in, without any changes to the source code. Somehow though, it still feels like you're right. I feel like I should be able to reproduce this...

Hi Ted,

Weird...what does the path at DSFLibWrite.cpp:1073 look like? If it's
ASCII and you put all that gak in, what's in memory and how is that
fopen() not failing?

cheers
ben

String getting passed into fopen: C:\Users\Ted\Desktop\X-Plane 11\Custom Scenery\WED-801_Ð”Ð›Ä…Ä™ÅºÅ¼ä½ á ¥Ã§\Earth nav data+30-070+32-065.dsf

Still produces a file without explicitly importing XDefs.h.

On Windows this behavior makes sense because in Visual Studio we set it to include XDefs.h everywhere.
"WorldEditor Property Pages->Configuration Properties->C/C++>Advanced>Forced Include File : ..\..\src\Obj\XDefs.h"

I foun this one while following up on a near identical problem in OSX:

The mktemp() function used in the course of creating a unique subdirectory for the export can't handle UTF-8 on windows.