A new 10.22 beta is out – it fixes a crash-on-startup in beta 1 that some users were seeing.
If you can’t auto-update (because the sim crashes before the update message appears) simply run your installer, pick update, and check “get new betas”.
There are a number of changes to how X-Plane 10.22 beta 1 handles memory for LuaJIT plugins.
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.
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!
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:
* 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.
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.)
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:
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.
I posted WorldEditor 1.2 release candidate 4 a few days ago. If you are using a WED 1.2 beta, please grab this latest release candidate. If we don’t see any show-stopper bugs in a few days we’ll call it final.
Thanks to Mathias for finding and helping squash the last few bugs; the bugs in the release candidates have all been oddball cases where clicking with multiple mouse buttons induced multiple commands at the same time; the program was usable by avoiding these cases, but in the rare case WED could crash. Release candidate 4 should fix that.
The last few weeks have felt like a bit of a Nine Inch Nails song (more or less) – in my weekly status report it’s “finish X-Plane 10.21, get WED 1.2 out.” Another week, another few bugs fixed. Are we there yet?
First WED: 1.2 release candidate 3 (!) is now posted. You can see a list of changes here. Two changes may be of interest:
Anyway, please report bugs on the scenery tools bug base.
Second: we’re looking at shipping a Lua memory allocator for Windows in a bug fix release to X-Plane 10.21, rather than waiting for X-Plane 10.30.
If you haven’t been following along at home on this, the short version is:
Originally we planned to provide allocators on Linux and Windows in 10.30, but our new thinking is that we don’t want to wait that long; we have some things for 10.30 that may require a full-length beta (e.g. at least four weeks) so rather than wait for a summer patch, we’re investigating whether we can ship Lua allocation now.
This topic is confusing, so I’m going to try to summarize “how to do it the correct way” without going into “under the hood”, first.
DataRefs of the form:
sim/flightmodel2/wing/dataref_name[N]
give you information about the wings – in particular, they tell you the degrees of deflection of the flaps, elevators, etc. etc.
But what number do you use for N?
The answer is: you pick “N” depending on which airfoil you are animating!
In X-Plane, the horizontal and vertical stabilizers are “wings” too – we call anything that has an airfoil a wing. So you use this table to pick an N that matches what you are doing.
Good:
sim/flightmodel2/wing/aileron1_deg[0] # left aileron sim/flightmodel2/wing/aileron1_deg[1] # right aileron sim/flightmodel2/wing/elevator1_deg[8] # left elevator sim/flightmodel2/wing/elevator1_deg[9] # right elevator sim/flightmodel2/wing/rudder1_deg[10] # rudder
Usually not good:
sim/flightmodel2/wing/aileron1_deg[8] # aileron on an hstab?? sim/flightmodel2/wing/aileron1_deg[10] # aileron on a rudder?! sim/flightmodel2/wing/elevator1_deg[0] # elevator on a wing? sim/flightmodel2/wing/elevator1_deg[10] # elevator on a rudder? sim/flightmodel2/wing/rudder1_deg[0] # rudder on a wing??
The moral of the story is: pick an array index that matches the part of the plane you are trying to animate!
I said “usually not good” above because there are airplanes with rudders on the wings (think of a flying wing) or V-tails where the tail is half-rudder, half-elevator. The rule still applies: use the index that you are animating! So if you have a rudder on your wing, then use index 0 (left wing 1) for the left wing, etc. The important thing is to pick an array index that matches the Plane-Maker part.
If you understand what was written above, you should probably stop reading now. And if you didn’t understand it, you should probably stop reading now.
Okay then. Why are the datarefs like this? The answer is that X-Plane is a completely flexible simulator: it lets you put any control surface on any flying surface. If you want to make an experimental design with elevators on the wings, X-Plane is not going to tell you that your idea is stupid. (I might tell you that the idea is stupid, but you can ignore me, because the only airplane I ever designed from scratch in Plane-Maker couldn’t take off without JATOs.)
In particular, because any flying surface can have any control surface, the datarefs are set up with array indices for all flying surfaces for all control surfaces.
But if your airplane does not have rudders on the wings, the value of those daterfs won’t be useful – they might be ‘correct’, they might be zero, they might be wrong. Don’t trust them! Use the correct array index for the correct wing and your plane will work correctly.
WorldEditor 1.2 Release Candidate 1 is now available here. Please try it! If you have a scenery project you use, please export using WED 1.2 rc1 and report a bug immediately if the export does not work! My thanks to the testers who have helped find the bugs in the 1.2 beta run.
If we don’t find any new show-stopping bugs, WED 1.2 will go final in a week or so.
Update: There is a bug in WED 1.2r1 on Windows that stops all art assets from being found in the library. I think this is responsible for all of the bugs reported against the RC. (This was from a change I made while my PC was down that I should have checked on Windows.) RC2 will fix these bugs.
Update 2: Release Candidate 2 is now uploaded; this fixes the one underlying bug that caused a lot of reports. The bug was that art asset location from the library was broken on Windows. This caused failed previews, facades that were rings and not fences, and red question mark objects. This is fixed in RC2.
I’m not sure what will go into the next WorldEditor release, but X-Plane 10 scenery usability features are on my short list.
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!
The C: drive on my Windows box died over the weekend. I mention this so that you can ask this question now (when my drive failed) and not later (when your drive fails):
What’s your plan if you have a hard drive failure? Do you back up regularly? Could you rebuild the machine from original install disks? Would the amount of time it took to restore the machine be acceptable?* If you make backups, would the data loss between what you had and the latest backup be acceptable?
The problem with hard drives is that they fail infrequently; my wife has never experienced a hard drive failure in the decade+ that she’s owned a laptop. The result is that I’ve known too many people who haven’t given the problem of hard drive failure much thought until they had already lost data. A hard drive is an electro-mechanical device…with moving parts…that spin really really fast. It’s amazing they don’t fail more. Think about backups now!
For backup these days I like 2.5″ USB drives – they’re fast enough, small, store a ton of data, and they don’t require an annoying power cable. You could use one to back up several computers.
Nag over…WED 1.2 is almost done – the remaining bugs are Windows-related and will need to wait for a replacement C: drive, which is in transit. So perhaps we’ll get an RC1 going this weekend.
Update: when the replacement drive arrived, I used Trinity Rescue Kit to boot from CD and do a drive-to-drive copy using the tool ddrescue. I do not recommend anyone ever have “I’ll rescue my drive” as a data safety plan – it’s a terrible plan. But…in my case I appear to have gotten lucky; the rescued image is bootable. This is a nice-to-have in that it saves me a few hours of reinstalling Windows + MSVC from scratch. (On the other hand, I don’t get that minty-clean feeling of reinstalling Windows from scratch with a clean registry.) So…chkdisk is running now and I should be able to kill off remaining WED bugs “real soon now.”
* For my Windows and Linux setups (two drives that are alternately used in one machine) my approach has been “rebuild it when it fails”. For Linux this has already worked well – my Linux drive died a while ago and a total rebuild from a new Ubuntu install DVD was quite fast. We’ll see this week whether putting a Windows box back together can be done in a reasonable amount of time.