benrussell

I wrote the repro. It's crash, 100% of the time when the ram is released. In the meantime, it _might_ have clashed with your memory. It still remains incredibly rare that anything scripted is asking x-plane for 16mb chunks in one contiguous blob.

16 megabytes of 1024 byte chunks is easy to get to. 16 megabytes in one contiguous chunk is a lot rarer to need. The entire simulator crashed to desktop when the plugin releases the 16 meg chunk. This will happen when, say, the aircraft is unloaded. This is not a "my plugin has random weird issues from ram sharing and overwrites". The entire sim is guaranteed to crash at some point when the ram is released. As you have mistaken a contiguous chunk from a large pool of small vars I'm done here. Have fun trolling further if you must.

I haven't seen anything like it being reported and asking for a 16 meg chunk of Lua ram in one go is an exceptionally rare event on this side of the branding fence. I've run into this problem exactly once in the last 11 years of heavy Gizmo use. I think you're reporting something else. This is a black and white issue. It took me a few hours to narrow it down and I wrote a repro using a script for XLua, Laminars lua plugin.

Are you refering to the recently discovered bug that I, author of Gizmo, reported to Laminar on ~5th Feb 2021 by Slack conversation with Ben Supnik and an email including working reprodcution to the Laminar bug tracker? If so, you don't understand the bug properly. I'll give the briefest of summaries... 1. This bug is _only_ triggered if a plugin attempts to ask X-Plane for a chunk of memory that is > 16megabytes in one single request. 2. This bug was never seen or reported "in the wild" that I know of. It was detected during our pre-sales bug testing. 3. The incorrect behaviour was present inside X-Plane. There was nothing any third party plugin could do to "not be buggy" if they were using Lua. It had nothing to do with what flavour of Lua plugin you used. It didn't matter if you had only one plugin or any combination of more than one installed. As soon as that single plugin asked for and released the Lua memory block of > 16 megabytes, crash. If what I've described above -is- the bug you're referring to, please stop. You're making life harder for everyone. Bug ID; XPD-11159 If you're talking about some other bug, please let me know.

In order to place an "activation freeze" on your account and "run out of license slots" requiring intervention from support you have to re-install your OS or purchase three entirely new machines in the space of six months. Please explain how this is unfair and how you've somehow exceeded it and I will adjust my care factor accordingly. This is exacerbated by the fact that you claim that you are "coming back" to XP... this strikes me as very odd because if, as you say, you're coming back after some time, one would assume that any machines that you may have activated "in the past" would have already automatically expired leaving you with no intervention required. You bought a License to Use the software. MOST companies grant a single concurrent use license. We grant a three machine license by default. Additionally, we are working so you can de-activate your old machines at will without interaction from our support people but this, like all things, takes time and money. Thank you for your understanding, I look forward to your detailed reply.

I purchased a new dedicated Windows machine yesterday so I can investigate all bugs more effectively. I've been running X-Plane inside VMWare which is limiting at best. Previously I could tell Gizmo loaded on Windows but that was about it. Now I have a serious gaming rig for Windows/Linux dev. It's still going to take some time but we're committed to resolving this.

You'll need the exact error details for anyone to post any meaningful advice. It was probably an FMC bug with Gizmo and you're blaming FWL.

Confirm that the ground physics model is customised.

The IXEG team have implemented custom ground dynamics, not sure on specifics but it's definitely not X-P default.

IXEG systems are built on top of Gizmo64.plugin which in turn uses Lua as a scripting language. LuaJIT is enabled to make the scripts run faster. In short, yes it's required.

All these "defender" clashes are probably caused by anti-malware aggressively scanning all the LuaJIT activity going on inside the X-Plane RAM space.. LuaJIT cause a large volume of CPU instructions to be generated "on the fly" "Just In Time" for use in systems code.. anti-malware scanners are probably concerned that this might mutate into something aggressive. It won't, but it's good to know they're doing their job properly. We'll do an code optimisation pass at some point that should hopefully reduce this even further and possibly reduce the need to disable "defender" products. Thanks for your support everyone!

Correct.

We've all been at this for at least six years now. Most of us quite a lot longer than that. No ones going anywhere. You've all given us more reason than ever to be here. Thanks for everyones support.

Thanks for confirming you found a solution. Curious for more details if you'd like to share in PM.