I just posted WED 1.5 release candidate 2. If you grabbed RC1 and hit the crash on export on Windows, please grab this ASAP and file a bug if your crash is not fixed. Of the four or five crash reports I received, two contained reproduction materials and both were the same bug – a crash when exporting a ramp position with no airliners, Windows only. This is now fixed.
WorldEditor 1.5 beta 4 is available for download. The only major change here is that we seriously backed off the requirement to have hot zones off of the approach and departure ends of runways; this requirement is now only 100m.
I believe that with beta 4, our validation requirements are now correct; please attempt to validate your WED airport in beta 4 and file a bug ASAP if you find a problem. Otherwise, our plan is to make WED 1.5 beta 4 the required version for Gateway upload.
The only other remaining task to finalize WED 1.5 beta 4 is for Ted, Jennifer and Julian to go through the 75+ (really!) validation messages and review them for clarity and helpfulness. If WED tells you it can’t upload your airport, you deserve to know why!
WorldEditor 1.5 beta 3 is now available on the WorldEditor download page.
Besides a number of new features, WorldEditor 1.5 has much stricter validation checking; our is to get to a point where, if WED will export it, your scenery pack doesn’t have problems. This has two implications for the beta.
You’re Not Validating My Work!
If you haven’t tried a WED 1.5 beta, you may be surprised by how many validation errors WED finds. In particular, Ted coded a hot zone and runway analyzer that catches mistakes with taxi routes. It turns out that it’s really, really hard to get hot zones perfect by hand; even experienced WED authors who know all of the hot zone rules usually miss a few just due to the shear number of hot zones in a large airport and human error.
We have also seen airports on the gateway where the author clearly did not understand how hot zones were supposed to work at all.
We put the validation in because X-Plane’s ATC absolutely cannot function without properly marked hot zones; they are the only way that the ATC understands how airplanes are operating in the movement area. I think a significant amount of “weird ATC behavior'” will go away as we get better airport data that passes validation, and it will make the remaining real bugs easier to spot.
It’s not fun discovering that you have a big pile of problems to fix in your airport. To that end, we have been working on the docs to make sure that the ATC system is clearly documented, and we are now working on the validation messages themselves to make them more clear. If you find some part of the docs themselves that aren’t clear or have mistakes, please file a bug on the X-Plane Scenery Gateway’s bug reporter.
To be clear: airports already uploaded to the gateway with WED 1.4.1 will remain there, even if they fail validation; we’re not removing airports. But if you want to upload new work once WED 1.5 comes out, you will need to fix existing validation problems.
Who Will Validate the Validator?
The validation code may not actually be correct! People reported a number of high profile validation bugs, and they have been fixed in beta 3. But this doesn’t mean we have found all of the problems.
Please run your airport through beta 3, and if it fails validation, read the docs. If it seems like what you did is valid but WED is saying it is not, please file a WED bug on the X-Plane Airport Gateway’s bug reporter.
When WED 1.5 goes final, it will become the required version to upload airports to the gateway, so we want to be sure that the validation code is enforcing what we want enforced.
WorldEditor 1.5 beta 2 is up – you can download it here. Please report WED bugs on the gateway’s bug base.
This version of WED has a lot more validation than past ones did, so expect your previously “good” airport to fail validation. In particular, WED now validates that hot zones have been properly used around all runways in the ATC taxi route network. Getting hot zones perfect is very, very hard to get right by hand; the validation tool is meant to help you find the problems.
Jennifer is working on comprehensive documentation on ATC taxi route authoring; I’ll link to it as soon as it’s done. Our hope is that with the new docs and validation, everyone can understand how to correctly set up ATC taxi routes, and get assistance from WED to get them right.
Update: docs are up!
As some have noticed, we are not accepting uploads to the gateway from WED 1.5 betas. The issue is: if the validation code has bugs, then WED could (due to a bug) force you to upload an incorrect airport to the gateway.
I don’t know when we will allow uploads, but my guess is that within two weeks we’ll have a WED RC or final version that is ready to use.
For now your best bet is to use WED’s new tools to get the bugs out of your taxi layout and flows.
As some of you know, it was my plan to end-of-life the AC3D exporter for X-Plane; the decision was based on having limited resources to develop exporters.
The good news is: Andy Colebourne of Inivis has taken over development of the plugin, and has released the latest version of it – you can find it here. I am linking our download page to his forum link for easy access.
The AC3D plugin shares OBJ import/export code with WED and the rest of the Laminar Research C++ tools; my goal is to not break Andy’s work when working on WED. We use this code not only for WED object preview and the AC3D plugin, but for internal tools that pack up art for the iPhone version of X-Plane, so hopefully there will be some good leverage between the AC3D plugin and other Laminar scenery tools.
The first beta for World Editor 1.5 is now available to download.
This version features numerous bug fixes, along with major improvements to make editing airports easier and faster by providing more visual clues. It’s also the first 64-bit version of WED!
Some highlights of this version include:
You can see the full list of bug fixes, improvements and new features in the README.WorldEditor file found in your downloaded WED folder.
Please try the latest version as soon as you can and let us know if you find any bugs by filing a report on the Scenery Tools tab of the Gateway (not the desktop bug reporter for once!).
That’s the new taxi sign editor in WED.
Signs in the hierarchy are shown as a rendered preview of what the sign will look like.
When you click on it (as if it was text) you get a WYSIWYG editor with two “text” fields where signs can be directly typed, and a palette where signs can be added by clicking.
X-Plane 10.45 fixed one of the big “ecosystem” problems with the global airports by excluding airport objects by ICAO code. This makes the global airports much less likely to conflict with custom scenery, even if that custom scenery lacks exclusion zones.
For 10.50, I am looking at another change to how we manage airports that should help gateway authors: per airport control of flattening.
As of X-Plane 10.45, airport flattening is a user setting; a user can pick to have all airports flat, or all airports follow the terrain contours.
This is a rather silly setup. One size does not fit all for airport flattening, and the author of the airport is more likely to know how the airport will look with/without flattening than a user who is flying to that airport. It certainly isn’t efficient to have everyone in the X-Plane community set flattening individually without authors being able to set up their airport the way they want.
From what I’ve seen, there are two legitimate uses of airport flattening.
- To fix bugs in the underlying terrain, e.g. if the DSF is screwed up, then the airport may need to flatten it to make the airport usable at all. We want this to be the exception, not the rule. (X-Plane 10 is more buggy than past X-Plane releases WRT bumpy runways, so this may sound funny right now, but overall we aim to have users be able to fly with non-flat runways.)
- To accommodate highly customized airports where the 3-d models depend on a flat surface.
In X-Plane 10.50, it should be possible (using a new version of WED) to mark an airport as “always flatten”. The expected usage is:
- Users leave “runways follow terrain contours” on, all of the time.
- Authors mark individual airports as needing flattening, e.g. to fix bugs or accommodate custom scenery.
There is one use case that isn’t handled well by this: if an airport needs different flattening based on different base meshes, there is no way to tag that in the airport. But I view this as a fairly difficult problem to solve with existing technology – we would need a 2-d grid matching every custom version of an airport against every version of the mesh ever to exist.
Fixing the Mesh
Please note that this feature is not a replacement for being able to customize mesh elevation at a local airport from an overlay. “Mesh patching” is what we want to be able to do in the long term, but for X-Plane’s engine, it also means a lot of complicated internal changes to how the rendering engine works; customizing flattening is something I can ship now in 10.50 that at least helps.
Flattening is also not a replacement for fixing bugs in the base meshes themselves; one trend I have observed over my decade+ working on X-Plane (!) is that the accuracy of source data keeps getting better. Ten years ago it would be silly to say “how about if everyone just uses the real world values for their scenery and it will just work”. At this point that’s not actually a pipe dream, it is often completely manageable. So my hope is that someday we can reach a point where the terrain is just accurate and everyone uses it.
As of right now I have this code working in X-Plane but I do not have a build of WED that supports it. We are still in the middle of working on 10.50 apt.dat features, so I’m hoping to post something on that soon.
Ondrej has posted a public thread about the new version of the Blender 2.7 exporter here.
The 3.3 release is the first release where we (Laminar Research) have worked closely with Ondrej to build what we hope will be one of the future cornerstones of modeling for X-Plane.
If you are currently using Blender 2.49 or AC3D, I expect that 2.73 will provide the best way forward for modeling in X-Plane.
The new release has a few major features, all aiming to create a new modern work-flow:
- All animation bugs are fixed. (At least,we think – if you find one, please report it ASAP!) This means animation is WYSIWYG. Armatures are supported for animation as well as animated data block containers.
- The exporter understands all modern OBJ features, including ones scheduled for release in X-Plane 10.50.
- Instancing is handled via a single option with exporter validation, so you don’t have to know how instancing works to get instancing.
- The material rules are validated, and materials are found automatically; you can simply model as you want and Blender will do its best to export it or tell you if there is a problem.
- Specular and Normal maps are ‘merged’ together from two separate sources. This lets you set specularity and normal maps in separate material channels in Blender for a more WYSIWYG approach. It also means no more messing with Photoshop to combine these layers.
The goal of many of these is to hide the idiosyncrasies of X-Plane’s modeling format and provide a cleaner, more artist-friendly view of modeling.
Regarding instancing: the model we have adopted is the one we used internally on the 2.49 exporter: you (the artist) tag an export as either “instanced” or not.
- If instancing is on, the exporter writes only data to the OBJ that will be hardware-instanced by X-Plane. If you do something that cannot be instanced, like animation, you get an export error telling you what you have to remove.
- If instancing is off, the exporter writes the object normally.
The win here is that you don’t have to know the (complicated) instancing rules; set instancing for the scenery objects you need to make fast in bulk (e.g. a luggage cart, a house, something that will be used many times in a small area) and you’ll get optimal output.
Optimization – Coming Soon
The goal of the 3.3 release was to set up an environment where authors could work using the new work flow. We have not finished optimizing the OBJ output.
If you are using the existing 2.7 exporter for airplane work, the output should be similar in performance. If you are using the 2.49 exporter, the new output is (like the current 2.7 exporter) not as well optimized.
In a future update, we will tighten up the generated OBJ code; this should not affect anyone other than producing better OBJs.
The new exporter should be fully work-flow compatible with the previous Blender 2.7 exporter; if you find your existing project does not work, please file a bug!
Our plan is to create a migration tool for Blender 2.49 projects; this will forward-convert the datarefs on annotations, manipulators, and object properties from 2.49 to 2.73 format. This lets authors using 2.49 move forward to 2.73 and have a migration path for existing content. (This work is not started yet, but is planned – we have our own aircraft we need to keep working on.)
MH1212, developer of the Prefab Airports for X-Plane, requested this feature, and it looks like we are going to be able to sneak it into X-Plane 10.45. (If we hit bugs, it might get pushed out to 10.50, but so far things look okay.) The feature is: the ability to exclude objects by airport ID without using exclusion zones.
Right now when a custom scenery pack replaces an airport (via apt.dat), the old apt.dat is completely ignored. But the DSF-based overlay objects, facades, etc. are included; the custom scenery pack has to use exclusion zones to kill them off.
With this extension, the DSF-based overlay objects in a scenery pack can act as if they are in the apt.dat file, disappearing when the apt.dat airport is replaced. This means that when you replace an airport (via apt.dat file) not only do the runways go away, but so do the overlay elements.
Here’s the win: we can export our global airports from the X-Plane Scenery Gateway this way, and custom scenery will remove the overlay elements automatically just by replacing the apt.dat, even if no exclusion zones are present.
Here are some details:
- The scheme works if the underlying airport is correctly marked as having its objects and facades “inside” the airport. So unlike exclusion zones, this scheme works if the underlying airport is modified, not the overlaying airport.
- This is a new scheme – no existing scenery already does this; scenery must be re-exported to gain access to this functionality.
- The functionality requires the latest version of X-Plane, but is harmless to old X-Planes – the DSFs will still load.
- Exclusion zones still work and are still recommended; if you are making custom scenery and you are on top of autogen or an old scenery pack that is not modified using this new scheme, only an exclusion zone will save you.
There are two big advantages of this scheme:
- We (Laminar Research) re-export our collection of thousands of airports on a regular basis, so we can tag the entire set of global airports using this new scheme and have them ready for by-airport-ID exclusion very quickly. So this scheme will start to help conflicts immediately.
- The scheme doesn’t require modifying the overlying scenery at all. There are freeware airports that are effectively orphaned – the author cannot be found and the license doesn’t allow the community to modify them*. Since these airports cannot be legally redistributed with exclusion zones, this technique will help.
Once X-Plane has this extension and the global airports are re-exported using it, global airports will fully disappear when any custom scenery pack replaces the airport by apt.dat, even if the custom scenery pack doesn’t have good exclusion zones.
This functionality will be available to third parties in WED 1.5 when it goes beta. In WED 1.5, if an overlay element is in the folder for an airport, it will be excluded when that airport is excluded. If an overlay element is ‘loose’ in the outer level hierarchy, it will not be excluded by airport (but will be affected by other pack’s exclusion zones).
Since gateway airports already have the objects “in” the airport folder, they are already authored to make this scheme work.
If you create your own DSFs using a low level tool like DSF2Text, the DSFLib source code, or something else crazy, I have posted the proposed schema here. That’s a technical link for people tinkering with the DSF format itself, but if you’re in that category, please do ping me to get early test materials. (The new code is also on GitHub.)
Two warnings to custom scenery authors: if you are creating a custom airport scenery pack, especially payware, please read these very carefully:
- This is not an invitation to stop using exclusion zones. There are plenty of scenery packs in the wild that do not have their objects tagged by airport, as well as autogen and all sorts of junk that can be under your payware. If your airport doesn’t have an exclusion zone and it conflicts with another pack, it is your fault. Go add exclusion zones, like I told you to do years ago.
- If a scenery pack from X-Plane Airport Gateway is removed by your pack (by airport ID) then our exclusion zones are removed too. This means that if trees on the runway have been removed by an X-Plane Airport Gateway airport, you will no longer get those exclusion zones for free. You must exclude those trees yourself! (If you put exclusion zones in from point 1 this is a non-issue.) Test your airport with global airports enabled and disabled to make sure your pack is good.
* As a side note I consider it a real problem that airports get uploaded and shared with the community under licenses that don’t allow for abandon-ware to be maintained. It’s clearly the right of the author to use any license you want, but as a community I hope we can encourage freeware authors to use a permissive open license.