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.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

One comment on “WED 1.2: Recovering from a “bad token error””

  1. 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?

Comments are closed.