X-Plane 10.10r3 is out – release notes here. Go use Rc3! This might be the final RC – we’ll know in a few days.
Now that people are using 10.10 more frequently, I’ve received some bug reports that turned out to be problems prioritizing scenery packs.
The rules for how scenery packs are prioritized have changed! Please read this carefully!
The Rules
Old: Scenery packs are loaded alphabetically by name.
New: Scenery packs are loaded according to the .ini file in Custom Scenery
That’s pretty much all there is to it. The .ini file means that you can organize your scenery by reordering the .ini file rather than renaming packs. That in turn means you don’t have to worry about having crazy names like a_Overlay b_SecondOverlay, and you don’t have to do a massive rename of a lot of packs to get the names right.
If you don’t want our scenery, disable them in the .ini file (by replacing SCENERY_PACK with SCENERY_PACK_DISABLED). The installer won’t re-download them.
The .ini file sets the stage for a future UI or third party utilities that edit priorities, and installers that can set up custom priorities.
How Packs Are Added
When X-Plane runs, any packs that are found in Custom Scenery but not in the .ini file are added to the top of the .ini file. If more than one “new” pack is found, the new packs are added in alphabetical order (but still before every old pack).
Any missing scenery pack is removed from the .ini file when X-Plane runs.
This means a few things:
If an overlay isn’t high priority, you can remove it, run X-Plane, then put it back and run X-Plane. This moves it to the top of the list. (Or just edit the .ini file – which is probably easier.)
If you simply want alphabetical order, delete the entire .ini file – every pack will then be added on the next sim run, in alphabetical order.
You know you’ve got a good bug when a user reports that his airplane’s wing disappears when he turns the battery switch off. It turns out that this is the same bug as the 747 rolling over to the side.
X-Plane 10.10 (beta 1 all the way through RC1) has a bug in the IO code that scrambles the electrical system of airplanes on load, sliding the electrical system selections on the “bus 2” page of Plane-Maker over by one slot (except for the last two columns, which get totally scrambled). Then, due to an accident chain that would make the NTSB blush, the results pop out in the flight model, often as an incorrect roll tendency for airliners.
This (and a number of other bugs — thanks to all of the airplane authors who tried their planes and reported bugs against rc 1) will be fixed in rc2, which will hopefully come out “real soon now™”.
If your plane is saved in X-Plane 10.05 format, this bug won’t affect you – the fix to X-Plane will cause your airplane to just work. If you have already saved your airplane with Plane-Maker 10.10, you may have to re-enter some of the amperages and bus choices for your electrical system – the amount of data scrambling depends on how you used Plane-Maker. The good news is that the damage is limited to the second electrical page so at the very worst, you’ll have to re-enter some electrical system data using rc2.
Trusting Beta Plane-Maker
This bug brings up the question: how much should you trust a beta or RC Plane-Maker? The short answer is: “not very much”. Here are my recommendations.
Never, ever, ever release an airplane against a version of the sim that hasn’t gone final. Things do change in release candidates, sometimes major things when we find a bug like this. Wait until the version is declared “done” before you release your airplane!
While always saving backups of your work is always a good time, it is especially important when using Plane-Maker betas. Assume a beta Plane-Maker might erase the .acf you are working on entirely; while we’ve never had it do something that bad, it has produced incorrect ACF files before due to bugs.
Beta Plane-Makers are good for testing and trying new features and experimenting, but not for production work; wait until we go final to permanently change tool chains.
The warnings about beta go for release candidates too!
I am working on a v9 -> v10.10 checklist for airplane authors; the actual “busy work” of editing the ACF file should be less than 30 minutes per airplane if you know what new values you need to enter for parameters that need updating, so a reasonable work-flow might be to experiment with the new features and report bugs until we go final, then make the actual update on a fresh copy of your plane from an older version.
How Did We Miss This?
The sobering thing for me is that this bug has been in our betas for four weeks and (1) we didn’t notice it and (2) no one reported it. I take a few things away from this: clearly we need to test our own planes more carefully. In 10.10 we did a lot of detailed work on our own fleet, but ironically this hid the bug from us. But I also take away from this that a lot of authors don’t even look at the build until RC.
If you make an add-on, I encourage you to at least look at a few betas before RC. Even if you don’t retest every one, taking a peak early means we can fix bugs that affect your add-on early, which is good for everyone.
First, X-Plane 10.10r1 is out, at least for the next few hours; beta notes here. There are already two known issues:
10.10 is not particularly happy with current shipping ATI Windows drivers. We’re still figuring out what our best path is. We may have to disable functionality when we identify this driver set.
It turns out I broke the P-180 3-d panel, so we’ll cut a new release candidate pretty soon.
If you create add-ons, please go test this release candidate! We can’t fix bugs that are not reported, so now would be a good time to find out if your add-on is adversely affected.
Screen-Cast: Engine Settings
While the changes to the starter are pretty limited, Chris and I did spend a lot of time experimenting with the starters on a number of planes. (The starters are tuned on the 747, C90, B58, P180, and C172.) So I decided to try a screen-cast showing how to edit the starter settings.
This is not exactly the highest production value screen-cast you’ll ever see; rather it’s something I whipped out in less than an hour while the release candidate was uploading.
If this kind of resource is useful, please let us know. During the developer conferences, Austin and I did some short hands-on demos; it isn’t hard for us to turn that kind of thing into a screen-cast.
The screen cast and the blog are not meant to be a replacement for documentation; we’re working on that too. But creating demonstration materials is significantly easier in screen-cast form than document form.
This post is a summary of what is going on with the X-Plane 10 starters. I am working on a more comprehensive X-Plane 10 aircraft update check-list that will include starters.
How the Starters Used to Work
In X-Plane 9.70 and 10.05r1, the starter motor applies a constant torque to the engine to increase its RPM. As you motor the starter without adding fuel and spark, the engine’s drag will increase (due to its higher RPM – pretty much all engines move air when turned and thus have higher drag at higher RPM) and eventually you’ll hit an equilibrium: the torque of the starter exactly matches the drag of the engine and you sit there at a constant RPM. This RPM can be quite high because the starter motor can deliver its torque at any RPM.
The torque of the starter is decided by X-Plane using a formula known only to Austin and a few highly trained monkeys that have secure access to the X-Plane source code. The starter “ratio” you set in Plane-Maker is a scaling factor on that ratio. A scaling factor of 2.0 doubles the torque, and a scaling factor of 0.5 halves it.
Note that the default torque (1.0 scaling factor) varies by engine type and engine size! The justification by this is that if you don’t want to have to deal with starters, you set the starter ratio to 1.0 and X-Plane’s “natural” choice is strong enough to start your engine. In practice, the default torque is surprisingly high for jet engines, but at least they start!
How the Starters Work in X-Plane 10.10 Beta 11
Pay no attention to X-Plane 10.10 beta 11 – the changes for RC1 are quite significant.
How the Starters Work in x-plane 10.10 rc1 (coming soon!)
X-Plane 10.10 rc1 is also a torque-based model, with the starter putting out constant torque. There are two key changes:
The torque is expressed as a ratio of maximum engine torque, not a ratio of an arbitrary default torque. This change the numbering scheme! When you open your aircraft in 10.10 you’ll see the new numbering scheme. For example, the default torque in X-Plane 9 for a jet engine was 50% of engine max torque (see above that jets started really fast), so if you set a starter ratio of 0.6, the net result was 30% of max engine torque. In X-plane 10.10 you will just see 0.3. In other words, what used to be a ‘secret scaling factor’ is now baked in to your starter value.
The starter now has a maximum design RPM; past this RPM its torque will fall off – very very quickly for electric starters, less so for bleed-air starters. The default will be 100% of engine RPM, so for old planes the starter will continue to motor up to equilibrium. You can turn this number down to model the real world: real starters generally can’t put out their maximum torque up to really high RPMs.
For piston engines with electric starters, I recommend setting the maximum RPM very low and the torque fairly high; a real electric starter for a piston engine is going to put out a ton of torque to get your engine to turn over, but it just can’t run that fast.
For turbines, make sure your design RPM is well above your fuel introduction point. From what a number of people have told me, the starter can often be motored quite a bit past the fuel introduction point.
The net of all of this is: no change from 10.05 for existing aircraft, but the potential to fix a number of weird starter behaviors in 10.10 by limiting RPM. (One advantage of the RPM limit is that you can increase the starter torque without getting an absurdly high terminal RPM.)
First a quick note: X-Plane 10.10 Beta 11 is now out. What happened to beta 10? It lasted about 15 seconds, from when it went live to when I realized that aircraft were missing and code signing was screwed up.
We’ve had a few of these “beta bounces” where a beta lasts less time than a Plutonium isotope. The basic policy is this: if we cut a beta and it is live on the net at all, even for one second, and we then realize the beta is borked, we cut a new beta with a new beta number. Thus the very short life span of beta 10 – we didn’t reuse the number 10.10b10 when we fixed the problems.
Why not just reuse the beta number? Because we want to make sure that anyone who accidentally gets the broken beta gets the new beta, and to do that we have to bump the version number. Now that X-Plane auto-checks for updates, people get the new beta within seconds of it going live.
Autogen
A while ago I posted a road map for our autogen cities. Part of the work involved improving the road generation algorithm (a lot of which has been done for 10.10, and some of which still needs more work) and part involved new art assets.
Our original plan was to include the latest art assets with 10.10, but we are now planning on releasing the next round of city art assets with 10.20, the 64-bit version of X-Plane. There are two reasons for this:
The urban assets aren’t entirely done, but they are very inter-dependent. To maximize framerate, Propsman shares as much texture as possible betewen parts of the urban package, so it’s quite tricky to release part of the autogen.
The new autogen does take a little bit more memory. Not tons more, but for a user on the red line with 32 bits, upgraded autogen might require memory that isn’t available.
So rather than take up Propsman’s time finding a way to cut off and release part of the art assets, only to hear from users that thy are out of memory on OS X, we’re thinking it’s better to get on with 64-bit and release the art assets as a whole on a build that can handle them.
I think we may be able to release the new road pack with 10.10, and a number of other art assets are already in the 10.10 betas – new aircraft, upgraded global terrain, and new lights.
I just made the X-Plane 10.10 beta live only to realize that: some of the airplanes are missing. We are reorganizing where the fleet is stored, and the installer didn’t kit them properly. So:
If you ran the update and are now missing some aircraft, you can update back to beta 9 to get them, or wait until tomorrow.
A new beta will be posted tomorrow with the aircraft all present, just in their new locations.
Beta 9 is “live” again until I can get things repacked – should be less than 18 hours.
Sorry about the confusion!
Edit: And…it looks like there’s something weird going on between our software that creates the patches and Code Signing (which we’re just starting to do for Mountain Lion users). So…it might take a little longer than expected to get this beta kitted.
Airplane authors: prepare yourselves! I am now very close to closing the last of my fixable bugs filed against the 10.10 aircraft SDK. This means that the next beta will be the one to test your airplanes against. If there is a problem with your work in 10.10 and you tell us after 10.10 goes final, it may be very hard for us to fix it, so if you’ve been waiting on 10.10 betas, please go get the beta now and be ready to test shortly! If you have been waiting and letting your users try 10.10, start downloading now!
One of the main goals of 10.10 is to have the airplane authoring SDK provide similar visual results when HDR is on and off; another is to have these results remain the same for the rest of the v10 run.
Long Term Future Proofing
Lighting model changes represent one of the trickiest engine changes we can put into X-Plane. When done right they add realism, but they also fundamentally change how an author’s work looks. With 10.10, the v10 lighting model is “done” for the version run, but I don’t think it will be the final model forever. The v10 lighting model definitely contains some compromises to make translucency and v9-style authoring techniques work.
A question came up in the comments as to whether HDR mode with the deferred rendering engine and global lights might become the standard rendering mode for X-Plane 10. I think some day it may be – just as we used to have an option: pixel shaders or not, and now they are always on, I expect that most rendering innovations will eventually become standard over a long enough time frame as hardware continues to scale up.
(We have already seen this in first person shooters: the first ones to feature a deferred rendering engine often provided two rendering modes; now new games tend to be deferred-only.)
We certainly view the deferred engine and HDR mode to be preferred, and that’s why so many effects are HDR only. There are effects we can only do with a deferred renderer, and there are effects that are much cheaper to build into the deferred renderer.
Beyond X-Plane 10
If you are working on an aircraft and you’d like it to work well not only with X-Plane 10, but also X-Plane 11, here are a few things to avoid. These features are supported in X-Plane 10, but we see them as compatibility features, not “good things to use.”
Avoid using the cockpit texture without real 3-d lighting. This happens when you use ATTR_cockpit without GLOBAL_cockpit_lit. The cockpit texture without 3-d lighting is still supported in version 10 but it is not recommended, and you can get some weird artifacts. Over time these problems will get worse (as the lighting model becomes more sophisticated) and a 3-d panel that doesn’t obey the lighting model may not even be possible after X-Plane 10. Fortunately you can use GLOBAL_cockpit_lit to turn on 3-d lighting and in almost all cases it will “just work”.
Don’t use ATTR_diffuse_rgb and ATTR_emission_rgb. Instead, paint the color into your albedo and lit textures and use ATTR_light_level.
Make absolutely sure that everything translucent is marked ‘glass’, and that nothing is translucent unless there is a really good reason. Alpha is really tricky for a deferred renderer! This is good advice for v10 as well.
X-Plane 10.10 beta 10 will be out soon, as well as more detailed instructions on airplane updates.
This rather odd 747 picture is from a quick test I did to make sure the shadow options in Plane-Maker were working right after beating the shadow code silly with a hammer. The wing objects have been marked “interior only” for shadows, and since we are in an exterior view…the wings don’t cast shadows. 🙂
Now this is a totally silly way to use the feature, but there is a legitimate use: mark as many of your interior objects as “inside shadow only” as possible; for example, in the 747 the interior passenger cabin object can be marked as interior only – it doesn’t cast meaningful shadows on anything outside the airport.
By marking an object as no-shadow in Plane-Maker you save the sim the work of drawing the object, which is good for fps. If your airplane is used for an AI plane, this makes AI plane drawing less expensive.
In fact, you save it the work of drawing it multiple times. X-Plane using a shadowing technique called “cascading shadow maps”. Basically X-Plane renders different parts of the world at different resolutions, so that the closer shadows (that can be seen in more detail on screen) have a higher resolution. The user’s plane ends up being drawn in a lot of these rendering passes, and as a result the cost of high-geometry-count objects in an airplane can be amplified several times over by shadows. So savings in object-shadow count matter!
(Given the choice of turning off shadows in Plane-Maker or via GLOBAL_no_shadow, use Plane-Maker; it stops drawing earlier and thus saves more CPU.)
500. 1 to write the new lighting code and 499 to work out the gajillion ways that backward compatibility gets broken!
Suffice it to say, there are a number of major bugs with aircraft lighting and drawing in 10.10 beta 6. Beta 7 is now out and attempts to fix most of them, but I fear there may be at least one more round of fixing backward compatibility bugs in airplanes.
If you have an aircraft (built-in, third party, or yours) that looks good in either 10.05r1 or 9.70 and looks borked in 10.10b7, please report a bug, particularly if the panel and panel lighting is not working.
Why is debugging aircraft drawing so difficult? It’s a bit of a perfect storm.
The code supports a huge number of individual behaviors. A lot of the airplane drawing code was done incrementally, so even supporting ‘What v9 does’ means supporting the presence or absence of a large number of small features in every combination. You may or may not be using regions, may or may not be using translucency, may or may not be using interior lighting, may or may not be using the 3-d texture, may or may not be using generics, may or may not be using ATTR_lit_level, may or may not be using additive instrument lighting, may or may not be using auto-adjust levels, and I haven’t even started on the per-object check boxes and global OBJ attributes! (This list is a combination of flexibility, combining two complicated systems, panels and objects, and the “little at a time” approach which introduces a number of intermediate authoring modes into the airplane SDK.)
A number of these options are very quirky. Sometimes they have long running bugs, sometimes they’re limited by hardware, and often using two together produces weird behavior.
Often the quirks are useful. Rather than avoiding quirky weird behavior, lots of planes take advantage of it. Bugs become new features.
We didn’t do much in X-Plane 9 to flag, warn, or prepare authors for X-Plane 10. While we knew HDR was coming, X-Plane 9 never flagged or squawked about old authoring techniques, so a “works in v9” plane might work because X-Plane 9 supports lots of old weird stuff.
HDR rendering (with the deferred renderer) is fundamentally different from standard “forward” rendering (what we had in v9) and thus everything above has to be coded twice.
Ironically, the generous backward compatibility of the panel/cockpit authoring system in the past (including the ability to use all of the intermediate use cases of these features) has made backward compatibility worse now by making the problem space much more complex.
Unity For 10.10
As I have posted before, one of my goals is to make X-Plane 10.10 a stable and final authoring platform for v10 planes – that is, fix all of the rendering bugs so that if your plane looks good in v10, it won’t need any more updates or check-boxes changed. 10.05r1 did not meet this criteria because there are problems with airplane rendering in HDR that an author can’t work around – they are bugs in the sim.
As part of that process I am trying to create a single “right” path for authors to use the panel texture in an HDR compatible way. This consists of:
GLOBAL_cockpit_lit gives you the newest lighting path. When this attribute is present, lighting is the same for regions and no-region panels, the panel texture is fully lit by HDR, and transparency works as well with a panel as it does with a regular texture.*
With 10.10 the cockpit object has a full set of plane-maker check-boxes for control over shadowing, LOD, glass, lighting, etc., to make it consistent with the attached objects.
In 10.10 any attached object on an airplane can use ATTR_cockpit or ATTR_cockpit_region as long as the cockpit texture does too. (This means you can mae your panel texture interior for lighting but reuse the cockpit texture in a glass object for a HUD.)
These features provide for all of the authoring techniques I have seen and work with both HDR and non-HDR. Most legacy airplanes can be updated simply by adding GLOBAL_cockpit_lit to the cockpit object and confirming that check-boxes are correct in Plane-Maker.
Logging Problems
With this beta I modified the non-fatal error reporter to handle airplanes. What is the non-fatal error reporter? You know it as:
Error loading the scenery package:
/Custom Scenery/my_awesome_scenery/
The scenery may not look correct.
Please see the log.txt file for detailed error information.
The idea of this message is that it puts up a single user-readable warning that something has gone wrong, while providing details on every error in the log. Authors can see all of their problems in one load of the sim, and the single dialog box is annoying enough to users that authors can’t ignore the problems.
A few things have changed:
Airplanes can now participate in these dialog boxes, so we can give you one message that there are several problems with your airplane.
There is now a “quiet” version of this that logs without the annoying dialog box. This lets us put warnings in that aren’t annoying yet but may become annoying in the future.
The log output goes through the dev console, part of an effort to unify our logging efforts. You can reopen the log file without quitting or browse the dev console on screen.
I was asked a few weeks ago whether warnings in the log hurt performance, and my unsatisfying answer was “it depends on the warning.” But I can tell you this: any problem in your add-on that causes one of these “non-fatal error” dialog boxes should be fixed! We only use it when (1) there is a definite error in your file and thus it is not parsing properly or (2) you are using a very old technique in X-Plane for which a better replacement has existed for a while and the old technique is going away.
Don’t Overuse Translucency
One last note from the * above; this came up when Tom was working on the Baron, but I see it in third party airplanes too. While you can use translucency with the panel, I do not recommend it for building non-translucent elements.
Example: if you have an annuciator panel with warning lights that can flash then…
I do recommend that you build the panel in Plane-Maker using panel texture and multiple instruments layered on top of each other. With GLOBAL_cockpit_lit (or regions) you will get correct 3-d and HDR lighting on this panel, and it will color match the rest of your cockpit object perfect.y
I do not recommend building the annunciators out of clear areas in the panel and layering two polygons in the 3-d object (a back polygon for the back-plate and the panel texture for the front).
Why not overlap 3-d polygons? First, the OBJ format doesn’t provide a good way to overlap near geometry without risking Z errors. Second, and more importantly, you will not get correct lighting by using alpha and multiple layers. The annunciator panel should be affected by 3-d light including the flashlight and shadows from the sun; that won’t work unless you produce a single “baked” annunciator panel in your panel texture. Finally, any time you use alpha in HDR mode, there’s fine print and issues with the lighting, so use it when you really need alpha, not when you can get the job done with a panel texture!