Americans: Go Vote!
Lines are a bit long here in Maryland, and we’re not even a swing state. Doesn’t matter! Go vote!
Lines are a bit long here in Maryland, and we’re not even a swing state. Doesn’t matter! Go vote!
Starting Wednesday I will be out of the office – Lori and I are going on a 2+ week trip to India!
So first, the obvious: your comments to the blog won’t show up until I get back and can moderate them. Similarly, I will be even less on email than I am now. I am trying to dig out my tech support emails as much as possible before I go!
I will announce this before I go: I finally got an end-to-end render of a global scenery tile using CGAL 3.3.1. Andrew did the original work on this, modifying parts of the scenery generation code to handle his NZ scenery. I’ve been working on the rest of the algorithms and finished it today.
This doesn’t mean very much immediately, but it…
The next steps will probably be to create a new release of the tool set, including perhaps a bug-fixed Mesh Tool, etc.
The 2.05 installer is now released – this is a multi-language update that fixes a few bugs and makes the map interface more usable. If you have existing DVDs, you may want to use the new 2.05 DVD installer because it scans the scenery folder very quickly when you pick “add-remove scenery”.
(The old installer would check the signatures of all scenery files – this one simply checks whether they exist.)
No URLs have changed – installers will always have the same file names and live at the same URLs; you can pick “Get Info” or “Properties” to tell their version (or run with –version on Linux).
I have a ton of emails I need to get through, so if you emailed me, I do apologize; I will try to clean out the pending tech support issues, etc. in the next week.
Sometimes I have one of those weeks where all I do is look at crashes and weird behavior. This is turning into one of those weeks. So here’s some status on the various bugs floating around.
So…you can’t necessarily tell whose fault it was from new drivers coming out, us changing the sim, etc. But…when it’s my stupid code, I’ll admit it openly – no one should think that a bunch of other smart programmers are screwing up on my behalf. (This is also useful to other apps developers, who can know that my bug isn’t the same as their bug, since my bug was in my code.)
The 921 patch is now available. This fixes the bad-alloc problems relating to complex airports.
Please note: if you have a bad-alloc crash, it could be because you are out of memory. Make sure you have virtual memory turned on, your page file is large enough, your disk isn’t full, etc. If you have a bad alloc error, try the sim without third party add-ons to see if you really are running out of memory. If you are running Vista or XP, use /3GB or the BCD – see this for more info. Basically when you are running out of memory, you either can crash on “bad alloc” if we need memory for the CPU or “we ran out of video card memory” if we can’t map geometry into virtual memory.
If you get a crash with 921 on OS X, please let me know by email! I’ve seen one of these reports.
I also have cuts of the new installer/updater suite, version 2.05 – if you are going to update, tryo ne of these:
http://dev.x-plane.com/update/installers9/stage/
The main features of the new installer are:
I recommedn the new installers for that last point alone.
There are a lot of patches coming out soon:
Why two patches in a row? Basically we did 921 rc1 a while ago, but Austin’s net connection got hit by lightning. He’s on a, um, “borrowed” wifi signal right now, and it isn’t real strong, so the 921 patch is just taking forever to post. It’s equally likely that we skip straight to 921 rc2 because we can get the translation improvements done before we even get the patch up on the server.
Now regarding French: first I must say thank you to Daniel, who is helping us with the translation…we’ve been behind schedule, and his helping us with a big block of strings is a real life saver. I must also thank my wife, who was also up pretty late working on some strings. 921 rc2 will address all other languages; we’ll do a new patch once we have complete a French translation. If this is soon, that could be 922 (another patch). If it takes a while, it’ll be part of 930 (which will have new features). Time will tell!
There is also an update coming out for the iphone soon – improvements to the UI and some framerate improvements. I believe that the iTunes store should make downloading the update pretty seamless.
After all this patching, we’re on to 930. I’m not entirely sure what will be in 930 yet, but I have already made some rendering engine changes for 930 that improve framerate.
EDIT: 921r1 is now up as a beta – so you can get it if you set your installer to “get betas”. If you have the bad_alloc crash, try this beta.
Traditionally, a pilot’s priorities are: aviate, navigate, communicate.
But that might not be true for X-Plane for the iPhone.
It’s real! And it pretty much is X-Plane – there really are OBJs and DSFs in there, as well as an ACF model, all tuned for the iPhone.
In the next few posts I’ll blog a little bit about the impact of doing an iPhone port on scenery development. The iPhone is an embedded device; if you go digging for system specs you’ll see that it’s a very different beast from the desktop. The porting process really helped me understand the problems of the rendering engine a lot better, and some of the techniques we developed for the iPhone are proving useful for desktop machines as well.
I just received a series of reports today that certain converted scenery will cause X-Plane to crash with a “bad alloc” error. Basically, this couldn’t have hit us at a worse time. The final 920 was cut a week ago. We physically can’t recut; Austin is on the road, and I am knee deep in it. But there is a possible work-around, and there will be a patch. Here’s the whole situation.
What is a Bad Alloc?
A bad alloc error is an error that comes up when X-Plane runs out of memory. This can happen for two reasons:
The first case is by far the most common – you’d only hit the second if you are on Windows with a fixed-size (but small) page file. (Hint: if you have a fixed size page file, make it big!)
X-Plane can run out of memory for many reasons – everything that runs in the sim uses memory, and the amount used depends on what area you are in, what rendering settings you pick, and what third party add-ons you use. While I’d like to someday reach a point when the sim tells you gracefully that it’s out of memory, it will always be a fact of life that at some point (hopefully an absurdly high one) the amount of stuff you’ve asked X-Plane to do will exceed how much memory you have.
(If you are thinking 64 bits, well, that will just change the problem from a crash to a grinding halt when we run out of physical memory.)
We see bad allocs when there are too many third party add-ons installed (XSquawkBox is a particular pig because it loads every CSL on startup), too complex scenery, and it can also be caused by drivers not efficiently using memory. (This is particularly a problem on Vista RTM.)
The Bug
When X-Plane creates a curved airport taxiway, it allocates a temporary memory buffer to hold the intermediate product of the pavement. The size of that buffer depends on the complexity of the curve it is processing and a constant, based on the maximum curve smoothness.
In 920 I provided an option to crank up the curve smoothness in X-Plane. In the process, I increased that constant factor by 4x, which causes X-Plane to hit its memory ceiling on layouts that used to be acceptable. You’ll see this problem more often on:
What really suckered us about this bug was that it comes in a form that looks almost the same as a driver issue we’ve seen with ATI drivers on Windows — we’ve seen strange forms of memory exhaustion on ATI when shifting scenery with high rendering settings. So we didn’t realize that this was something new until G5 users reported the bug (making us realize it wasn’t a driver thing).
What To Do
The bad news is that we can’t do an RC5 – we’re out of time. But – there will be a patch – relatively soon. This bug is on the short list for a patch to fix 920.
In the meantime, there is actually a work-around. By coincidence, some of the internal rendering engine constants are viewable via the “private dataref” system — basically a series of datarefs in the sim/private/… domain that I use for on-the-fly debugging. The dataref that matters here is:
sim/private/airport/recurse_depth
If you load up DataRef Editor you’ll see it has a value of 12 . That’s too high. Changing it to 10 will allow otherwise problematic airports to load.
I will try to post a plugin in the next 10 days that sets this dataref to 10 on startup, effectively patching the problem. This will also limit the maximum smoothness of curves – but my guess is that if you see the crash (not all users do) then you can’t run on the max airport curve setting anyway.
Of course the next patch will contain a real solution: a more efficient memory allocation scheme!
Two random and unrelated notes:
First, RC4 is going out as is, despite the engine modeling changes being incomplete. Basically we now have a more sane approach to the engines themselves, but no FADEC control. FADECs are on the short list for the next update. Sometimes we just run out of time – not every release can have everything.
Second, a note on autopilot customization – I am party to a fair number of questions about whether the plugin system can be used to make subtle changes to the autopilot logic. The answer is of course: no. If you really want something different for an autopilot, you’d have to replace the entire “top-half” set of logic and drive the flight directors yourself – in this situation you are responsible for:
But you are not responsible for driving the trim and yoke, which are done by you setting the flight director.
Why can’t you just override one specific behavior? It’s an issue of infrastructure.
Fundamentally, the autopilot only does a few certain tricks. If it were capable of doing customized behaviors, you’d already see it, in the form of a dataref or (more likely) a Plane-Maker setting. Basically there is no generality to the autopilot that we secretly have inside the code but don’t expose.
Will there be a more general autopilot someday? Maybe – I don’t know, I don’t work on that code. But the plugin system has always aimed to make it possible to do anything, but not necessarily easy. In particular, the plugin system doesn’t aim to make your development easier by recycling the simulator itself as a convenient library of lego bricks. In the end of the day, X-Plane is an application, not a library. If it were a library, that would be lots of fun for third parties, but it is not.
I don’t like to delete/reject people’s comments, but I do not want new users to find this blog, see tech support requests, and add their own, only to have them sit unanswered for, well, ever.
If you bought X-Plane from Laminar Research, the tech support contact info can be found here:
http://www.x-plane.com/contact.html
If you bought X-Plane in a store, the distributor will have their own tech support contact info on the box.
From this point on, I am going to reject requests for tech support that come in the comment box. If you need help with X-Plane, use the email or phone number found on the contact page above!