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.
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.
If you maintain a plugin for X-Plane, you can already take some of the steps necessary to go 64-bit. I am working on 64 bit code for 10.20; here’s what you can do to be ready for the beta:
Upgrade to the X-Plane SDK 2.1 headers. The 2.1 headers change the use of long to intptr_t to fix 64-bit issues. This will mean a one-time cut-and-paste pass over your code.
Note that you do not have to make your plugin v10-only (or 2.1 SDK only) to use the new headers. Your plugin will require the 2.1 SDK only if you #define XPLM210 to 1. By not defining the new APIs you don’t opt into them. Your plugin built against the 2.1 SDK will work with X-Plane 9 (or 8, 7 or 6 for API 1.0 plugins).
Find and fix any case where you cast a pointer to an int and back – in 64 bits that will fail. as you will see from the 2.1 headers, widget properties are now intptr_t to ensure that the property can hold a pointer.
Once you have have fixed these new header issues and int <-> ptr issues you’ll be in good shape to go to 64 bits when a sim is available.
Update: to clarify, with the 2.1 SDK you can write code that will be 64-bit safe, and you can probably even compile in 64 bits. But you can’t link your 64-bit plugin – we have not released library files or documentation on the appropriate fat packaging structure. So you can get ready by cleaning your C/C++ code, but you can’t actually finish a 64-bit plugin. (And if you could, how would you test it?)
We have a handful of users reporting crashes on Windows using NVidia drivers. So please email me (ben at x-plane dot com) if you meet all of these requirements:
You have an NVidia graphics card.
You are running Windows 7.
You are running X-Plane 10.10r3.
You are running the latest (306.23 WHQL) drivers.
X-Plane crashes in a reproducible way (e.g. every time you turn up shadows, crash).
I am looking to collect more in depth crash information to figure out what is going on. Sadly Chris and I both have NV-Windows boxes in our offices and both are stable.
Chris and I wince whenever we see a forum post like this*:
Every time I start up the left engine of the KX-1000 turbojet, rain appears on my right windscreen. I hope 64-bit fixes that!
Seriously though, 64-bit seems to have gained a reputation in the community as the messiah that will cure all evil. This reputation is unfounded.
64-bit will do one and only one thing: allow X-Plane to use significantly more virtual memory without crashing. If you crash because you run out of address space, 64-bit will help you. It is not going to fix anything else.
Here are some things 64-bit will not do:
64-bit will not make X-Plane faster. Using more memory doesn’t make things faster. (Nerds: using IA64x86_64 doesn’t make things faster. We’re not register bound because secretly x86 chips do crazy register renaming. We are, however, L2 bound, and making all of our pointer-based structures 2x in size isn’t a move in the right direction.) Past tests indicate that 64-bit is performance neutral.
It won’t fix any bugs. If a system is broken in 32-bits, it will be equally broken in 64 bits.
It won’t make anything look any better. The same settings should produce the same image in 32-bits or 64-bits.
It won’t bring world peace. For that you need 128 bits.
Actually, that second-to-last statement is slightly not true . With 64 bits, some settings will become possible for some users that were strictly memory bound before. For example, if you couldn’t run extreme texture res and extreme forests only due to memory limits, 64-bits will let you use extreme res and forests, and that probably will look better than having to pick one or the other.
Of course, with the address space limit removed, users will run into a series of new limitations:
Some users will run out of physical memory. Fortunately RAM is very cheap, but it’s not easy to upgrade in a laptop or iMac. (I stand corrected: apparently iMac RAM upgrades are now slip-in, which is cool. I think a while ago you had to pop the case, which wasn’t much fun. The TiBooks used to have a RAM drop-in under a pop-off keyboard, which was cool but put constraints on how strong the keyboard could be. But I digress.)
Some users will not be able to show all of that extra 3-d “stuff” at reasonable framerates.
Some users will run out of VRAM at the higher texture resolutions.
There’s always one thing that limits performance…64 bit simply ensures that it isn’t the needless artificial limit of a 32-bit process.
* Whenever we see such a post by accident while looking at online shoe catalogs. We do not read the forums! Do not assume that a forum post is a bug report. Insert the rest of the rant here, etc.
X-Plane 10.10r3 came out this weekend – go use it! This is my expectation over the next week:
Barring a truly horrific bug, we’ll probably declare 10.10r3 to be the final build of 10.10 and make it live to everyone.
We will probably cut a 10.11 bug fix patch within the next week.
Why do I expect 10.11 so soon? Because there is always one bug that we don’t find out about until we make the rc live to everyone – inevitably one hour after the build goes live, someone reports something that no one saw in development, no one saw in the company, no one saw in beta, that we want to fix. Murphy’s law is irrefutable.
In the case of 10.10, the rate of bugs coming in on 10.10 has slowed down a lot, so if we continue to fix bugs in rc, we’ll be fixing bugs at a very low rate without moving on to the next thing. Thus it’s likely we’ll “kick it out the door”, get our one late bug, and cut a quick patch. We may also get additional localization into 10.11, depending on what we get from our translators.
It looks like the next sim patch after 10.1x (e.g. 10.10 plus any bug fixes) will focus on finishing and shipping 64-bit, hopefully with more autogen coming along for the ride.
As always, please report bugs to the bug reporter, not the blog, and not email; link is on the right.
(A quick side note/rant: my email server kind of exploded a week or two ago – lots of emails bounced, lots of emails were lost. This is one reason why I do not want bugs by email! I am always threatening “if you don’t file a bug, it might be lost.” Well, if you sent me a bug by email, for all I know it was lost. Please use the bug reporter!!!)
I’ve yet to see an episode of “Hoarders” with an aviation theme but apparently people with that flavor of the disease exist because I’ve gotten a chance to talk with a few who have accumulated a serious amount of 3rd party X-Plane content over the years. I’m joking of course and don’t mean to insult anyone or make light of people with illness. If you want to complain about my faux pax, contact Ben Supnik. 🙂
There is a real X-Plane issue here however. X-Plane makes no assumptions about the locations of certain types of files. Aircraft/Airfoils/Objects/Bitmaps etc are allowed to be…well pretty much anywhere in the X-Plane folder (with a few exceptions). You can argue this is silly but for historical reasons, that’s the way things are today. In order to show you a list of all aircraft for example, X-Plane has to search everywhere within its folder in order to find them all.
In prior versions, if you added a new aircraft into your Aircraft folder for example, you had to restart the sim for it to appear. As of X-Plane 10.10, X-Plane now scans for new files every time the “Open Dialog” is opened. This is done intentionally as many users have asked for this behavior. For 99% of the population, this works fine because X-Plane’s file system is relatively flat but if you’re a hoarder and you have a HUGE amount of content in your X-Plane folder, you may notice a delay when opening new Aircraft/Airfoils/Objects etc. This delay always existed but it used to ONLY happen during sim load so it was hidden.
The problem is that you have to rescan the entire file tree each time the dialog is opened. I know a lot of you developers are saying “No you don’t! You can hook the OS and look for changes since the last time and rely on your cache if there were no changes!” and you’re right…but you haven’t seen X-Plane’s File I/O code. You’ll have to trust me when I say it’s non-trivial to support this on 3 different operating systems and it will only benefit a very small percentage of users. This is not where our time needs to be spent at the moment.
In the meantime, we did want to provide a workaround but before I get into that, I want to explain things in a bit more detail. The slowness I found in the few cases that I studied were caused by 3rd party folders within X-Plane that did NOT contain any X-Plane relevant data. In other words, there were no aircraft, airfoils, objects, scenery etc in it that were being used by the sim. That means, the sim had to search through the whole thing only to find…nothing. One common folder was “Custom Scenery (disabled)” which is apparently created by a plugin out there that lets you disable certain scenery packs. This folder has now (As of 10.10R2) been added to our internal black-list so that we know to automatically skip it when searching for data. There are other folders that were already in the black-list. Here’s a current list:
Global Scenery*
Custom Scenery*
Resources
Plugins
Liveries
Cockpit
Note that the * is a wildcard so anything can appear after and still match our filter.
This is very important to note…the black-listed folders are automatically skipped by X-Plane for one purpose only…Dialog Population! Files in blacklisted folders will not appear in any “Open Dialogs”. Examples include Open Aircraft, Open Replay, Open Situation, Open Airfoil (planemaker) etc. Files in these black-listed folders can still be found by the sim for other purposes. Notice that custom scenery still loads even though it’s blacklisted, plugins still work properly etc.
What we wanted was a way for users to specify their own black-listed folders. Some users are developers and have folder after folder of development data in the X-Plane tree that they’d want to blacklist. Starting in 10.10 R2, you can do this by creating a file called:
dont_search_here.txt
in the folder that you want to blacklist. The file can be blank…its contents are completely irrelevant as only the name matters. When X-Plane encounters a folder that contains that file, it will completely give up on the folder and not scan it or scan any deeper. So any Aircraft, Airfoils, Situations, Replays, Weapons, Objects, FMS files, Waves, FDR files or Bitmaps in there will not appear in the appropriate open dialogs.
My recommendations to you:
Do your best to keep non-X-Plane specific data out of the X-Plane tree.
If you can’t or don’t want to follow advice #1, that’s fine. If and ONLY if you suspect that your data is causing X-Plane’s various “Open Dialogs” to be slow, try dropping the dont_search_here.txt into the folder if it doesn’t contain any files you want displayed in X-Plane’s dialogs.
If you’re not experiencing noticeable slowness, don’t mess with this at all! This is not a widespread problem!
First, X-Plane 10.10r1 is out, at least for the next few hours; beta notes here. There are already two known issues:
10.10 is not particularly happy with current shipping ATI Windows drivers. We’re still figuring out what our best path is. We may have to disable functionality when we identify this driver set.
It turns out I broke the P-180 3-d panel, so we’ll cut a new release candidate pretty soon.
If you create add-ons, please go test this release candidate! We can’t fix bugs that are not reported, so now would be a good time to find out if your add-on is adversely affected.
Screen-Cast: Engine Settings
While the changes to the starter are pretty limited, Chris and I did spend a lot of time experimenting with the starters on a number of planes. (The starters are tuned on the 747, C90, B58, P180, and C172.) So I decided to try a screen-cast showing how to edit the starter settings.
This is not exactly the highest production value screen-cast you’ll ever see; rather it’s something I whipped out in less than an hour while the release candidate was uploading.
If this kind of resource is useful, please let us know. During the developer conferences, Austin and I did some short hands-on demos; it isn’t hard for us to turn that kind of thing into a screen-cast.
The screen cast and the blog are not meant to be a replacement for documentation; we’re working on that too. But creating demonstration materials is significantly easier in screen-cast form than document form.
First a quick note: X-Plane 10.10 Beta 11 is now out. What happened to beta 10? It lasted about 15 seconds, from when it went live to when I realized that aircraft were missing and code signing was screwed up.
We’ve had a few of these “beta bounces” where a beta lasts less time than a Plutonium isotope. The basic policy is this: if we cut a beta and it is live on the net at all, even for one second, and we then realize the beta is borked, we cut a new beta with a new beta number. Thus the very short life span of beta 10 – we didn’t reuse the number 10.10b10 when we fixed the problems.
Why not just reuse the beta number? Because we want to make sure that anyone who accidentally gets the broken beta gets the new beta, and to do that we have to bump the version number. Now that X-Plane auto-checks for updates, people get the new beta within seconds of it going live.
Autogen
A while ago I posted a road map for our autogen cities. Part of the work involved improving the road generation algorithm (a lot of which has been done for 10.10, and some of which still needs more work) and part involved new art assets.
Our original plan was to include the latest art assets with 10.10, but we are now planning on releasing the next round of city art assets with 10.20, the 64-bit version of X-Plane. There are two reasons for this:
The urban assets aren’t entirely done, but they are very inter-dependent. To maximize framerate, Propsman shares as much texture as possible betewen parts of the urban package, so it’s quite tricky to release part of the autogen.
The new autogen does take a little bit more memory. Not tons more, but for a user on the red line with 32 bits, upgraded autogen might require memory that isn’t available.
So rather than take up Propsman’s time finding a way to cut off and release part of the art assets, only to hear from users that thy are out of memory on OS X, we’re thinking it’s better to get on with 64-bit and release the art assets as a whole on a build that can handle them.
I think we may be able to release the new road pack with 10.10, and a number of other art assets are already in the 10.10 betas – new aircraft, upgraded global terrain, and new lights.
This rather odd 747 picture is from a quick test I did to make sure the shadow options in Plane-Maker were working right after beating the shadow code silly with a hammer. The wing objects have been marked “interior only” for shadows, and since we are in an exterior view…the wings don’t cast shadows. 🙂
Now this is a totally silly way to use the feature, but there is a legitimate use: mark as many of your interior objects as “inside shadow only” as possible; for example, in the 747 the interior passenger cabin object can be marked as interior only – it doesn’t cast meaningful shadows on anything outside the airport.
By marking an object as no-shadow in Plane-Maker you save the sim the work of drawing the object, which is good for fps. If your airplane is used for an AI plane, this makes AI plane drawing less expensive.
In fact, you save it the work of drawing it multiple times. X-Plane using a shadowing technique called “cascading shadow maps”. Basically X-Plane renders different parts of the world at different resolutions, so that the closer shadows (that can be seen in more detail on screen) have a higher resolution. The user’s plane ends up being drawn in a lot of these rendering passes, and as a result the cost of high-geometry-count objects in an airplane can be amplified several times over by shadows. So savings in object-shadow count matter!
(Given the choice of turning off shadows in Plane-Maker or via GLOBAL_no_shadow, use Plane-Maker; it stops drawing earlier and thus saves more CPU.)
I’ve yet to see an episode of “