“Necessary” is a tricky word. I can definitely say that it was _not_ our intention to _replace_ custom scenery with the gateway. Our goal was to create a pyramid of customization, with the gateway on the bottom, freeware in the middle and payware at the top, with increasing realism coming from increasing complexity, authoring time, and level of tools involved. The scenery system has a lot of features that are not legally usable on the gateway to support the rest of the pyramid.

Even users with X-Plane versions newer than 11.20b3 might get errors.
NEVER base any released scenery or addon on a X-Plane beta version. Anything can change w/zero forward or backward compatibility between betas and final versions.

Still, I’d like to see an OttoPilot-style (“Airplane!” movie) inflatable First Officer in the right seat, getting automatically inflated as the “AI flies your Aircraft” option is engaged…

I just hope that those flyable models would make it into X-Plane 12. I can help in the development, with my expertise on mechanical resistance of assembled lego bricks which I studied since very early in my life…

A true story…

After a nice evening flight as passenger, had landed in Abu Dhabi airport at night. After a smooth landing, the large A330 was taxiing in the dark in the direction of the terminal. Suddenly, a strong brake made the plane go full stop in the middle of nowhere, shaking passengers. A few seconds later, as the front camera was still on, we could see… A little rabbit gently crossing the taxiway…

Just to mention, the rabbit was in fault, since no rabbit-crossing marks were drawn on that location of the taxiway…

Yeah – that’s the docs that we wrote before we realized it didn’t work. There’s a doc update in progress that does fix this.

Carn’t wait to see your batman version

happy April fools

Thanks a lot for you detailed reply, I very much appreciate it! I indeed came up with the idea of the wakeup worker thread because the SDK docs explicitly mention that scheduling is allowed from any thread, mentioned in the very last part of this official page: https:/sdk/XPLMProcessing/

It even mentions the restrictions for using it from other threads, but it’s still broken as you say.

Could you please remove that paragraph so no one else tries this? It took me quite some time to figure out it’s actually impossible to not have data races with the given design. I’ll use a polling approach for now.

A follow-up: we did at one point intend to make already-created flight-loop scheduling asynchronous, specifically to allow worker threads to ‘wake up’ something inside the sim, and you are correct that there’d be a data race between the thread putting itself to sleep and async code waking it back up again. We never shipped that code – we realized after the fact that a bunch of internals of the SDK weren’t ready, so we backed away from it – you might find spurious older docs claiming thread safety to be available for a small number of calls.

Given the above data race you describe, I think such an API (wake up the worker from a thread) would be pretty useless in a lot of situations due to “lost wake-ups” – there might be work-arounds but they’d be messy to do. A more useful API would be “queue callback on main thread once”, callable from a thread, so that worker threads can queue _something_ in plugin land on demand. Since it would be “one queue, one call” there’d be no races – you’d queue as many times as you need. But that’s not coming any time soon – poll for now.