One difference between X-Plane 10 development and previous development efforts is that, because we have a fairly large art team (by LR standards), we’ve been developing a lot of the tools for version 10 scenery/airplane development during the main development cycle.  In the past, we’ve gotten the sim out, then added the tools later; I think the delay will be a lot shorter this time around, since many of the tools more or less work.

For WED, we have some of the new 10.0-related features controlled by #define; they’ll remain off for WED 1.1 (which basically makes WED a DSF overlay editor for X-Plane 9.0) and then go into a WED 1.2 release.  I think the timing will be tight – that is, we’ll get 1.1 finished during or right after X-Plane 10 beta, and then have a development preview of WED 1.2 almost immediately, by exposing the new features we are using internally.

What will be in the next crop of WED features for X-Plane 10:

  • ATC taxiway layout editing for the new X-Plane 10 ATC system.
  • A few more DSF tricks, like forests that render trees on the polygonal outline instead of the interior.

There are also some 1.2 features that we’ll get eventually that are in rough or partial shape right now:

  • Autogen placement (works pretty badly right now).
  • Road grid editing (still highly experimental).

WED File Formats

This brings us to WED’s file format.  If you’re not a coder, suffice it to say nothing’s going to break…the rest is technical.

WED 1.0 uses a sqlite3 database to persist earth.wed files.  This seemed like a good idea at the time – I thought it might be useful to do database-like queries against WED files.  Unfortunately, it’s not a good idea.

  • WED can’t run against the database, it loads it all into RAM, so the database is wasted.
  • Using sqlite3 slows down development time and makes versioning files more complicated.
  • The performance of the code that uses sqlite3 is poor.

I really do like sqlite3 as an embedded database, but my use of it is just not well thought out.

So I am planning to replace the sqlite3 database with some other file format.  I am planning on doing this before finalizing WED 1.1, to get the change over with before I go any further with the database format.

WED 1.1 will continue to read sqlite3 databases for the purpose of opening legacy projects (both 1.0 and older 1.1 beta projects) but will only save in the new file format.

The new format isn’t yet decided, but the strong contender is a simple XML format that persists each object in the WED hierarchy.  This would give us something structured, readable enough to debug, and there are lots of third party tools to work with XML.

If you area third party developer and have any strong opinions on WED’s internal file format, shout at me by email.

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.

9 comments on “WED, X-Plane 10.0, and File Formats”

  1. Do you mean the current delay of v-10 from December originally, as in the sim will be out in the relatively near to mid future.. aka not another yearly quarter?

    1. I mean neither of those things and I am making no statements about our release date.

      What I am saying is that, in the past, there has been a lag from when the sim was capable of doing a feature to when there were tools to make it easier to use the feature. Example: it was months from when the new apt.dat 850 came out (it was new in X-Plane 850 🙂 to when WED let you edit the format visually.

      So what I am saying is: with X-Plane 10, I think we’ll have the tools almost immediately after we have the sim, because so much of the tool work is being done now during development.

      1. Regarding airports, would it be possible to change the parking spot selection interface to a drop-down box (a la FSX) to allow more parking spots/gates/stands to be defined? When I try to port scenery over from FS, in many cases just a small subset of the parking spots is brought over. Especially with ATC now in the pipeline, this will turn out important…

  3. Thanks for the clarification Ben,

    this wait is gonna be worth it, but is long drag especially with silence on any input towards possible dates, or at least saying the august rumor is ridiculous. We fans are flying blind in anticipation for a release that could be may to august? ugggg

    Cant wait

  4. Ben, I don’t have a horse in this race, but how about yaml, or possibly better for you (simply because it’s more popular), json? They’re both text formats, they both have parsers/encoders available in “most” languages, and either of them is a whole lot nicer to look at, edit, or create by hand (if needed).

    1. Looks like both yaml and json would work, but lacking any strong pro, I think I’m likely to pick XML over both of them. I think the human component of WED is only debug-ability by programmers; a WED file is already semantically complex enough that making one by hand would not be fun. WED’s native format isn’t really appropriate as an intercange format..that’s one of the reasons why SQL wasn’t an appropriate choice (in hindsight).

Comments are closed.