Ben Russell

My understanding is that Coop is blocked by Laminar Research. - Laminar changed how avionics are rendered. - Laminar updated the default aircraft to use their new avionics. - We as developers are waiting on the SDK and tools to be expanded in many ways to allow us access to all XP12 can do. I've attached a Screenshot from the XP-Developer Slack chat where Ben Supnik explains some of the logic behind current choices. Further in the thread Ben S. explains that Laminar is looking to expand the "click" processing to better suit things like; real touch screens, VR, VR Gloves, and boring old mouse clicks. The obvious solution seems to be to provide patched versions of the default aircraft files that can hook the the mouse clicks but I don't think it's possible at this time with the way XP12 has changed. The thread that screenshot is from was quite long and several other developers(including Laminar for their own mobile titles) are wanting better functionality for these items so hopefully it's high on Laminars priority list.

Please attach a copy of X-Plane/Log.txt to your next post if problems continue. This will allow us to see what (other) plugins you have installed and may help us determine what's going on.

I have read and replied to your post. I am the author of gizmo and the X-Aviation global drm plugin. You have them installed in the wrong folders.

You have the plugin locations switched. Xa plugins is global. Gizmo-avionics is for aircraft.

Thanks for the additional data. Newer versions of gizmo can deal with this better because the host plugin provides more status information to the script about what happened to its network request..

Likely just a network glitch in a version of Gizmo that lacks the functionality to deal with it properly.

@VirtualGAaviator

Do you know gizmo has been split and is now available as an aircraft plugin and a lighter-weight xa drm global plugin?

It is NOT normal for X-Plane to pause during license fetch. There's an animation to display activity during this phase. It is definitely not normal for X-Plane to freeze because the user pasted from their clipboard. You might see a fraction of a second pause for some Gizmo-powered aircraft like the Saab or 737 after the license has been fetched because those aircraft reload their systems and re-init some code. I have no advice regarding what the topic starter should try. Seems likely a onece-off random bug. Might be a plugin clash, might be ImGUI doing some weird parse of their password characters and glitching out the GPU drivers leaving sound working. This is the only instance I've ever seen of this bug being reported and it went away for them on the next attempt.

As you have not attached a current Log.txt file I will assume that you have a similar number of plugins installed as with the Drt topic of a few days ago. My advice is also the same... Please try removing all other unnecessary plugins and retesting. There is no 10 minute time out feature or code to trigger inside xa.plugin or gizmo64-avionics. Something else is going on. Sorry for the inconvenience.

I'll install drt on this end and see if it gives me any clues.

You've got a bunch of other plugins installed so you can either: - Try removing them all and putting them back piece by piece to determine the possible clash. - Try the new beta version of Gizmo detailed here: https://blog.x-plugins.com/2023/02/gizmo64-version-23.html

Please post a complete copy of Log.txt as an attachment.

You are required to name your machines and type "FREEZE" to confirm your own actions. The process is quite clear. You locked your own system.

No. There is no alternative.

Request a feature in fse where you can set an allowable percentage of fuel value tolerance. If people set a stupid percentage then they're cheating themselves. Alternatively the author of fse could set a Max percentage to 5-10% so that people don't set something stupid like 80%. Then the entire issue with custom systems and fuel flow goes away for every product now and into the future.

https://blog.x-plugins.com/2023/02/gizmo64-version-23.html?m=1 Please provide links to current/recent forum threads or reddit posts if you're going to make posts like this so that I can look into the issue.

All plugins are loaded into a shared memory space. Any plugin can corrupt any other plugin. Occasionally this shows up as a reliable and reproducible clash between two of them.

This product is not sold by X-Aviation. Contact the vendor you purchased from for support.

I downloaded v1.04 It contains a "fat plugin" binary with both x86_64 and arm64 segments present. There is definitely a glitch with the signed status of the file. It claims it is unsigned yet attempting to sign it with my own Apple Dev cert fails. I was able to get the plugin working by extracting the arm64 portion of the plugin and renaming some files. cd ~/X-Plane 12/Resources/plugins/XMidiCtrl/mac_x64 mv XMidiCtrl.xpl fat.xpl lipo fat.xpl -extract arm64 -output XMidiCtrl.xpl After extraction X-Plane 12 starts without error and XMidiCtrl was present. The lipo tool might not be available if you don't have Xcode installed...

https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-SW2 Search the page for "Signing Code Manually" .. you can sign binaries from the Terminal...

@Cameron

The installer would have created the X-Aviation folder. If it already exists you have a different issue.

Create a new folder called x-plane/X-Aviation this error is caused because you copied the product folders instead of using the product installers.

Hackintosh have a "special case" code path in the machine Id code... Please raise a ticket with X-A support so we can gather some diagnostic info based on your registration attempts and the machine Id it sent us. This is not something that is likely to be resolved without changes to the plugin code. A new plugin release is not far away though(days to weeks) so hopefully we can get this resolved fairly soon.