X-Plane 11.30 beta 7 is out – full notes here. Hopefully the next beta will be a release candidate; we’re down to a small number of bugs, almost all of which are in the particle system, or are regressions (meaning the behavior was fine in 11.26 and is borked in 11.30).
If you have a bug that dates back to 11.26 or earlier and it hasn’t been fixed yet, it probably is not getting fixed in 11.30 – we’re out of time with this release.
Here are a few details on bugs we’re still working on and bugs we recently fixed.
Drawing Callbacks and Plugins
Beta 6 fixed a bug where plugins would receive extra window-phase drawing callbacks if a modern plugin had a new-style XPLMDisplay window on screen. This should fix a wide variety of plugins-interfering-with-each-others-drawing bugs, particularly where the “culprit” was a new plugin and the victim was SASL-based.
As a general guideline, please use XPLMDisplay windows with the modern SDK and new APIs whenever you can – it will give you the most compatible results going forward. The only drawing phase we recommend at this point is the panel/gauge drawing phases for custom panels.
N1/N2 for Turboprops
X-Plane’s free turboprop model uses the “N1” engine dataref to represent the gas turbine speed, and ties “N2” to the compressor tied to the prop. When you turn on the starter but don’t bring in fuel, N1 will rise up to 16%, but N2 will stay much lower.
11.30 introduces the “new” free turboprop model – a second engine model that’s designed to more closely emulate the PT-6. For most of the beta, Austin was using an opposite convention: N2 represented the compressor turbine and N1 represented the prop turbine. Austin’s logic was that this was analogous to a high-bypass jet engine: N2 makes the high pressure and N1 spins the big fan-like thing.
In beta 7, Austin changed this; the new free turboprop model now follows the same convention as the old free turboprop model. This should make it a lot easier in the long term for authors whose aircraft have real PT-6’s to use the new model and take advantage of the improved accuracy.
Particles In the Cockpit
In beta 6, we fixed the bug where the new partilcle effects could not be seen from within the cockpit. This had the unfortunate effect of making them visible when the particles were inside the aircraft. This problem can be hard to avoid – depending on the wind and location of the exhaust on your aircraft, it’s possible the smoke just blows through the cockpit, making an artifact.
This is my plan for how we will ship particles in 11.30:
Particle emitters attached to objects with “outside” lighting objects will create particles that appear outside the aircraft; they will be masked out so that they don’t appear in the cabin.
Particle emitters attached to objects with “inside” lighting will be ignored and produce a log warning. We are reserving this capability for a future update when we can have interior-pass particles; for now, don’t use this capability, as you can’t know how it will look in future versions of X-Plane.
This is one of the scariest “not done yet” parts of 11.30, because the logic to control interior vs exterior drawing is very complicated – it has to take into account different hardware capabilities, different rendering settings, etc.
Particle Light Levels
I am still working with Alex on particle light levels. A recent beta included logic in the particle lighting code to match the clouds (e.g. direct sun makes them brighter) – without this, contrails don’t match the clouds.
But with this logic, particles look too dark on the ground. So we are tweaking things. The take-away here is: don’t ship your add-on with particles until we go final, as these things are subject to change during beta.
Automatic Toe Brakes and the C172
Automatic Toe Brakes is a feature where X-Plane automatically applies toe brakes when a user who does not have toe-brake hardware deflects the rudder pedals to near their maximum position. The idea is that on some aircraft, you can’t steer tightly or hold a heading in a cross-wind without the toe brakes. (This feature does not run if a plugin is controlling toe brakes or hardware is available.)
Early X-Plane 11.30 betas caused us to apply automatic toe brakes to aircraft where it was not appropriate, e.g. airliners. X-Plane 11.30 beta 6 removed this behavior from the airliners but also removed it from some third party GA aircraft where it was accidentally (but usefully) being applied.
We’re looking at this now, but at a minimum, I expect we’ll restore legacy aircraft to acting as they did before, and probably widen the steering range of our 172 a bit. I’ll write more in a separate post once we make a decision.
As some of you may be aware, Blender 2.49 is old unsupported software that is becoming increasingly less usable on modern computers. To make matters worse, authors have large projects that are currently stuck on this platform, jeopardizing their work!
We are creating a 2.49 XPlane2Blender converter inside of XPlane2Blender 2.7x, so that opening a 2.49 Blend file in 2.7x will automatically convert meshes, animations, materials, lights, textures, and XPlane2Blender properties into a modern format. This isn’t just an idea, we currently have a strong proof of concept that animations can be converted from old to new!
The 2.49 Converter Needs Your Help
The goal is
That if it exports in 2.49, it exports in 2.7x as similarly as possible. That the conversion process is hassle free and also transparent. That your work is safe and won’t be lost if there is a problem.
To accomplish this we’re going to need a lot of test .blend files and projects – to make it work for artists in the wild we need projects in the wild! We’ll take anything working and not working.
All source files will be kept secure and confidential within Laminar Research, and only used for this feature of XPlane2Blender, unless you make it open source.
Given that we’re trying to convert EVERYTHING, including materials and textures, it would also be extremely nice to have all files referenced as well.
Any description you’d like to include (preferably in a text block) would be nice too.
Again, just as with any other time someone sends me a sample to debug, it is kept secure and private, kept only for as long as needed, you can ask me to delete it at any time, and is only used for the development of that specific bug or feature of XPlane2Blender. They would never be used to develop any Laminar Research asset.
If you’re willing to submit a project to me, please get in contact via e-mail, DM, comment, or especially Github bug #397.
Update: it is a screamapiller. The lighting is missing for chunks of the runway, city, etc. When b6 fixes this, we’ll cut a Steam build.
There were some questions in the comments section about whether aircraft would lose the built-in default effects as part of the particle system upgrade in 11.03. The short answer is “no” and the slightly less short answer is “no, unless you do some stuff in Plane-Maker.” Here’s the details:
In X-Plane 11.25 an earlier, you got default effects, and there was nothing you could do about it. Every aircraft gets every effect.
In X-Plane 11.30, default effects are enabled by check-boxes in Plane-Maker’s “Invisible Parts” screen. Just like you can hide rendering of the aircraft’s physics model and replace it with OBJ models, you can replace the default physics-based effects and replace them with your own OBJ-based emitters.
In X-Plane 11.30, most of the built-in effects are built by the new particle system, but a small number (e.g. rotor down-wash) still use the old one, to take advantage of some hard-coded effects code that the new system can’t (yet) simulate.
Note that the question of how we did the default effect (new or old code) is totally unrelated to whether you (the author) want to replace it; if you turn off our effects, that check box will turn off our effects both now and when we re-implement that category of effects with new emitters (e.g. for rotor down-wash).
I still have a pile of effects bugs open, so please don’t ship aircraft based on the beta using the new particle system. (You shouldn’t ship an aircraft based on a beta anyway, but in the particle system, as of beta 5, I definitely have bugs that, when fixed, will require re-tuning of art files, e.g. lighting levels aren’t final).
X-Plane 11.30 Beta 4 does not have the performance improvements we have been working on for the last week and a half; Sidney and I found a bunch of things that are slowing 11.30 down, but we didn’t want to risk yet another broken beta. This stuff should be ready for beta 5 in a few days.
The public beta for 11.30 has been unusual in that it took us quite a few betas to get a stable non-crashing, usable beta, and during the waiting period we heard a lot of complaints from Steam users about being left out, and a lot of questions about when the beta would make it to Steam.
Here’s the problem: we don’t know the date when a beta will make it to Steam. Here’s the rough algorithm:
So in the case of X-Plane 11.30, we had to go back and recut betas due to a crash in the joystick code (beta 1), a crash when the radios were on (beta 2) and airplanes falling through airports into the abyss (beta 3).
One thing to note: if there’s a beta and it’s a few days old and it’s not on Steam, it’s because the beta has a known bug that makes it so unusable that you wouldn’t want to set your Steam install to use it. I see no reason to have a beta that crashes when you start it.
(Since we collect automatic crash reports from users, we have frequency information about how often crashes are happening, and we can identify crashes that are significantly more frequent than what we’d expect in a stable beta.)
Nicely wrapping the X-Plane Scenery Gateway’s API to get information about the airports available there. This includes the ability to download scenery packs and manipulate them just like you would an apt.dat on disk.
If you’re doing any sort of automated analysis or manipulation of X-Plane airports, this should be a huge help.
We’re pushing to get a stable X-Plane 11.30 beta 3 right now, and I think we’re making progress: Chris has fixed the crash when using the radio stack audio (this Windows-only crash was very frequent) and I have found at least one case of collapsing landing gear.
The bug report was the landing gear collapsing when taxiing on orthophoto-based scenery. It turns out that the custom DSF meshes have triangles that are duplicated and then flipped. In other words, a few of the triangles have twins that are upside down.
Here’s a pair of pictures to illustrate.
The image on the left is the “tops” of the orthophoto mesh triangles – this is what you expect to see. The image on the right is the bottoms!
Now normally the “bottom” view should show nothing – we should see only the light blue background, because the camera is above the mesh, so all of the triangle backs are facing away from us. Those extra triangles you see are copies of parts of the orthophoto mesh that have been duplicated and flipped over, so that their fronts face down and their backs face up.
This DSF violates the DSF specification, which requires all triangles to be wound counter-clockwise when viewed from above. But as of X-Plane 11.26, this wasn’t a huge problem; X-Plane blissfully ignored the flipped triangles. X-Plane 11.30 is intermittently detecting the upside-down triangles and the resulting upside-down normal vectors are making the collision physics go crazy. We should have a fix for this in X-Plane 11.30 where we filter out these flipped triangles.
One last bit of the mystery: the creation agent on both bad DSFs I have looked at is “X-Plane Scenery Creator 0.9a”. Does anyone have a link to this tool or know who the author might be?
Post script: there is a separate bug where the new physics code is reacting to DSF boundary cracks more severely than X-Plane 11.26. I had hoped this would all be one big bug but it’s not, so mesh cracks will be next on my todo list.
X-Plane 11.30 beta 2 went up yesterday – it fixes a few of our really big bugs, e.g. crashing and completely whacked out graphics. In terms of what’s next for the beta:
We should have a Steam version of beta 2 early next week. As always, Steam betas will wait until we’ve proven a beta doesn’t crash; given how easy it is to get Steam betas, we can’t risk the reputation of the product by posting broken betas. The delay for Steam betas should be days, unless the beta is broken, in which case you shouldn’t want it anyway.
We have a number of performance problems that we’re looking into now. The good news is that these are perf problems that may be fixable; the new tech in 11.30 that was suppose to be fast actually is fast, so I’m optimistic that things will run decently once we get these lumps out.
We should have beta 3 mid next week; we don’t have much out-standing in terms of flight model compatibility bugs.
If you make a third party aircraft, you should be carefully evaluating your aircraft for compatibility bugs ASAP. The window for reporting compatibility bugs is going to close next week, and if you tell us late in the beta (after the app has been available for six weeks) that there’s a compatibility problem, you may have to wait for a patch to get a fix.
Do not wait for the release candidate to check compatibility!
Art controls are internal tuning constants in X-Plane that we put in so that our art team can modify the behavior of X-Plane while they work without having to recompile the sim from source code. We leave them in the final product because they are sometimes useful to third parties, useful for in-field debugging, and because we are generally okay with people hacking the sim if they understand the limitations. X-Plane has always been a relatively open sim to play with and lots of X-Plane authors got their start just poking around. Our first instinct isn’t to encrypt everything.
We don’t go out of our way to break art controls. We don’t go in and change their names in every beta just to mess with third parties. But we also spend absolutely zero time trying to maintain art control compatibility with previous versions of the sim. Backward compatibility takes a lot of planning and effort and there’s just no way we can keep a bunch of internal tweaks the same while modifying the sim.
In X-Plane 11.30, a number of art controls have stopped behaving the way they used to. They aren’t going to go back to the way they were, because we don’t spend time trying to support hacks based on art controls. Here’s what happened and why:
As part of our work to port X-Plane to Vulkan, I rewrote the code that renders a frame in two ways:
All off-screen rendering needed to draw the frame is now done before the frame is rendered; up to X-Plane 11.25 some of this work was done as a diversion, mid-frame.
The graphic resources (mostly off-screen rendering buffers in VRAM) are allocated once when the configuration of the sim changes, rather than being allocated “just in time” when we get into a frame and realize something has changed.
Change 1 was needed to match how Vulkan and Metal handle off-screen rendering*; change 2 helps avoid stutters by allocating expensive resources early when we are not flying.
The side effect of this is that art control edits take effect only when the sim is reconsidering its graphic setup anyway (e.g. due to a window size change or rendering setting change); if the art controls change mid-frame, any code that does resource allocation ignores them because it is no longer “sniffing” for configuration changes per-frame. Other code that uses the art controls notices the change, and the result is often haywire drawing due to a half-used art control.
* This was an example of the OpenGL driver doing a lot of work for us, and hurting performance, to support an abstraction that doesn’t make sense. The real graphics card has to do real work when a rendering pass begins and ends; the OpenGL driver automatically synthesizes these rendering passes on the fly for the GPU as the app runs. Because Vulkan/Metal requires that we spell out the passes explicitly, we (the app) know exactly when we are doing something expensive (starting a new rendering pass) and we can minimize the cost.
We’ve been breaking X-Plane apart so we can put it back together with a revised flight model, shaders, joysticks, and particles. All these changes have resulted in some interesting effects at times. Here are some of the best mistakes I’ve seen as we’ve been hammering away at 11.30. Enjoy! Read More
Almost! we’ve been running a small scale private beta for the last few weeks while we finish new features and fix major bugs. I don’t want to curse the beta, but it looks like we may be able to get the public beta posted this weekend.
In the last two days we’ve had two major show-stopping bugs, but both are fixed, so we’re going to keep trying to nail this thing down and get it posted.
The public beta features not only the new particle system, available to third parties, but it is now in use for most (but not all) of the built-in effects in the sim. New Plane-Maker options let authors specify which effect categories (e.g. engine effects, wheel effects, etc.) they want to replace.
At this point it looks like we won’t have anything public for Vulkan this year, although I do think we will hit some internal milestones.