After working on this issue with Ben Supnik, it seem that Laminar have decided to make it harder on threaded programs to work with unsafe libraries (simplified: not thread-safe). The correct way to interact with their libraries is only through the "main thread call". Any threaded job should not interact with Laminars own libraries, ie: functions that stats with XPLM.
Here is a quote from Bens e-mail:
Wait...wait wait wait wait wait...
On 2/11/19 6:31 PM, Saar n wrote:
> So, my thoughts are, maybe the XPSDK since v11.3x is not thread safe or
> something on same lines.
Maybe? The SDK is _absolutely_ not thread safe in any way. It is
totally illegal to call us from a worker thread.
Anyway, this perfectly explains the behavior. In 11.26 we didn't screen
for wrong-thread XPLM calls - we just ran the code, and if we crashed,
the log would say X-plane and not blame the plugin. In 11.30 we early
exit to avoid crashing.
Call from the main thread!
You can see below my first findings on this change before I spoke with Ben and better understood the reason behind it.
I usually do not write bug findings regarding X-Plane, I prefer to read or share them in X-Plane Developer Blog site. But this bug wasted few hours of my life, until I figured that nothing was wrong with my code it is probably the XPSDK fault. This is how stable X-Plane library, I almost never thought that it is the root cause (really appreciate it).
So what I believe I found. It seems that when I try to probe for elevation in certain coordinates, in v11.31r1, the elevation I receive are skewed badly. I mean, when I receive the elevation on a mountain next to LOWI airport I was stunned, it just did not add-up.
I then used Google Earth to validate my suspicions and it seem that I was right, something was not right with the elevation probing. Even more, when I used the code to get elevation relative to Camera View, the elevation was correct.
With these findings, I decided that I have to test my code on X-Plane v11.26. Luckily I took a backup prior to upgrading to v11.31r1 (I did not test this on v11.30).
When I tested against X-Plane v11.26, the code returned the correct height for all cases. This led me to believe that something went wrong between X-Plane v11.26 and v11.31r1.
You should be able to see the slop at the "marker" location. You can see that the terrain is not even but slopped.
When I execute the elevation test in v11.26 I receive:
north: lat: 47.269946, lon: 11.331731, elev_ft: 2452.39
south: lat: 47.269766, lon: 11.331731, elev_ft: 2432.14
east: lat: 47.269856, lon: 11.331863, elev_ft: 2444.77
west: lat: 47.269856, lon: 11.331598, elev_ft: 2439.64
Elevation probing seem OK, and the slope I receive is: "17.62"
When I execute same code and location in v11.31r1 I receive:
north: lat: 47.269946, lon: 11.331731, elev_ft: 329.456
south: lat: 47.269766, lon: 11.331731, elev_ft: 329.72
east: lat: 47.269856, lon: 11.331863, elev_ft: 329.717
west: lat: 47.269856, lon: 11.331598, elev_ft: 329.46
Elevation probing seem SKEWED, and the slope I receive is: "0.23"
I believe that you should stay away from X-Plane v11.31r1 for now until the next fix will come out.
I did open a bug request, and I hope I'm not the first one since this bug should "confuse" many plugins that based their information on elevation probing.
Have a great day