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.
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: Let me be more clear: we do not need any more volunteers! Thank you to everyone who helped. If you have this configuration, please just check the release notes in the next beta and test when the bugs are reported fixed.
If you are a Windows 7 X-Plane user with:
- An Ivy Bridge Intel CPU (in other words, one of those really nice shiny new ones)
- In a desktop machine (so that you can remove your GPU) and
You have an appetite for misery- You can spend an hour or two running test builds over the next day or so
Please email me (ben at x-plane dot com). I need to gather diagnostics on problems with the Intel HD4000 motherboard graphics, but I only have the previous-gen chipset.
This series of exchanges happens to me way too often:
User: X-Plane crashes when I change the flap setting.
Me: Which airplane does this happen on.
User: Any airplane.
Me: (Tries one of the default airplanes. Crash does not happen.) I could not reproduce this!
This has happened to me over and over again. Invariably, when told that a bug is reproducible with “any” materials, it turns out that the bug requires something specific, like a particular airplane or scenery pack.
Bugs that occur with any materials are far less common than bugs that happen to particular airplanes or scenery because bugs that happen all of the time are more frequent and easier to spot and fix.
If we ask you which airplane or scenery pack a bug happened on, or ask you for reproduction materials, it means that either:
- We already tried the bug on our own airplane or scenery pack and it didn’t happen or:
- We think it’s very likely that the bug is specific to something in the airplane, based on how the code works or
- We haven’t gotten any other reports of the bug, making it unlikely that it happens for all airplanes.
Now here’s the thing: if you have seen a bug, you saw it with a particular airplane or scenery pack. When you report the bug, just tell us which materials you used!
(One exception: if you’re using a custom airplane, try one of the defaults first – that’ll be the first thing we ask you anyway.)
I’ll end this rant with a philosophical thought: you shouldn’t report a bug as happening with any airplane unless you have tried it with all airplanes.
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.
I had a chance to work this week on the Blender 2.49 scripts; here’s a quick update on the status of the scripts and what the next steps are.
Blender 2.49 for Internal Scenery Development
Relatively early in X-Plane 10 development, we picked Blender 2.49 for our scenery development environment. We did this for a few reasons:
- The two artists doing scenery (Alex for cities, Tom for airports) both used Blender 2.49 as their primary 3-d tool.
- There was already a completely functional OBJ exporter (Jonathan’s XPlane2Blender scripts, version 3.09) that produced highly optimized OBJ output.
At the time, some developers were already migrating to Blender 2.5, but Ondrej’s exporter was only partly written. Since we didn’t need any Blender 2.5 features and schedule time was of primary importance, we decided to stick with 2.49 (to avoid the delay of our artists learning a new environment and the delay of having to wait for or develop for ourselves a complete and fully optimized exporter).
The result is that I augmented Jonathan’s scripts to:
- Fully support X-Plane 10 OBJ extensions like instancing, the new GLOBAL attributes and draped geometry.
- Export some of the other v10 data types (autogen, facades, roads). Exporting non-OBJ stuff is really complicated, and the rules to use Blender to make the right meta data are not trivial.
Other Scripts
There are other variants of the scripts floating around: both Ondrej and Ben Russell added partial manipulator export to the 3.09 scripts to help aircraft authors. Ondrej has also created a new branch (the “3.20” scripts) that target Blender 2.50 and newer.
There’s one technical point tot note about Blender that might not be obvious: for all practical purposes. Blender 2.4x and Blender 2.5x might as well be completely different programs! They have totally different scripting interfaces and they don’t even use compatible versions of the Python language. Supporting Blender 2.5x is a from-scratch effort and the scripts are totally unrelated to anything you can use on Blender 2.49.
There is no way to use my Blender 2.49 scripts on Blender 2.5; this is just a decision that the Blender developers made – they created a major fork in the Blender world. So when you read about Blender 2.49 vs Blender 2.50, consider that difference to be as major as Blender vs AC3D or Blender vs 3DS.
Recent Work
This week I had time to integrate both Ben and Ondrej’s manipulator export code into my 2.49 scripts, and I also added the remaining missing OBJ8 commands that are useful for aircraft developers. This means that my scripts are now more or less ready for aircraft use as well as scenery use, and they provide a forward path for Blender 2.49 users who use either Jonathan, Ondrej, or Ben’s scripts. This brings me closer to my goal: making a complete set of 2.49 scripts, current to X-Plane 10.
I have a few more loose ends to tie up, but I am hoping to get the scripts pushed to github for Jonathan (and anyone else who wants them) in the next week. There is still a lot of documentation to add.
I’ve been quiet on the blog both because I was out sick for a few days but also because Sandy and I have been bashing pretty heavily on plugins, trying to determine the best way to prevent plugins from conflicting with each other. The way 32-bit plugins link on OS X/Linux allows one plugin to interfere with another one’s code, which causes support problems in-field. We are looking for any way we can to minimize this for 64-bit plugins.
The short of it is this:
- Name & shame is probably not going to work for DLL linkage. (It will work if you crash!)
- Beta 11 should ship with a new XPLM implementation.
- You should not be shipping 64-bit plugins now. You should expect to retest your plugins against the next beta, and possibly even recompile your 64-bit Mac plugin
I cannot emphasize this enough: it’s not over until it’s over. Just because 64-bit plugins appear to be working does not mean that we have worked out all of the bugs and won’t be making radical changes. Once we are out of beta, things should be very stable, but during beta, this is our only time to get things right.
The last plugin ABI lasted over a decade, so it’s important that we get 64-bit right.
X-Plane 10.20 beta 10 is out, and it features a new XPLM with two new features that help plugin authors detect problems with their plugins; I am jokingly calling it “name and shame” because the new code lists the particular name of the plugin that failed. This will help plugin authors figure out which plugin failed in a multi-plugin environment and help users report bugs to the right third party developer.
- If a Linux or Mac 64-bit plugin incorrectly links against a number of common libraries, the plugin manager will log this on plugin load. This will help authors detect linker setting errors and prevent a recurrence of the plugin conflicts that are quite common for 32-bit plugins. (We do not log these problems with 32-bit plugins because they are very common; in fact, the sample templates for the SDK had the linker set up incorrectly until recently, so fixing these problems is “new” for most authors.)
- If a crash is cause by a plugin (and thus not auto-reported to LR) we log the name of the plugin that crashed.
To this second point, your plugin is charged with the crash if ones of its callbacks was running during the crash. This includes calls in X-Plane code due to your plugin. For example if you call XPLMDrawObject with a bad object pointer and the sim crashes, your plugin gets dinged.
This beta (10.20 beta 10) is the beta to test! If you have a 64-bit plugin, go test it against this new beta to see how well it really works!
