737NG tries XP12 :-)

[mSparks 2,094]

8 hours ago, blingthinger said:

Does XP put ALL plugin threads (including any children) to sleep while it's running the physics and render passes? In other words, could a FM plugin spawn a child thread to do some tasks and then hold at a mutex/semaphore while waiting for XP to callback?.

The impact from plugins is they each put xplane to sleep.

The SDK doesnt "help" with parallel compute at all.

This is that "cant be exaggerated gigantic pita" I mentioned. 

 the SDK functions are not "thread safe":

https://developer.x-plane.com/2019/02/the-plugin-sdk-is-not-even-remotely-thread-safe/

you can absolutely spawn threads from a plugin, and they will run at the same time as xplane.

But you cannot interact with xplane from that child thread - i.e. you cannot call any xplane functions from that thread, and xplane will only call a plugins functions sequentially from its "main thread".

the way xtlua works around this is it creates queues of "things to do with xplane", "proper name" pub/sub:

https://en.m.wikipedia.org/wiki/Publish–subscribe_pattern

the xplane main thread then only has to process what is in those queues (sleeping for around 200 nanoseconds in my earlier post) rather than sleep waiting for a plugin to finish working out all the things it wants to do.

As a side note, it will/would be a disaster if Laminar modify that for existing plugins, rather than just extend it for new ones, because plugins written under the assumption the "world is frozen in time" dont work properly if the world is no longer frozen. 

the very common "fun" example of that is unconditionally setting some dataref to a fixed value, then setting it to what you want if some condition is true.

When the world is frozen that works fine, because when XPlane wakes up and reads the value when the plugin finishes it will always be what you expect.

when the world isnt frozen xplane can get both the first value and then the value set if the condition is true, depending on when it woke up.

If developers start writing code with their own mutexes, they open themselves up to other race conditions, which can create all kinds of awful strange behaviour.

https://cloudxlab.com/blog/race-condition-and-deadlock/

Many, many projects fail spectacularly trying to roll their own multithreading/parallel compute because of this, Laminar have rolled back multithread code changes at least once that I am aware of (during the 11.30 beta run) because they were deadlocking.

[jarmstro 2,405]

14 hours ago, snglecoil said:

Oh, yeah. This definitely falls into the “what the heck were they thinking” category. No one who has ever flown an Arrow of any type would have signed off of that pile of hot garbage 😂

Well I just have to chime in on that one. To call the JF Arrow garbage is absurd. It was the first detailed GA plane for MSFS so of course there are now better flying planes. But garbage it isn't. And yes, I've flown in a P28. You want real garbage? Try the best selling/most used  airliner for XP - the JARDesign A320. Your garbage may be another man's treasure.

Edited July 23, 2023 by jarmstro

[blingthinger 649]

7 hours ago, mSparks said:

the SDK functions are not "thread safe":

This much I did know. I think XP fails to some degree now if a plugin child thread dares to call a SDK function. I was curious about the scenario of well-behaved threads that don't call SDK functions. Sounds like it's not a problem for the plugin to keep running other tasks while XP does its main thing...as long as there's no competition for cores of course. I vaguely recall that LR has discussed making a system to contain that battle too.

[snglecoil 1,828]

1 hour ago, jarmstro said:

Well I just have to chime in on that one. To call the JF Arrow garbage is absurd. It was the first detailed GA plane for MSFS so of course there are now better flying planes. But garbage it isn't.

You are right, there are many redeeming qualities of the JF Arrows. The flight model is not one of them…which is a shame because visually it is a very faithful representation of the typical Arrow in the GA fleet. I don’t typically stress about small inaccuracies in a flight model, but this is one of the few planes that, in my opinion only, is so bad that it is actually frustrating to fly. It is specifically the over-dampened elevator response. I don’t know for sure, but I suspect they were trying to overcome the “twitchiness” exhibited when MSFS launched due to inadequate modeling of inertia. It appears they severely overcompensated to the detriment of flyability and have sadly failed to adjust it in subsequent updates. So “pile of hot garbage” is a little harsh…I’m not mad, just disappointed 😉. And since this has nothing to do with XPlane, I’ll cease and desist further discussion.

[Dirk.M 84]

Ok, here is X-Plane Forum and not MSFS. Could you pelase diskuss MSFS only in the MSFS Forum

Thanks

[Bjoern 1,162]

21 hours ago, UrgentSiesta said:

As an unabashed xplane / SimCoders / AFL fan, A2A is absolutely worth the time. 

IntoTheBlueSimulation's review of the Comanche admittedly leaves me with a mild case of envy.

https://www.youtube.com/watch?v=enaAX7C4KYM

If I owned MSFS, the Comanche would likely be in my hangar by now.

Edited July 23, 2023 by Bjoern

[mSparks 2,094]

On 7/16/2023 at 8:49 PM, SAS443 said:

From a C172 pilot POV,  a big "well that's not right" is when XP12 rather aggressively slams the nosewheel of the airplane onto the tarmac while the landing itself is quite gently. (pitch attitude of 7 degrees at around 44 kts, that is perfectly fine). This is with Simcoders REP C172 (default C172 no longer does this!)
Regardless what X-plane is simulating

Knew I remembered this comment.

voilà

 

Edited October 17, 2023 by mSparks