Ben Russell

Lee has made it clear in his own way that he's not interested in contributions from me.

Thanks for taking the time to report this.

Sorry. Intel graphics chips are not supported. They're simply not capable of a reliable experience.

Bear in mind that if you download and activate the product there are no refunds. If you activate it and find that it runs very badly; no refunds.

I'm just loving opening my brand new Windows 10 machine to a freshly force rebooted desktop every morning. All my apps closed. All my work context gone. I LOVE IT. So productive. It feels just like 1994 again.

Haven't seen one of those in a looong time. Thanks Tom. Adding it to the list.

Recent builds of DRT seem to make some incorrect assumptions about the rules regarding array datarefs. I've seen some junk in log files about it throwing tantrums. I'd fix it but the project started using boost a long time ago and I lost interest.

I'm waiting to discuss this with other team members. We've seen the bug a couple of times before and I'm not sure what the solution was. While you wait, try re-installing the product.

It's funny how every day light weight meaningless chit chat about the weather with people is actually one of the deepest subjects you can start talking about... how far down the rabbit hole do we want to go?

Don't even get me started. Oh you have fifteen years of memories and _like_ the way it works? Too bad, we deleted it. Learn again.

No hackintosh here. (Zero tolerance towards piracy.) Linux. I still own a mac and will still work on macs, but their place as my primary workstation has passed. All the iCloud crap and magical files that don't really go away, yuck. ...and just because I'll be working in Linux doesn't mean we'll be supporting it to the ends of the earth. Any future Linux release will be "serve yourself" there's simply too much room to make a horrible mess. (and three million distros) ..still sitting at my iMac, probably for a few months yet.

Mac are no longer interested in serious media professionals. The MBP line up is a joke. ALL Intel "GPU" except for the highest model costing nearly $4,000. I miss the days of "Pro" in three sizes and "Student" in three sizes. (I just bought an Alienware...)

Very strange. Gizmo is showing an error that looks like it cant read from the ACF file but everything else looks in order. Did you use a different user account to install the product? Unfortunately I'm going to have to patch Gizmo a little to provide extra data to tell me what actually went wrong.

You'll be fine. We allow for activation of upto 3 machines. Your old machine registration will fully expire in six months. Result; Old machine: one dead slot. New OS installed: 2nd slot used. 3rd slot remains spare. Do take the time to get your Windows install correct before activating though. Some people seem to activate as the first thing they do on a new machine and then have "more troubles" leading to another OS install, leading to another slot being used...

Move this folder somewhere else to disable the iTow plugin; F:\X-Plane 10/Resources/plugins/iTow/

Your log files tell us what other plugins you have installed. This lets us identify patterns. Although it looks empty to you please attach them anyway.

Only a fresh install of your operating system software should trigger a new hardware ID. You can activate upto three machines by default. This is to make life easy for you, not so people can share with friends. (We will find you if you do.)

Check that your computers clock is set to the correct time and date.

I haven't bothered with overclocking for about 15 years. Is it really that hard to just clock it down to factory specs and run tests? It seems a much easier path to me than the infinite mess that is DLL hell.

Yes, it was obviously a gross simplification. If you look at error % rates there is only one fix. The user doesn't want to participate.

You're the only one reporting the problem. That makes the problem your hardware. Fun game huh?

I'll be getting some dedicated hardware for Windows/Linux plugin builds in the near future. It's a lot easier to build and test for Linux when you're not rebooting your primary machine to do it. Even with a Gizmo plugin for Linux there will probably still be some filename upper/lower case issues to deal with and X-Aviation has no plans to distribute Linux installers. All of these things can be easily worked around. Using a Windows VM to install your product and then moving the folders around is fiddly but possible.

I'm glad the extra detail helps. I figure the best I can do at the moment is try and share the insights. If it's all "geek"; well, at least it shows that I want to be open about the issue at hand and any methods we can use to resolve issues. Back to the Arduino side of things; It's far more accessible to me on every level to fix Arduino stuff than any other hardware platform. - Costs less. - Uses less space. - Repurposable. I will get to it. I have a box of Arduino hardware already.(2x Uno, 1x Mega + random sensors) It's just a matter of working through the queue.

Some parts of the SDK look like a "single call back entry point" when in fact these functions can be called repeatedly with different datarefs indicating a subtle yet important change of state. This leads to naive creation of plugins that _appear_ to only query gizmo for data once when in fact they're probably querying for everything ~five(I'm not inclined to do an audit right now to find the exact numbers) times in the space of a single frame. This leads to complications which manifest as a stack overflow. There's nothing "wrong" inside Gizmo. It works just fine with X-P, DRE, DRT and now the GoFlight Interface tools from Pollypot. The reason it explodes is because I chose optimisation and power over data safety, management and "hand holding" These third party plugins are interfacing directly with the systems that the IXEG team have written and the third party plugins are doing a crap job of it. The reason you don't see this with anyone else? They probably use the concept of data buckets. Dataref value storage that's isolated from the core of their code. It's easier to write and far more resilient to stupid plugins blasting it with unsolicited overzealous requests. There is no logic to run because the internal systems have already calculated all the values and moved them into dref containers. There's also no branching into code that relies on the underlying JIT engine with dynamic memory allocation and all the fun that brings. It's complicated. I have a good idea of what triggers the issue and it's not something I need to fix... or probably even can fix now that we have multiple premium products built on this. Any attempt to cache value or somehow be "smart" about it will undermine the point - and power - of Gizmo. There are legitimate reasons to change a dataref value 5 times in what appears to be only one graphics call back. In short; You're going to need to get your hardware interface plugins updated one way or another. Given a few more weeks (as in probably more than a month) .. I might have the time to go and patch someone elses open source plugin. Right now we need to serve the majority.