Comments on: X-Plane 11.40 is Final

By: Steven Estes

Steven Estes — Sun, 17 Nov 2019 02:55:39 +0000

Heads up: I just filed a bug report on mic permissions. I thought the issue first appeared in 11.3, but I may have been incorrect: it may be new to 11.4. Sorry for the confusion

By: Ulrich

Ulrich — Thu, 14 Nov 2019 00:08:35 +0000

In reply to Christoph Feldhaus. While we're on it: AI vehicles drive through airport fences and through each other (seen at KBFI). And even small planes are served by big food trucks ;-)

By: Ulrich

Ulrich — Thu, 14 Nov 2019 00:03:11 +0000

In reply to xplanefan. In Linux there exists a "pmap" utility that can display all the memory areas a process uses. For example I see that .../voices/default pilot/default_pilot.zip is loaded with roughly 115MB. And I see many small rendering objects (/dev/dri/renderD128).

By: Frank

Frank — Wed, 13 Nov 2019 22:37:11 +0000

Just a quick thank you for the great work and explanation. Cheers.

By: Ben Supnik

Ben Supnik — Wed, 13 Nov 2019 18:19:49 +0000

In reply to jrKok.

Sigh…This is a known bug that will be fixed in 11.41…XPD-10382. This is why we can’t have nice things. I changed a low level routine to have slightly faster code generation as part of some work I was doing…the result is that our clamping math routine produces different results when the inputs are illegal.

As it turns out, swapped manip extrema (which is illegal in the OBJ spec) hits this case and causes “working” stuff to “break”.

I’m putting the math back the way it was and drowning my sorrows for 11.41…if we can make the obj parser more robust we may be able to get this back. The perf improvement was really tiny – it was part of an audit of all of the low level math funcs that were in a particular hot loop.

By: jrKok

jrKok — Wed, 13 Nov 2019 17:40:01 +0000

Hi Ben,
Maybe I’m wrong but has the obj8 compilation code changed in X Plane ? I ask because I’ve observed that some custom models had an issue where a switch got “stuck”. It moved once but it couldn’t be moved back. In those cases the cockpit.obj had “min” and “max” values inverted. That is the case of some manipulators like but not only ATTR_manip_axis_switch_up_down where for instance “min” is set to “1”‘ and “max” to 0. In versions lower than 11.40 this would be discarded but since about rc1 this seems to mess up the manipulator. Correcting the value in the cockpit.obj cleared the error. Of course being more strict in implementation and sticking to the syntax is what is expected. But I just wanted to put this out for 1) knowing if it is on purpose 2) letting devs know so they can easily correct their models should users complain about stuck switches since 11.40 rc1 if my observation is correct.

By: Ben Supnik

Ben Supnik — Wed, 13 Nov 2019 12:58:28 +0000

In reply to Al Sardo. Mac will use Metal natively, not MoltenVK.

By: Ben Supnik

Ben Supnik — Wed, 13 Nov 2019 12:58:01 +0000

In reply to Johan. No, this is not correct at all. There is no conversion to Vulkan for third parties. It will either work or it will not. If it does not, you can use it with the OpenGL back-end.

By: Pete Leemeijer

Pete Leemeijer — Wed, 13 Nov 2019 04:25:04 +0000

In reply to Ben Supnik. Thanks man :)

By: Al Sardo

Al Sardo — Wed, 13 Nov 2019 02:17:02 +0000

Great News! So the Mac version will use Metal, natively or will it implement MoltenVK to wrap and execute the Vulcan code on the Mac?