X-Plane 10.20 beta 3 is out. This build went out without new art assets. We have a pile of new art assets waiting to go out the door: autogen from Alex, more terrain textures from Albert, an airplane upgrade from Javier, and fixes to airplanes and aircraft from Tom.
But I held them back and kept them out of this release. Why am I such a bastard?
The answer is: two complex low level changes went into this beta, and I want to capture at least one beta’s worth of crash report data to check for destabilization. The new art assets may use more memory (especially if users crank them up to see what’s going on); if we rolled everything into one beta, we wouldn’t be able to tell art-induced crashes from code-change induced crashes. So we’ll roll things out in steps. As I have said before, the purpose of betas is not to have an awesome flying experience, it’s to find bugs!
Bear in mind that not all of the bugs reported are fixed; we cut beta 3 to get these two specific code changes fixed; more bug fixes are coming soon. Please see the release notes for what is fixed. please do not re-report bugs unless they are listed as fixed but still show up as broken on your machine.
I’m hoping to get a beta 4 out over the weekend with art assets if beta 3 goes smoothly.
So What Did You Do?
So what are the two bug fixes that are major enough to warrant their own beta?
- A change in the load order between X-Plane’s sound code and OpenAL. I realized that the old way we load sound (e.g. in 10.10) makes it virtually impossible for a globally installed plugin (one in Resources/plugins) to share OpenAL, even if it follows all of the rules set out in the OpenAL plugin tech-note. This change fixes that, apparently fixes conflicts between Gizmo and SASL, and hopefully should let plugins do the right thing. Plugin developers, see here for more info. (The original load order assumed that OpenAL would be more robust to two copies being opened; it now appears that this is not the case and OpenAL can be quite picky at times.)
- The OS X 64-bit memory layout has been modified to be compatible with LuaJIT 2.0, the Lua engine inside most Lua-based plugins (e.g. Gizmo, SASL, FlyLua, etc). This does not entirely fix the porting problems developers have been seeing with LuaJIT, but it at least makes the plugins work under light memory conditions. (These plugins would fail 100% of the time in beta 2.) Here’s the technote; I am in contact with most of the plugin developers using Lua, but if you use Lua and haven’t heard from me, email ben at x-plane dot com.
These are not the only bug fixes in beta 3, but they are the two that are weird enough that we want ‘clean’ bug data, without additional art assets to cloud our view.
So: hopefully these two changes will go smoothly and we’ll get on to beta 4 and art assets soon. The artists work their butts off to create this stuff and we want to roll it out!
Will Lua Ever Work With 64-Bit OS X?
A few developers who depend on SASL and Gizmo have asked me whether Lua will work with 64-bit X-Plane on OS X. The only answer that I can give is that I do not know, but I am optimistic that we will engineer a solution. I consider making Lua work to be a very high priority.
Lua is in almost every commercial third party airplane we’ve seen in the last few years; the market has spoken and third party developers have said “we like Lua.” So I think it’s worth doing some serious engineering to keep Lua working. Making Lua work with 64-bit OS X is currently my top priority bug.
Great thanks for the info and art asset update
Happy thanksgiving to you and the team
Thanks for your continuing hard work, Ben. Particularly in making LUA work in 64 bit. It’s greatly appreciated!
Aside from all the technical + binary musings… I wanted to say that you BEN, have become an excellent blogger.
“But I held them back and kept them out of this release. Why am I such a bastard?”
To my own credit, ( ahem ) I dont really read that many blogs, but this one always has more personal touch than I would expect from bunch of programmers + their loyal yoke loving fans.
+1 🙂 LR (and Ben / Chris in particular) attitude makes a difference..
Loyal yoke loving fans!… That is me and the rest of our rowdy lot I suppose…
Overwhelming news on the art assets Ben… Oh your the bastard right!
Thanks for all the hard work and for keeping us updated! 🙂
Thanks to all X-Plane Developers for this continuing effort to make X-Plane a really advanced Flight Simulator! Taking the Simulator to 64-Bit is really appreciated for such a complex and hardware-demanding Software technology. I am not a Beta Tester but it will be a pleasure to be able to load more Planes and Objects with 64-Bit in real high rendering quality.
Suggestion: It would be nice to see a slightly different icon for the 32/64-bit XP executable. Right now, I have both pinned to my taskbar, but can’t tell the difference.
Question: Are there any performance implications we should be concerned with re: the new OpenAL methodology?
re: OpenAL, I don’t think so.
Thank you Ben for steaming forward with the development of X-Plane and for making it so enjoyable. By the way, cudos on the mountain textures, they are really coming along.
However if I may ask, we ever see:
Seasonal textures
Integration of ATIS and METAR and the ability to call them
External power option on apron
Aircraft tie down option
PS
Disregard my ignorence if one of this allready exists in XP
In advance thanks..
We may see these someday – they are not crazy features to have.
Thanks for the feedback Ben..
PS..
Is there any API or libraries available for the public in relations to either C, C++, Python or Arduino?
Ben, or anyone
now that 64bit is out and we can test it on our systems/ art assets will be soon,
do you think 32Gb of RAM is overkill and may not be helpful? I have 16Gb now, no memory crashes but some lag; probably due in part to beta, settings and hardware. I read more RAM can make things smoother and increase fps. before I buy or not buy, I wanted to check with knowledgeable users.
Thanks
32 GB will only help if X-Plane, plus your other processes, are _actively_ using 16 GB while you fly. This is exceedingly unlikely. More RAM does _not_ make anything smoother unless RAM was why you were having slow fps.
Thanks Ben
follow up:
I managed to test 32GB actually and it has helped , allows me to bump rendering up even more. extreme res too. Preserved 18-20fps over NYC with add-on scenery, HDR and night time
Memory does not seem to have much to do with the overall performance in XP.. I tend to lean more in the area of CPU render. Have my CPU clocked at 4.0Ghz and 12GB of ram running at 1600Mhz CL9.. This gives me 40+ with 10% clouds and water set to default, rest at very high and extreme..
RAM has helped me, I have a mac/ can not and or do not know how/ will not over clock it. regardless, I can have more apps going, no page outs and x-plane kept up more nicely. Guess there is no clear cut one answer. Just wanted to share my sole experience if others were wondering about more RAM
Hey Ben
I’m guessing all didn’t go as planned with beta 3, since beta 4 didn’t hit this weekend?
Yes – but not in how you think … I had a sports-related injury Wednesday night and it slowed me down more than I expected…
get well ben and best of luck to fix up beta 3 and get beta 4 assets this week would be great
I’m new to X-Plane (and an old-world, real-world pilot). Thank you for this blog and what you are doing in X-Plane with the latest Beta. Great work on both. (On my Mac? Its an ‘oh wow’ world since Beta 2. With everything loaded and hardly a tick of a strain on the 2.66/34Gb/1gb Ati – this is FLYING). So well done and get better soon. Ed.