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.
X-Plane 10.50 is now final – X-Plane will prompt you to auto-update the next time you run. Steam users – 10.50 should be posted on Steam within a day or so.
We are working now on a new beta of WorldEditor 1.5, which I hope to have in a day or two.
You can find the release notes here.
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.
Release Candidate Three is out – Steam version coming next week. I think this is going to be the final version of 10.50, mostly because I’m going to stick my fingers in my ears and ignore any more bug reports. Seriously though, if you do find a bug, please report it, we’ll fix it in a new patch.
RC3 took a while to get out because we had a number of severe bugs reported very late in the beta process. Several third party developers waited until our release candidate to even try the beta, and this has delayed the release schedule.
Third party developers: please do not wait until the release candidate to check your add-ons. Doing so means a few things:
- We might not be able to make the best fix due to a lack of time.
- If the problem turns out to be an authoring error in your add-on, exposed by a new beta, you won’t have any time to fix your add-on before the problem is revealed.
- This definitely impacts the efficiency of the entire beta process in a negative way.
WED 1.5 beta 2 will be out as soon as I can compile it.
Posted in News
by
Ben Supnik |
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.
First, X-Plane 10.50 release candidate one is now available to Steam users.
X-Plane 10.50 release candidate 2 should be out Monday for DVD and digital download users, and a few days after that on Steam. I am hoping that 10.50 rc2 will be the final build. See the release notes – the list of bug fixes in RC2 is already posted.
If you know of a bug and it is not marked as fixed in RC2, file a bug ASAP.
For users who are having problems with real weather: we are still looking into this, but the problem looks intermittent and may be a problem with the servers. We are trying to gather more diagnostics, but whenever we try to reproduce it, the servers have a good day. (These are not our servers, they are NOAA.)
Finally, we have the code done for WorldEditor 1.5 beta 2 – Ted’s fixing his last few bugs and I am hoping to cut that Monday or Tuesday.
Posted in News
by
Ben Supnik |
Our original plan for adding more X-Plane scenery gateway airports to 10.50 was to add two batches: one at the beginning of beta and one at the end.
We are changing that plan – I think our new plan is going to be an X-Plane 10.51, a week or two after 10.50 goes final, with new airports.
The reason to wait is that X-Plane 10.50 is further along than WED 1.5 – we have an RC for X-Plane but we’re still on beta 1 for WED.
New airports uploaded for X-Plane need to come from WED 1.5 (for both new features and much stronger validation checks) but they also need to come from a better tested WED 1.5. So we’ll wait for WED to be a little bit more mature.
I’ve said this before, but I’ll say it again: don’t panic if your airport isn’t going to be ready; X-Plane 10.51 will not be the last time we add more airports to X-Plane.
For now if you are working on an X-Plane 10.50-compatible airport my suggestion is:
- Use WED 1.5 beta 1 and X-Plane 10.50 rc 1.
- Don’t upload to the gateway yet.
- Do test your airport and report bugs against WED and X-Plane – especially X-Plane.
I will post here when we have a WED that we think is solid enough to upload airports with.
X-Plane 10.50r1 is out – we should have a Steam build some time this week depending on when people can get it uploaded to the servers.
For users seeing missing runways when flying, we will have a special build for you to try soon if you filed a bug report.
If you are working on a WED 1.5 airport layout, please re-try your AI traffic in 10.50.
The release notes have a complete fix list.
X-Plane 10.50 beta 7 is out. There are a few fixes that I hope make this finally a “solid beta”: no more flashing airport lights during the day, normal maps back on aircraft, and liveries should work correctly.
We have a fix in the works for tall buildings blocking the approach path at KLAX; I’m hoping to get that into beta 8 some time next week.
Creating New Apt.Dat Layouts
WED 1.5 beta 1 is out; please do not upload revised airports with WED 1.5 yet. If there are still bugs in X-Plane’s handling of the new apt.dat data, then you have no way of knowing what your airport will look like after we fix those bugs.
X-Plane 10.50 adds a new rule: AI aircraft will not be born or land at airports where there isn’t a parking spot wide enough for the aircraft to park. So if you have an airport with a 11,000 foot runway and no size-E or F parking spots, the 747 would have landed in 10.45 but will not land in 10.50.
AI aircraft will land even if the parking spots don’t match the needed aircraft type – in other words, if you have a size E parking spot for helicopters only, the 747 will still land (and try to park there). Here’s why I didn’t stop this case: without static aircraft, the equipment codes on parking spots is likely to have errors; it’s hard to know you get everything right. So if we start requiring equipment code matches to land an aircraft, we may end up with no AI aircraft at lots of airports.
Once static aircraft have been deployed and authors update their airports to use them, the equipment codes should become much more accurate, and at that point we can prevent the AI from landing if it can’t find an equipment code match on a parking spot.
We also do not limit landing by taxi route width; the assumption is that if you have a width-E parking spot, you have a width-E route to the active runway somewhere on your layout.
Starting with beta 7, you can now debug ATC AI placement decisions by setting the art control atc/debug/log_spawn to 1. After it is set, future spawning decisions will be heavily logged under the “ATC” log tag. If an AI isn’t placed at an airport, you’ll see exactly why.
Note that currently the takeoff/landing requirements for the aircraft tend to be inaccurate. (They are computed from some properties of the aircraft, not flight testing.)
Flow Problems
From my examination of the small set of airports that I run across while debugging (with something like 3000 airports, I am at best “sampling” the gateway airports), it appears that authors don’t understand how ATC flows work. We’re working on new documentation to try to explain this, and I’m thinking that some very basic flow errors could be caught by WED. For example, I saw one airport that had this in WED:
Airport XXXX
Flow "east/west"
Runway Use: 9 (arrivals, departures)
Runway use: 27 (arrivals, departures)
This is almost certainly a mistake. This is a single flow for the airport that says “when this airport is in east/west mode, aircraft may take off or depart from either runway 9 or 27!” In other words, airplanes can use the runway from either direction at the same time.
I know of no real-world example where this actually happens, and if there is one, it has to be super-rare. The author probably meant to do this:
Airport XXXX
Flow "east"
Wind rule: wind must be coming from the east
Runway rule: 9 (arrivals, departures)
Flow "west"
Wind rule: wind must becoming from the west
Runway rule: 27 (arrivals, departures)
In this case, the airport is using either 9 or 27, but not both at the same time. A few things to remember about flows:
- Only one flow is ever in use at a single time. That’s why a flow can have more than one runway.
- All of the runways within a flow are in use at the same time when that flow is in use. So never put conflicting runways in a flow!
- X-Plane picks the flow by looking at your flows in the order you put in WED. It takes the first flow where all of the restriction rules (time, wind, visibility) can be met. So put the ‘preferred’ operations for your airport first in the list.
- If you have more than one rule of a type, only one must be passed. So for example, you can have a “rush hour” flow with two time rules, and it will be picked if either is picked. So you can make morning and evening. Similarly, you can make a wind rule for “strong from the east” and “calm wind” and if either is picked, the flow is picked.
- If you provide no rule for a category, the flow is never disqualified by that rule. So if you have no time rule, the flow can be picked at any time.
Here’s two more art controls: atc/debug/rwy_flow debugs how X-Plane picks its flow – turn it on and then go to your airport and you can see in the Log why the flow was picked. atc/debug/rwy_selection shows how a runway was picked for an airplane given an existing flow.
