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.)
[Scene opens with a joystick being thrown across the room in frustration. Camera angle is from the ceiling looking down. A rotating and twisting view creates tension as it centers on the joystick, laying abandoned on its side as the dust settles. Cut away to a different angle. In the background is an iMac with Google Chrome open in the background just barely in focus.]
[In walks developer Chris Serio wearing a pair of Ray-Ban sunglasses. He nudges the joystick with his boot before crouching down and removing his sunglasses to get a closer look.]
Chris: “Looks like someone really had it out for this Joystick”
Ben: “Yeap…tossed it like a salad at Denny’s. What do you think ticked them off?”
Chris: “I bet Google’s behind this somehow…”
Ben: “Google? Really? I thought their motto was to do no harm?”
Chris: “On the contratry…They’re involved in everything!”
[Chris stands up and walks over to the computer…the camera zooms in as Google Chrome comes into focus on the screen]
Chris: “You see this? Chrome…that’s not a coincidence. I want the computer’s ip address…run it through CODIS. Bag it and tag it”
[The camera moves back and zooms out as Chris pulls his sunglasses from his pocket, placing them on his face as he pauses to speak]
Chris: “This Joystick killer’s about to get…..yoked”
[Cut to opening credits as The Who’s “Won’t Get Fooled Again” plays loudly]
Ok so perhaps I’ve seen too many episodes of CSI in my time…but sometimes I must say I do feel like more of a detective than a developer.
The latest weirdness with joysticks is that on Mac only, sometimes they do not seem to work at all. In the log, you’ll see an error message stating that the device could not be opened. I’ve seen it myself before and it’s odd because typically device access is shared between processes. Imagine if your keyboard only worked in your word processor because it demanded exclusive access and none of the other applications on your computer could use it once the word processor was opened. That’d be silly right?
I started killing processes on my system one at a time until the joystick finally started working again. Killing Google Chrome is what did it. Why on earth would a web browser be touching my Joystick hardware?!
After a bit of research and a run through Chrome’s source code (isn’t open source great?), I discovered a new system in HTML5 compliant browsers like Chrome called Gamepad. Gamepad allows new HTML5 pages to access your joystick hardware! Because of the Olympics, the daily Google Doodles have been little mini games which are stealing Joystick access! So Olympics + HTML5 kills Joysticks in X-Plane….amazing.
The solution is a simple change for them. They just need to pass a different flag so that they share the device with other applications. I’ve already filed a bug and spoken with the developer and the fix will likely be in Version 22 of Chrome but for now, make sure your browsers are closed if you appear to be having intermittent Joystick issues on Mac.
Sometimes reality is stranger than fiction…
***EDIT*** I do have to say, I got an immediate response from the engineer in charge of this Chrome feature and within an hour the bug was fixed and checked in for release in future versions. I can’t ask for better support than that.
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!
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. 🙂
