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.
I’ve yet to see an episode of “Hoarders” with an aviation theme but apparently people with that flavor of the disease exist because I’ve gotten a chance to talk with a few who have accumulated a serious amount of 3rd party X-Plane content over the years. I’m joking of course and don’t mean to insult anyone or make light of people with illness. If you want to complain about my faux pax, contact Ben Supnik. 🙂
There is a real X-Plane issue here however. X-Plane makes no assumptions about the locations of certain types of files. Aircraft/Airfoils/Objects/Bitmaps etc are allowed to be…well pretty much anywhere in the X-Plane folder (with a few exceptions). You can argue this is silly but for historical reasons, that’s the way things are today. In order to show you a list of all aircraft for example, X-Plane has to search everywhere within its folder in order to find them all.
In prior versions, if you added a new aircraft into your Aircraft folder for example, you had to restart the sim for it to appear. As of X-Plane 10.10, X-Plane now scans for new files every time the “Open Dialog” is opened. This is done intentionally as many users have asked for this behavior. For 99% of the population, this works fine because X-Plane’s file system is relatively flat but if you’re a hoarder and you have a HUGE amount of content in your X-Plane folder, you may notice a delay when opening new Aircraft/Airfoils/Objects etc. This delay always existed but it used to ONLY happen during sim load so it was hidden.
The problem is that you have to rescan the entire file tree each time the dialog is opened. I know a lot of you developers are saying “No you don’t! You can hook the OS and look for changes since the last time and rely on your cache if there were no changes!” and you’re right…but you haven’t seen X-Plane’s File I/O code. You’ll have to trust me when I say it’s non-trivial to support this on 3 different operating systems and it will only benefit a very small percentage of users. This is not where our time needs to be spent at the moment.
In the meantime, we did want to provide a workaround but before I get into that, I want to explain things in a bit more detail. The slowness I found in the few cases that I studied were caused by 3rd party folders within X-Plane that did NOT contain any X-Plane relevant data. In other words, there were no aircraft, airfoils, objects, scenery etc in it that were being used by the sim. That means, the sim had to search through the whole thing only to find…nothing. One common folder was “Custom Scenery (disabled)” which is apparently created by a plugin out there that lets you disable certain scenery packs. This folder has now (As of 10.10R2) been added to our internal black-list so that we know to automatically skip it when searching for data. There are other folders that were already in the black-list. Here’s a current list:
Global Scenery*
Custom Scenery*
Resources
Plugins
Liveries
Cockpit
Note that the * is a wildcard so anything can appear after and still match our filter.
This is very important to note…the black-listed folders are automatically skipped by X-Plane for one purpose only…Dialog Population! Files in blacklisted folders will not appear in any “Open Dialogs”. Examples include Open Aircraft, Open Replay, Open Situation, Open Airfoil (planemaker) etc. Files in these black-listed folders can still be found by the sim for other purposes. Notice that custom scenery still loads even though it’s blacklisted, plugins still work properly etc.
What we wanted was a way for users to specify their own black-listed folders. Some users are developers and have folder after folder of development data in the X-Plane tree that they’d want to blacklist. Starting in 10.10 R2, you can do this by creating a file called:
dont_search_here.txt
in the folder that you want to blacklist. The file can be blank…its contents are completely irrelevant as only the name matters. When X-Plane encounters a folder that contains that file, it will completely give up on the folder and not scan it or scan any deeper. So any Aircraft, Airfoils, Situations, Replays, Weapons, Objects, FMS files, Waves, FDR files or Bitmaps in there will not appear in the appropriate open dialogs.
My recommendations to you:
Do your best to keep non-X-Plane specific data out of the X-Plane tree.
If you can’t or don’t want to follow advice #1, that’s fine. If and ONLY if you suspect that your data is causing X-Plane’s various “Open Dialogs” to be slow, try dropping the dont_search_here.txt into the folder if it doesn’t contain any files you want displayed in X-Plane’s dialogs.
If you’re not experiencing noticeable slowness, don’t mess with this at all! This is not a widespread problem!
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.)
I’ve yet to see an episode of “