I think I forgot to blog this when it happened, but: a few weeks ago Chris shipped a free update to X-Plane 10 Mobile, completing an odyssey that has been going on behind the scenes for a few months now: X-Plane 10 mobile runs the complete desktop flight model from X-Plane 10 global. We now have one flight model to rule them all.
This is big for X-Plane 10 mobile not only because it brings a lot of additional detail to the flight model, but because it makes it possible to implement new features a lot more easily, since the complete simulator is backing these features.
How did we get here? X-Plane for the iPhone started when Austin and I ported X-Plane 9 to the original iPhone. We had a working prototype in two weeks and a shipping product in four (after which we, like, slept).
We were able to do this so quickly because the original iPhone was such a tiny device. The final program used between 28 and 30 MB of RAM total for everything. That’s all the code, all of the scenery data, all of the flight model data, all of the 3-d objects, and even all of the textures! By comparison, X-Plane 10’s startup screen is 16 MB.
Because our RAM budget was so insanely tight, we produced the product by starting with a blank slate on iPhone and X-Plane 9, and we moved only what absolutely had to be moved over to mobile. So instead of taking the whole flight model and then cutting fat, Austin copied in only what he absolutely had to have for those first few planes.
The technique worked – by keeping such tight control over what made it in, we kept our RAM budget down. But it also meant that the resulting code was pretty different from X-Plane – it was like someone took a book, cut out a bunch of words and taped them together into a short story.
Mobile devices are a lot more powerful than they used to be – at this point the top-end mobile devices are just about on par with the bottom end of desktop hardware. X-Plane 10 Mobile took a lot of technology from X-Plane 10 Global, and for the first time started giving back technology to the desktop as well.
Since the products have started sharing common code, we decided to try to re-unify the flight model (by bringing the desktop flight model as a whole to mobile); this makes it easier to move things around and saves us development time. With this process now complete, Chris will be able to move faster in developing mobile features, and we’ll be able to use more of his code.
(I like mobile as a test lab for the desktop version of X-Plane. Since the product is closed, we can rapidly prototype systems without compatibility concerns; when we’re done we can take the system to the desktop and the code will be blazingly fast because it was tight enough to run on mobile devices.)
As an example of code movement between the two products: X-Plane 10 mobile’s user interface started its life as…the panel editor in Plane-Maker! When I rewrote the panel editor (in X-Plane 8) I wrote a quick & dirty OpenGL UI toolkit to get some of the features that Plane-Maker didn’t already have.
Chris took that code to mobile and built it out into a complete user interface solution, with a richer set of classes, DPI independence, gesture support, performance optimization, and real font support.
That code is coming back to desktop, giving us things like DPI independence (4K monitor users know why this is important), beautiful typography, and the right tools to make a really great looking user interface. It’s nice to loan a piece of code to mobile and get the same code back only better. I think flight model sharing will provide similar benefits.
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.
The next beta will be out in a day or two, and it will be 10.50 release candidate 1 – that is, I’ve just finished off the last few bugs holding us back. A few quick bug notes:
- Beta 7 has a major bug in how AI airplanes can park at airports – this should be fixed in the RC, resolving a lot of confusion by authors.
- The KLAX tall-buildings-in-the-approach path are fixed – this is an art fix.
- Alignment of water reflections with the terrain is slightly better.
On this last bug, three things can go wrong with the water reflections, and only one of them is fixed:
- The Earth is round, but X-Plane has to pick an arbitrary flat plane to pick as “the water”. If this flat plane isn’t pretty close to the triangles where the reflection is closest to land, then this can cause error.
- Similarly, since the Earth is round, any time the water isn’t perfectly flat, weird stuff happens. This is normally not a problem, but sometimes if airports have been flattened this can cause crazy reflections.
- There was a small permanent offset in the reflection noise texture, partly due to mipmap rounding error and partly due to a 0.19% rounding error.
This last one is what’s fixed in 10.50 and it should remove small errors where the reflection plane is picked right in (1) and there isn’t goofy shaped water (2) – which is to say, it should help some of the time.
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.
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!).
