We’re reaching the end-game with X-Plane 11.0 public betas. Right now I am working to try to solve three problems at once:
- Users of the beta really want to see rendering issues solved ASAP. Besides the constant chorus of “you know your sky looks like hell” in the comments section, the cloud code has serious performance tuning problems that I have been working on. We definitely want faster clouds in the next beta so it is a useful beta.
- We are trying to get the flight model locked down ASAP. We’ve received a number of really good bug reports in the last week and fixed a bunch of compatibility issues; the sooner we get those fixes out, the sooner authors can confirm their planes work.
- There are some issues that really need to be resolved in 11.0 because fixing them mid-version (where backward compatibility requirements are much stricter) is a lot harder.
You can see where this is going – those things are totally at odds with each other. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. If we don’t fix cloud perf, the build isn’t useful. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy.
I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. I also made some progress on cloud tuning last night; I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance.
(Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!)
I’m hoping to have beta 16 out Monday or Tuesday.
One Last Change
The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales.
X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.
The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would.
The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. if the knob is being driven by a custom manipulator or command or some internal plugin path.
This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent.
I have code that I am planning to put into beta 16 that puts the behavior back the way X-Plane 9 and earlier was: the value of these datarefs will be rounded to a grid only when Plane is done twiddling them. If you write to them with a plugin or manipulator, you’ll get exactly what you ask for – at least until the user touches a built-in panel instrument or command or some other pure X-Plane path.
This change is a little bit scary – there may be plugins or add-ons intentionally writing not-rounded values and counting on X-Plane to round them. This is a change that we can put in one beta and remove in the very next one if it turns out to cause too much chaos.**
But I am certainly hoping we can make the change – having X-Plane only round when needed makes a much better and more convenient interface for add-ons – add-on authors can get exactly what they want without having to wrestle with an octopus.
* Not impossible – just very difficult. To work around the problem, you have to inject your own values in a hook after X-Plane and manually track what the value should have been so that you don’t get fooled by X-Plane constantly snapping the value. There are a number of “unwritable” datarefs where you can write them by just shouting louder than X-Plane, but I strongly recommend against using this to make your add-on work. If you need to do this, contact us about what dataref you are fighting about – there might be a better way.
** This is going to be one of those cases where if one or two add-ons is broken by the change, we’ll declare it as “this is how X-Plane 11.0 is”, but if 100 add-ons are broken, we’ll put it back and I’ll have to go drown my sorrows. See also the usual joke about owing the bank $100,000,000.00 and all that.