In my previous post I mentioned that re-saving your aircraft in Plane-Maker from X-Plane 10.45 would opt you in to the new fixed torque model.
I’ve talked about this before, but it might bear repeating now:
Please do not ship an aircraft saved with a beta version of Plane-Maker. Instead wait for X-plane to go final or use the previous non-beta version of X-Plane.
The problem is that file formats change during beta and if they do we do not provide compatibility; the file format is only “for real” when beta is over.
So if you need the torque bug fix, plan to ship your aircraft in a week or two when 10.45 beta is over. If you need to ship now, use Plane-Maker 10.42. Test against the beta, but don’t save using it.
X-Plane 10.45 beta 1 fixes a bug in X-Plane’s flight model where props applied too much torque to the aircraft. The effect is most noticeable on single engine aircraft where the prop torque is applied along the center of the fuselage.
Authors: in order to have the new correct torque applied to your aircraft, you must resave your aircraft in Plane-Maker 10.45. When X-Plane finds an aircraft authored with an old Plane-Maker, which includes all existing aircraft already shipped, we preserve the old torque behavior.
We put in this compatibility because some aircraft have plugins and other work-arounds that try to get correct flight dynamics assuming X-Plane will apply too much torque. If we were to apply the fix to these planes, they’d then have too little torque (because we’d apply less torque and the work-around would already be in place). So this is an opt-in fix.
Authors: if you use Plane-Maker 10.45 to work on your aircraft, you will be opted in to the fix! There is no way to work on a new aircraft and preserve the old torque. Our thinking is: the old torque calculating is physically wrong, so we’re not letting anyone preserve this mistake when working on a new aircraft.
So when you bring your aircraft in for its next feature update, note that you will be getting the torque fix and you should make sure the results are useful.
Since El Capitan came out, SASL has been crashing on quit when used in aircraft with customized sound. While I work on neither SASL nor El Capitan, both are (at least partly) open source, so I spent a few hours yesterday and located the bugs.
The good news is: this bug is fixed in SASL version 2.4. The bad news is: you’ll need to make sure the aircraft you are flying is using SASL 2.4 – and this applies to every aircraft that you have that uses SASL.
If you develop an aircraft using SASL, you can get the latest free version of SASL here. Note that this new version is apparently 64-bit only.
If you are using a freeware aircraft that is no longer supported, I think you could theoretically drop in the new SASL and see if it fixes things. If the aircraft is payware, the aircraft author might not be thrilled to have to support a “modified” aircraft and might prefer to do the upgrade in-house.
If you are a developer of SASL or you use OpenAL, you can read the gory technical details here.
There are a number of changes to how X-Plane 10.22 beta 1 handles memory for LuaJIT plugins.
Windows and Linux 64-bit: X-Plane Manages Memory
Previously, 64-bit Windows and Linux LuaJIT plugins had to allocate their own memory, and often they did not succeed. 64-bit LuaJIT can only use certain special areas* of memory; if, by the time a LuaJIT-based plugin loads, some other code has used all of that memory, then the LuaJIT plugin cannot operate.
With 10.22 beta 1, X-Plane pre-allocates as much low memory as it can and then provides it to LuaJIT plugins on demand.
This change should fix problems where LuaJIT-based plugins run out of memory, fail to load, etc. on Windows with lots of scenery packs and rendering settings cranked up.
If you ship a plugin that uses LuaJIT, make sure your plugin can use the memory provided by X-Plane. The process for doing this was defined during the X-Plane 10.20 beta and has not changed, so plugins that are coded correctly will just work.
OS X 64-bit: Crash Fix
Previously for OS X, when a LuaJIT used up all available low memory that X-Plane had reserved, X-Plane would crash. This was a bug in our code; X-Plane now correctly simply tells the plugin “sorry, we’re out of memory for you.”
I have said this before in forum posts and I will say it again: your plugin should not exhaust Lua memory! There is typically over 1 GB of LuaJIT memory available; if your plugin exhausts it all, your plugin is doing something wrong.
So it’s good that this won’t crash, but if there were plugins that were causing this crash, those plugins probably need to be carefully examined – their memory use was way too high!
New Stats to Monitor Memory Use
There are two new “stats” in DataRefEditor (pick the “show stats” sub-menu option) for Lua memory use: lua/total_bytes_alloc and lua/total_bytes_alloc_maximum. The first one tells you how many bytes of memory all Lua plugins are using, the second shows the highest memory allocation ever recorded. A few notes:
- This only measures memory use provided by X-Plane. So 32-bit plugins will show “0” for both, because in 32-bit plugins, X-Plane does not provide memory to Lua.
- Lua is garbage-collected, meaning it allocates memory for a while, then periodically throws out unused stuff. So it is normal to see this value slowly rise over time, then periodically drop down by quite a bit. It is not normal to see these values increase indefinitely without ever dropping down.
- If your 64-bit Windows plugin uses LuaJIT but registers “0” for lua/total_bytes_alloc, your plugin is not getting memory from X-Plane and is not working correctly; fix your plugin ASAP!
- This memory includes allocations by Lua scripts. It does not include memory for textures, sounds, and other “native” resources provided by SASL or Gizmo. So you should not see a 4 MB allocation just because you made a 1024 x 1024 texture, for example.
* The lowest 2 GB of virtual memory, to be specific. Most other code running in X-Plane (the sim itself, the OpenGL driver, OpenAL, the operating system, other plugins) can use any memory, but they tend to consume some of this “LuaJIT-friendly” memory during normal operations. Thus X-Plane’s strategy is to pre-allocate the LuaJIT-friendly memory and reserve it only for LuaJIT use.
X-Plane 10.22 Beta 1 is available now (release notes, bug reports). To get this beta you’ll need to check “Get New Betas” in the X-Plane 10 Installer’s update screen.
This is a very small bug fix patch; there will not be an art asset update, and we’re only including three fixes that we think are critical enough to release ASAP, as well as support for the latest Xavion iPad app.
I will comment on Lua memory allocation in a separate post.
Landing Gear Problems
Plane-Maker 10.21 has a bug: when you save your airplane, the weight distribution coefficients for landing gear are calculated incorrectly, causing the plane to tilt or lean on the runway. Astute users noticed that resaving the plane in Plane-Maker 10.20 fixed the problem.
This bug is fixed in Plane-Maker 10.22; if your plane has “the leans”, just re-save it in Plane-Maker 10.22 and the problem should resolve itself.
This bug was always a bug in Plane-Maker, not in X-Plane itself; airplanes whose data was not saved incorrectly would fly correctly in 10.21, which is why it took a while for the bug report to get to us.
First: let’s agree to disagree re: copy protection. No one likes copy protection, and we can all agree that copy protection is always imperfect. (That is, it never avoids annoying users completely and it never stops piracy completely.) Users who buy products and the companies that sell them often disagree about where to draw the line between deterrence and annoyance.
So please: no rants about how awful DVDs are in the comments section. The goal of this part of the post is to explain what we fixed so that users who have seen a known bug can have better situational awareness.
X-Plane 10 “remembers” that you have inserted X-Plane DVD 1 recently, so that you do not need to have the DVD constantly in the drive to fly. Right now X-Plane needs to see DVD 1 (for each product you purchased) every seven days or so.
Every now and then we get a bug report from a user where the process of saving the DVD information fails; due to a bug in X-Plane 10.21 and earlier, when this process fails, the DVD would not enable scenery loading at all and the user interface would tell a global scenery user that a regional DVD was found. This was very confusing and also annoying (since it stops paying customers from using the product).
The bug in X-Plane is fixed in 10.22; furthermore if the preference-saving process fails we now put up a message for the user to contact tech support; previously it was a small item in Log.txt. If this preference-saving process fails, we want to know about it and fix it. (So far the only cases we’ve seen are Hackintoshes with hardware configuration issues and one case of a borked network preferences file.)
Water, Water Eveywhere
There is a separate bug in the copy protection system that I couldn’t fix for 10.22; we’ll revisit this issue for 10.30. The issue is this:
- When X-Plane needs to see your DVD to get out of demo mode, it tells you after you have started your flight.
- By that time you are on a runway that is all water.
- When you insert the DVD, does not reload scenery; you have to go to another airport and then come back to your original airport to “force” a scenery reload.
This behavior is confusing – X-Plane says “now you can fly anywhere in the world” but where’s your scenery? We get a fair number of tech support calls about this. The problem is that if we reload scenery when the DVD is inserted and your airplane is on the runway (in water-world) then once scenery is reloaded your aircraft is underground and your aircraft is destroyed. So a fair number of things need to change (e.g. when we check for the DVD, what we do when we find it) to fix this use case. That’s too much change for 10.22 and will have to wait for 10.30.
If your add-on uses LuaJIT (e.g. via SASL, Gizmo, FlyLua, or directly) then this tool may help. It’s a special build of X-Plane 10.21 for 64-bit Mac that can show total Lua memory use. Use DataRefEditor and filter on “lua” to see the numbers.
Since Lua uses garbage collection, you’ll see the number rise up and then “fall” periodically as garbage gets cleaned up. Non-Lua allocations by plugins are not counted.
If you use LuaJIT in your add-on (or a plugin that uses LuaJIT), please try to keep the amount of Lua memory used below 300 MB or so – more is available, but if you use it all, your plugin won’t inter-operate with other plugins.
That got your attention, eh? Sorry, this is not a tip on how to tune your X-Plane system; it’s a tip for aircraft authors to make sure their 3-d cockpits are running at maximum performance.
Prefill is when X-Plane blocks out the clouds that will be behind the airplane cockpit. The biggest cause of GPU slow-down is cloud rendering, so reducing the area that the clouds have to fill is really important.
In the 2-d cockpit, X-Plane pre-fills automatically. But in a 3-d cockpit, the airplane author has to specify which objects should be used to pre-fill.
Aircraft Authors: go watch this video or read this page to learn how to set up pre-fill in your aircraft! If you aircraft has a 3-d cockpit this optimization is very important!
We have received a number of bug reports on the livery system in X-Plane 10, as well as complaints from both users and authors about how the system works. This post describes what I am thinking for liveries; if this proposal seems hair-brained, the comments section would be a good place to counter-propose.
Two notes on UI discussion before we jump into the details:
- We hate check-boxes. If the UI debate is “which is better, UI A or B”, then the answer is pretty much never “let the user pick A or B with a check-box”, because the point of UI is to present the program in a human-friendly manner. Having two different UIs with selection forces the user to become the UI designer, which is inherently harder. So while we don’t have zero check-boxes in our UI, we really try to keep the ‘have it your way’ stuff to a minimum; X-Plane is a product for sophisticated users and if we put in a check-box every time we get a request for one, the product would be absolutely unusable.
- In arguing for UI, describe what you want to do, not how you want to do it. If you describe an implementation but we can’t do the implementation, the discussion is over. If you describe what you want to do, we can find several implementations and pick the best one.
As of X-Plane 10.11, you can:
- Select your livery when you open a plane using Open Aircraft…
But you cannot:
- Change the livery without reloading the airplane, mid-flight.*
- Select your livery from the Quick Flight dialog box.
- Change your livery quickly (since a plane reload is slow).
- Change which livery the QF dialog box picks for you – it always pick “no livery” (that is, default paint).
These first two bugs go hand-in-hand. Because you have to reload the plane to change liveries, you lose the initialization that Quick Flight may have done for you.
* There is one bug to note: if you go to the open aircraft dialog box, select a different livery and hit cancel, X-Plane will change your livery on the fly but not reload the plane. Some users have noticed this and use it as a back-door way to change livery mid-flight.
For the short term, I am converting the bug in the Open Aircraft dialog box into a feature – the dialog box will have a “change livery and keep flying” button to change your livery on the fly, and the “cancel” button will not unexpectedly change your livery. Thus the functionality of the old “open livery…” v9 functionality will be part of “Open Aircraft.”
This isn’t perfect, but it at least addresses the issues of changing liveries quickly, or changing them while flying, without having to know about and use a hidden UI bug.
For the Future
There are more features we’d like to do in the future:
- Have a dedicated livery-change UI again – perhaps one that ‘floats’ over the main window while you fly, so that you can see the liveries as you click on them. This would be a quicker way to rapidly preview a large number of liveries.
- Remember the last user selected livery in the per-aircraft preferences (along with quick-look keys) so that if you go to open an aircraft and don’t do anything else, we can pick the last livery you used.
- Someday have ‘drill down’ functionality in the Quick Flight window so that you can set more detailed info about your plane (livery, weight and balance, fuel, weapons) and then go back to the main QuickFlight window. This is a long ways off though.
None of this is going to make it into 10.20 – I mention it only to explain where we’re trying to go – the change for 10.20 are designed to not interfere with this future work. The future work is all based on user selected livery choice, with preferences an easy selection.
Livery Choice in Plane-Maker
This finally brings me to livery choice in Plane-Maker. I have always considered this a bit of a weird feature; it is inoperative in 10.20 and we are looking to get rid of it permanently – that is, setting a livery in Plane-Maker has no use in any of the above plans. Our view:
- The first livery you see if you first open a plane for the very first time in QuickFlight will be the default one.
- Preferences should record the users choice of livery, and this should be done entirely from X-Plane. It should not be necessary to open Plane-Maker to change livery preferences, any more than Plane-Maker is needed to change rendering settings or joystick preferences. User customization should be 100% in-X-Plane.
As I said before in the top of this article, if this seems half-baked to you, please describe what you want to do, not how you want to do it. And please understand that when it comes to UI, less is more; we need to identify a small, highly leveragable set of UI options to cover a wide variety of features. We don’t want to have 6 ways to do everything!
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.)
Conventional 3-d games like first-person-shooters and racing games are just full of cheats in the rendering engine. And that is not a bad thing! By cheat I mean they find clever ways to optimize performance that make the game look good while doing less work. The result: better framerate, better graphics.
I look at these games with a bit of envy because those cheats are often inapplicable to general purpose flight simulators for two reasons:
- The unrestricted viewpoint of a flight simulator is incompatible with a number of optimizations that on-the-ground or movement-constricted games can apply.
- Since a lot of our content comes from a third party, we can’t apply restrictions and optimizations across the entire set of content for the sim.
Despite these limitations, rendering-engine specific optimizations are beginning to creep into X-Plane as the engine becomes more powerful. These options and optimizations are unsurprising to anyone used to making 3-d game content but new to X-Plane itself.
What Is a Light Group?
Light groups are a
cheatoptimization available in many 3-d rendering engines. The basic idea of a light group is that the author of 3-d content can create 3-d lights, meshes, and then specify which lights apply to which meshes.
There are two big advantages to light groups:
- Lights are expensive in traditional (non-deferred) rendering engines; by restricting which lights affect which objects, an artist can reduce the average number of lights applied to their 3-d meshes, which is good for framerate. (Using light groups to remove lights from objects that are out of the light’s range can be done automatically by a pre-processing tool.)
- Lights in games often do not cast shadows, either because the engine can’t support this (this is the case for X-Plane now) or just because shadows are expensive to generate. With a light group, artists can get correct results without shadows by simply marking geometry that is shadowed by the light as not in the light group.
As an example of the second case, imagine that you have two rooms separated by an internal wall and a powerful light source in one room. If the light source casts shadows, the unlit room will be dark because the entire room is shadowed by the internal wall. But if the lights do not shadow, the light from the lit room will “leak out” into the second room.
With light groups, an artist simply marks the second room as not being part of the light’s group, and the rendering engine doesn’t even consider the light. The dark room renders faster and has no incorrect light leakage.
Light Groups in X-Plane
X-Plane implicitly has two light groups: the exterior of the user’s aircraft, all AI aircraft and the entire world, and the interior of the user’s aircraft. In X-Plane 9, landing lights don’t light up the cabin interior, and the 3-d lights inside the cockpit don’t light up the runway or the landing gear.
In X-Plane 10.05r1 HDR mode was not supporting these light groups correctly; one obvious example was the Piaggio tail landing light spilling light on the cabin seats. This is now fixed in X-Plane 10.10. Just like X-Plane 9, your choice of “interior” or “exterior” for Plane-Maker objects matters for lighting!
Light Groups and Spill
What if you include spill manually by attaching a named light that casts spill to an object? What light group should the spill cast light on?
My idea to resolve this is:
- Spill lights attached to “exterior” Plane-Maker objects will be part of the exterior light group and only light up the aircraft exterior and surrounding scenery.
- Spill lights attached to “interior” Plane-Maker objects will be part of the interior light group and only light up the aircraft interior.
- Scenery-attached spill lights will light up everything. (Perhaps this should be “exterior” instead? I am not sure!)
For a non-enclosed aircraft (E.g. an old biplane with no cabin) you would not use the interior light group at all – everything would be exterior and all lights would affect everything.
If an aircraft has two light groups (interior and exterior) and a light affects both, you can simply include the spill light in two objects; the spills are cheap. This also means you could make effects. For example, if the spill light does actually light up the interior a little bit, rather than having the actual landing light blast the cabin with directional light, you could include an exterior spill for the landing lights themselves and a second interior spill that is omnidirectional, dimmer, and tinted, to represent the reflected light that makes it into the cabin.