There is a bug in WED 1.2 beta 1 right now: if you somehow manage to get non-unicode data saved into your file*, you won’t be able to re-open it. This is definitely a bug and something I will fix as soon as I can, but it also means you can lose your WED project. This blog post explains how to fix an earth.wed.xml file that produces “bad token errors”.
An earth.wed.xml file is basically a very big text file. These instructions are for a Mac; on Linux the same tools are available – on Windows you can use the port of xmllint or find another, more friendly XML validator.
From the terminal, run xmllint like this:
xmllint --noout "/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml"
If you have an XML bad character bug causing the bad token error you will get something like this:
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : invalid character in attribute value <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : attributes construct error <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : Couldn't find end of Start Tag hierarchy line 168705 <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : PCDATA invalid Char value 16 <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^
In this case, the ? is the bad character being mapped to ‘?’ by OS X’s terminal. I now open the file in a text editor (I used X-Code), go to line 168705, and simply replace the string inside “name” with a new string, without a bogus character. Resave (make sure you are in UTF8 format) and you are good to go.
A future beta of WED 1.2 will fix this, but for now you can hand-edit; once you remove these XML errors your project should be good for further use.
* This bug is particularly insidious because WED 1.0 would very happily write junk data out to disk, then read it back again, so you could have non-unicode junk strings in your project for years and only upon moving to WED 1.2 realize what happened. A common way to get junk data is to import an apt.dat file with non-UTF8 airport names.
Just a note. In my experience there doesn’t have to be a (visible) bogus character. I’ve run into this issue in my past and using a XML code cleaner (or other means to find the offending line/column) of offending code simply rewriting the name=”n” and saving solved the problem.
At the same time, I’ve noticed that my resource directories are not presenting in X-Plane, ie. Airplanes menu in empty, Output, etc.
The directories are there but not showing up in X-Plane 10.10. I thought one of the beta’s did this but when I reversed my install to 10.10r3 the menu’s are still empty.
Permissions seem to be OK.
Could this be related to this XML bug in some way?