Qwark

I just "revived" my MU-2 after quite some time now. Flying the GNS variant + TDS GTNXi (+ SBAS-Receiver enabled via Plane Maker and HSI needle autosync GTN setting). Is great fun again! ILS+RNP approaches simply work with this config. Of course the MU will benefit from any improvements yet to come. but as a thumbs up: It's already (and still) great fun on XP12 even in its currently somewhat orphaned state!!

I found that the MU-2 GLASS (+ G500) needs BOTH the Gizmo and the X-Aviation DRM plugins installed / enabled. I use xOrganizer and had the X-Aviation plugin disabled (as the MU-2 is Gizmo still). In that case there is no error message, but the G500 simply stays dark. So, reinstall of course installs fresh (and "enabled") copies of those plugins, but it should not be needed if you just make sure both Gizmo and X-Aviation plugins are enabled at runtime.

Just to pin down e.g. the takeoff power N1 value to remember it. Has no „function“ other than helping your memory AFAIK.

Old topic, but I was just bitten by this again (kind of). If someone still got problems with the GNSs and/or the transponder not powering up, maybe this can help?

Not wanting to bump this topic, but just had the same cause with an other symptom. After the RXP GTN plugin was disabled and a GNS (actually a GLASS) Variant of the Moo loaded, the XP GNS came up fine, but the transponder did not power on. Sure enough "rxpgtn_config_enum:4" was set in the *_prefs.txt. In this case probably the transponder was disabled because the GTN‘s one would be used in lieu (the stock transponder was still showed, just not powered).

I do appreciate you trying to help. But (you can not know, and I do not feel like going into details on this medium) I am professionally involved with „IT“, and that for several decades now (wooh, that feels old ,-)). So, if there is a way to measure/analyze the connection to the endpoint that the DRM wants to communicate with, I will happily cooperate (if I can find some toolchain on Windows thats up to the task, and provided the data center does not send in the cavalry for a „sniffing attack“ ). If there is a debug logging for the plugin (more detailed than what goes to the XP log) I will try to provide that, too. I would even run it under a debugger if deemed helpful and told how (and provided that Laminar does not send in the cavalry for „reverse engineering“ ) Shooting in the dark will not be of real value, though. Even if it worked on another machine it would still not prove „the network“ guilty, and I have to use it on this machine, so I better cure the cause, not the symptom, anyways. Also I use that provider for two or three years now, with different payloads, and never had issues with the network (if any, my local Wifi was the cause, but that would not apply at all to the issue at hand). Afterall the problem is the plugin *crashing*, not being unable to reach some endpoint (and if the crash is a side effect of connection problems, at least the logging is poor). Not wanting to be rude at all, but „send more logs“ and „must be your network“ always have some „support deflection“ smell. Just let us keep the smell low

Ok. Poor Tom Kyler sorting a "three out of thousands" problem ;-)

Well, yes, they are surely different. But they all use the same Gizmo plugin, and I wonder if that is the "one of the day" (depending on what X-Aviation product was installed last) or the "highest version" seen among all products installed. As I did not monitor the Gizmo version from my previous install (the CL650), but saw that the Gizmo plugin had todays modification time on the files (from the IxEG install), I wanted to make sure the CL650 still runs with "on the other gizmo". And, as the error explicitly mentions a problem related to DRM context, a suspicious look on the gizmo seemed sensible (the IxEG and the CL650 possibly *do* work quite similar with regards to the DRM mechanism). So, worst case a "parallel", but no "comparison". Makes sense?

Hi, and thanks for coming back on this topic! Haha, Pils already had nearly the same "amazement" moment about the HW when I provided a log yesterday (wrt. to some CL650 problem), so I just copy&paste my answer: So, I do not think it's a hardware problem, and the network connection should be ok, too (after all Windows/X-Plane runs "inside" a data center with quite professional connectivity). I currently do not have access to another "Windows"-Machine (as I avoid them obviously), but I would not see much hope in trying, anyways ;-) Oh well, it is no fun to be one of "three out of several thousand" ;-) P.S.: When I just ran the CL650 (to make sure it still works after having installed the IxEG) I had to re-activate it (probably because of the changed Gizmo-Instance that came with the IxEG). But that went fine. Just FYI.

Fair enough, though I doubt it will provide more insight that all that is already discussed on this thread. But I would be happy to be proven wrong ;-) Log.txt

Hi, I just purchased and installed the IxEG on XP 12.0.8-rc1. Now I have the same problem: XA DRM - RMD0: [c36bbfd5] --=={This application has crashed because of the plugin: X-A Validation}==-- So, I've not been able to load (or activate) the brand new aircraft (= v1.5.2) even once. Already stripped down my plugins to "zero" (just leaving the Gizmo64 in). The solution can *not* be using a Mac XPL on a windows installation, so I did not try that. I do have some other X-Aviation aircraft installed and running successfully (CL650, MU2, SR22, TBM900(waiting for XP12 update)), so this should be not a "general" problem with my gear. As this thread is open for two months now seemingly without a solution to that "kaputt" xa_validate.xpl, is there any perspective to get that fixed anytime soon? Otherwise the plane is complete useless for me (not being able to even load it). Would be a pitty, because I do like the MU2 a lot, and was hoping for the same wrt. the IxEG 737 .

See also e.g. from around 11:30. Have fun!

Arghh... Had read about DRT/CL650 problems, but simply forgot about it. Without DRT sure enough it works now, just doing the registration... Sorry for the noise. Well, machine stats may look funny. It's a remotely hosted VM (https://shadow.tech/). GPU is ok, but for XP it is obviously somewhat CPU limited ;-). As I privately just use Linux/Mac I have this for some gaming on Windows now and then. Works (mostly) without having to let that OS pass my door. Thanks, that was quick help ;-))

Hi, a complete virgin install of the CL650 crashes XP 12.0.8.rc1 during startup before I can even enter my licence data ;-( Log.txt

Hi, did you try to set "Repeat Activation" to e.g. "Delayed-Fast" on the respective event in HC-Configurator?

How about https://forums.x-plane.org/index.php?/files/file/54217-portable-oxygen-for-ga-aircrafts-lua-script/ ?

I'm on XP12 now, so no GTN 750, G500 (and MU2 with visible lights daytime <g>) for me. But IIRC the settings from did help a lot on XP11 :-)

Yep, noticed that also. But as I only fly 5B GNS ATM I simply temporarily moved the G500 out of the AC plugin folder

Hi, sorry, I am aware that this may be of no help, but I just did about 20 flights on the 5B GNS (v2.0.4 on XP11) over the last few days, and everything is working perfectly fine here. So at least the AC seems to be OK, and I would suspect some other reason ("leftover" joystick binding or FWL script or whatever ...). Best regards

Hi, thanks! No big deal after the culprit is found, manually editing the prevs works fine. It's just confusing if there seems to be no way to power up those dark GNSs, not with the radio switches nor any other "in sim" means. As long as the GTNs are (invisibly) "selected" via the prefs the GNSs simply seem not being "installed" (internally, although shown on the panel) I guess. So it is manageable even without a fix if the cause is kown. Just wanted to inform in case someone else also is puzzeled by dark GNSs ;-) Best regards.

Hi, just FYI... I (virtually) removed the RXP GTN plugin (via XPOrganizer) on XP restart and loaded the default GNS variant. In this case the GNSs stay dark. Looking at the mu2b60_prefs.txt it still has the attribute "rxpgtn_config_enum:4" set (i.e. the GTN 750/650 that were selected on the last flight), but there is no option to switch back to the default GNS via the options panel (as the GPS selection is not shown, because RXP is "not installed"). So the only way seems to change that attribute to "rxpgtn_config_enum:1" manually before loading the plane after the RXP plugin was removed. Shouldn't the code simply default to (effectivlely) "rxpgtn_config_enum:1" if no RXP stuff is installed on load?

Ah, ok, thank you. Looking forward to no longer have to reach down without having proper attitude awareness from seeing the instruments.

Hm... Are those xscenery/mu2b50/manips/... commands supposed to be shown in XP(11)'s list of commands to be bound to keys or buttons? The xscenery/mu2b60/ category is there, and also a xscenery/mu2b60/misc/, but no xscenery/mu2b60/manips/. Or are they only reachable via API?

Great! This is so much more interesting (Engines, AP, …) and fun to fly than any „big button fadec start and off you go“ plane. Thank you!

While you're at it, perhaps you may want to correct the GTN panel positions/sizes. As they are now they are a little too big for their bezel. E.g. the top "Home" header line on the GTN 650 is currently cut off ("out of the bezel"). If you review there are GTN "in 3D bezel panel sizes" that match better. Just a small thing, but simply looks cleaner