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.