X-Plane 10.20 rc2 is out – just a few crash fixes and the final code to support Lua-based add-ons.
If you make a third party add-on, please: go try your add-on with 10.20 rc2 now!
If we don’t find any new bug reports, 10.20 will go final next weekend.
Edit: the Kingair is, weirdly, missing a small panel of its fuselage in the right rear corner. Tom has already edited the file and I’ll post it shortly. I’m going to let the RC sit for a day or two to see if anything else washes up.
Here’s a rough road-map for getting X-Plane 10.20 and friends out the door:
- X-Plane 10.20: if all goes well, release candidate 2 will be posted overnight and you’ll get a crack at it this weekend. RC2 fixes a few crash bugs and sets up Lua memory allocation the way we want it to be for 64-bits going forward. (I also plan to post the rest of development materials for Lua plugins tonight.)
- X-Plane 10.21: we are planning a 10.21 bug fix release. It will include bug fixes that we have already coded but didn’t want to put into 10.20 late in the game. It will also include new apt and nav data from Robin once he gets the next release done, and possibly more autogen. (If 10.21 goes out before the next autogen drop, we’ll do a 10.22 for autogen.) We’re not looking to do anything major or disruptive in 10.21.
- WorldEditor 1.2: WorldEditor finally has some (desperately needed) time on the road map; this should allow me to close out the major bugs in 1.2 and get it posted. This is a high priority for us; we’ve done most of the work for the new airport system, but it doesn’t do anyone any good until WED 1.2 goes final. (Yes, you are reading correctly, WED 1.2 is earlier in the road map than an X-Plane release.)
- X-Plane 10.30: we don’t know when this will be or what will be in it with any kind of certainty, but there are some areas we’re looking at, like fog and visibility (where we have a mix of bugs and feature requests that might go well together). I think that even for 10.30 we’ll be in “fix what we already have” mode, not “add more stuff” mode; we want to make X-Plane 10 as stable, solid and fast as possible.
One of the goals of this roadmap is to make sure that 10.20 itself is a stable 64-bit release that authors can target and users can run. One reason why late bug fixes are going into 10.21 is to avoid delay in getting a solid, ‘final’ 64-bit release to everyone. (We also expect that at least one major bug that was not reported during the long 10.20 beta will pop up as soon as we hit “final”, hence the expectation of 10.21.)
Please do not turn the comments section into a guessing game about 10.30; we don’t have a precise list of what goes into it, and if we did I wouldn’t post it anyway, because it’s likely to change over time as we get new data.
I have some specific comments on airports and ATC, but that’ll be another post.
Posted in News
by
Ben Supnik |
A quick follow-up on yesterday’s post regarding LuaJIT memory failures on Windows:
We will be making a change to how plugins interact with LuaJIT and X-Plane for 10.20 rc2. If you have an add-on that uses a LuaJIT-based plugin (SASL, Gizmo, or FlyLua) you must get new 64-bit binaries for your add-on! If you do not get new binaries, it will only be a matter of time before your 64-bit add-on stops working.
This change is unavoidable – it either has to happen now (in RC, when only beta testers have X-Plane 10.20) or later (when we’ve shipped the product and everyone is happily flying). I think now is better — I would rather not have to do this at all, but the memory problems are not going away.
I am already in direct contact with the plugin developers who use LuaJIT to work with them on the needed changes.
With this in mind, I am hoping to cut RC2 later this week.
A quick status update on X-Plane 10.20:
- The Portuguese language bug in the installer is fixed – thanks to all of the users who helped test the new installer.
- X-Plane 10.20 rc1 has two bugs that we have fixes for: a crash when opening radio controlled planes and a crash on 64-bit Mac under heavy load with Lua-based plugins. We have fixes for both of those; the second has been privately tested for about a week.
- We have one more new bug report that I am investigating: memory failures with Lua-based plugins and Windows. This last bug (if it needs fixing) is serious and will kill our release schedule. If we don’t need to fix it, we’ll get an RC2 out shortly. I hope to have a verdict on the bug by tomorrow.
There’s a bug in the latest installer/updater: if your machine’s default language is Portugese, it will crash. I will post new installers that fix this as soon as I get back home on Monday (maybe Tuesday if the snow storm is bad enough).
For now, the sim will run, even though the updater will not.
Posted in News
by
Ben Supnik |
10.20 release candidate is out now; see the release notes for a list of changes. There are two sets of bugs that we didn’t get to:
- Some users on Windows are having sound problems; I will write more about this shortly in another post; we’ll fix this as soon as we can.
- I have a set of bug reports relating to the airplane exterior lighting; I hope to get those fixed in a 10.21 build (as well as whatever one bug gets reported the day after 10.20 goes final).
Plugin authors: if your plugin has a problem with 10.20, you should have reported it weeks ago. The 2.1.2 SDK is done, 10.20 is a release candidate, so the 64-bit SDK is ready for you and has been for a while now.
We will continue to slip additional airplane improvements and autogen into updates as we get them from our art team.
ppjoy users on Windows have been experiencing a crash on startup; this was a bug in X-Plane 10.10/10.11, induced by particular virtual HID devices that only ppjoy could make. I found the problem and it will be fixed in 10.20.
In the meantime, if you need to use ppjoy and want to work around the problem, set your hat switches to discrete directions, not analog. (X-Plane can’t use an analog hatswitch anyway; most people have this because it is a ppjoy default.)
As a side rant to ppjoy users: I was a bit horrified with the process of installing ppjoy. ppjoy is an unsigned driver so I had to turn off driver signing in Windows. ppjoy is also, as far as I can tell, not hosted anywhere official. So I had to install an unsigned driver off of a file locker onto my Windows machine with the safeties off.
To be clear, I do not think that this is the author’s fault. He is making freeware, and the only thing that would remedy these problems is money. I do not and cannot expect him to give up not only his time (to code) but also pay to solve the distribution problems of official hosting and buying a signing certificate.
Still, the process of taking off all of the safeties to put random third party binary software on my Windows box was unnerving and not something I would ever do as an end-user.
As far as I know, the ppjoy crash and the PS3 controller crash are the only two known regression bugs* with joystick hardware, and they’ll both be fixed in 10.20. (Linux users, needing to edit udev rules to use hardware is not something that we consider to be a bug – see this post.)
When will 10.20 go final? Real soon now. Plugin authors, if you aren’t already running on 10.20 betas, you should have been doing that weeks ago.
* Regression bug means: it used to work in 10.05 and stopped working in 10.10 when we rewrote the joystick code.
It’s been a slow week – I’m sick, Alex was sick, Chris is sick, Chris’s wife is sick, my wife is sick, Chris’s daughter is sick, my son is sick…basically all of New England has bubonic plague. Skype meetings sound like a 19th century sanitarium for TB patients. But we are making progress on 10.20 betas. What’s still left?
- There are a handful of new 10.20 bugs that I still hope to resolve before we go final: sound problems, Intel GPU compatibility, etc.
- The installer needs to be made 64-bit aware.
- There are a handful of authoring bugs that were present in 10.11. I may push these off to a 10.21 bug fix patch, so that we can get 10.20 out the door sooner.
Users: please stop asking your favorite third party developers when they will release a 64-bit version of their add-ons. The devs are really stuck until we finalize 10.20. If they release an add-on before 10.20 goes final and then something comes up during beta, the dev is stuck fire-drilling a quick fix of the add-on.
Thanks to everyone who offered help WRT Intel GPUs. I have been in contact with the Intel driver team and we have a potential work-around for the HD4000 GPUs crashing. We do not yet have a fix or work-around for Gen-4 (GS45 chipset) GPUs crashing.
We also do not have a work-around for black sky with Intel HD GPUs and HDR mode, but honestly if you have an Intel GPU, I recommend keeping HDR off for frame-rate reasons. (I only have the HD3000 though – it’s possible that the GPUs on the new Ivy Bridge chipsets are faster. We’ll know once the shader-compiler issue is fixed.)
EDIT: when this article was originally written, the 2.1.2 plugin SDK was not available, which caused a lot of confusion. The new SDK is now posted, and the building instructions are completely updated.
Beta 11 is out and this hopefully has the final set of SDK changes for 64-bit plugins. Besides a bunch of other fixes (see the release notes), here’s the rough state of plugins:
- 32-bit plugins should just work. If you have a plugin that worked in X-Plane 10.11 but is broken in 10.20, please report a bug – even if it’s not your own plugin! I really want to hear about any of these cases.
- 64-bit plugins should just work; if they don’t, it may be due to programmer error, so please only report a 64-bit plugin problem if you wrote the plugin.
- A new SDK (2.1.2) is cut with real frameworks for the Mac; Sandy and I spent a pile of time working on this, but I need to update the wiki instructions. Docs coming in the next 48 hours I hope.
- Name and shame is gone for linking, so the logs should be clean. If your plugin crashes, you still get named and shamed.
X-Plane 10.20 beta 9 is out and (hopefully) fixes missing library paths. Alex and I spent a good chunk of yesterday trying to clean up the tools that generate the autogen library, but it is a very complicated problem, as indicated by the 4786 distinct entries in the library.
Beta 8 and 9 introduce a change in how the rendering settings work; my suspicion is that users seeing a framerate drop in the new betas are seeing the effects of the intermediate rendering settings acting differently; the minimum and maximum for the settings should produce nearly identical results.
I’m not going to try to explain how the settings used to work – the actual results were extremely convoluted due to quirks in the engine. This change is one of several we want to make to both improve how the settings work (from a usability standpoint) and improve the look of the autogen at lower settings.
- The “objects” popup controls the amount of autogen and 3-d stuff in general. Besides adding more autogen, it adds more detail to the autogen as it appears and can even add more detail to custom scenery. (This behavior isn’t new.) In particular, if you use an a complex library element like an “AGP” scene (e.g. the control tower or FAA building) the amount of detail of that mini-scene will increase with the objects setting. The goal here is to have the objects slider control the amount of 3-d.
- The “forests” popup now strictly controls the density of all vegetation in the sim. This includes both the natural forests (.for files for DSF nerds) and the vegetation that is part of the autogen (e.g. the trees that Alex puts down on the lawns of houses). Lower forest settings tend to prioritize the rural forests over autogen trees to save framerate.
- The distance to which 3-d is drawn is controlled by “world detail distance” – this is how far anything 3-d is drawn out to. Finally with this change, this affects the forests as well as the autogen and the roads – everything runs to the same distance.
A few tuning tips:
- If you are running 32-bits, turn “world detail distance” down by at least one notch; having a shorter distance for 3-d will allow the sim to save some memory.
- If you run with full autogen, moderate forests, and highest world detail distance, you may now need to turn forests up and world detail distance down to create the equivalent of what you used to see. In older betas, the forest setting modified world detail distance in some very strange ways.
Our eventual goal is to keep the autogen base footprints even when the object count is very low; the footprints of the autogen contain views of the building tops, allowing for the equivalent of ‘orthophotos only’ for users with very low rendering capabilities. This will help avoid the ‘sea of green’ effect on lower settings. (The behavior now, where whole city blocks disappear) will eventually go away, to be replaced by the “footprint” with roofs of the city block when 3-d is turned down.
These pictures illustrate the effect of world detail distance. Note that the ground images attached to the buildings are still present even as the buildings begin to disappear with lower settings. The last picture shows the autogen with most 3-d buildings stripped away to reveal the ground tiles underneath.
As we keep working on the autogen system we’ll get more and better ground textures in place, more and better ground tiles on the autogen, and yet more buildings; the result should be a reasonably seamless urban experience at a range of rendering settings.
Some cities are “over-green” in their underlying data in the DSF – this happens when the source land class is difficult to ‘fit’ into the grid system efficiently. (Typically a little bit of vegetation or water area affects zoning and ‘greenifies’ a large area.) We will have to address this problem in DSF tile recuts. (In other words, zoning errors are a failure of accuracy compared to the source data, to be recut; adding more autogen improves plausibility by providing a wider variety of “stuff”.)
