snakem12

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

Haha, nice, that came through while I was authoring mine LOL. But is a separate thing from the panel size (the "Home"-Header on the GTN 650 is cut on their screenshots, too) I will go and catch some sleep now, its about 4 AM here in Germany.

Hi again, Sorry to seem nitpicking... 1) The placement and size of the GTN panels within the 3D border is wrong / cuts content (see MU2_RXP_FRAMES_ORIG.png). IMHO changing the frame in RealityXP.GTN.ini to [GTN_750_1.PANELS] ... ; display position and dimension (left,top,width,height) ; frame.rect = 10,725,605,715 frame.rect = 16,715,592,700 and [GTN_650_2.PANELS] ... ; display position and dimension (left,top,width,height) ; frame.rect = 10,1005,605,270 frame.rect = 20,988,583,260 is better (see MU2_RXP_FRAMES_MOD.png). 2) The lower two thirds of the GTN 750 screen is black (no display showing, see images). So for the panel dimensions given above I could not validate the botton border 3) Why not activate... [GTN_750_1.PANELS] ... ; right mouse button on the screen toggles popup window if true (requires XP11.1). ; popright = false popright = true as is already done for the GTN 650? 4) After finally finding the "REALITY XP GTN Config" setting () I now have to set it on every load to "GTN 650/750" again. The setting seems to get saved (mu2b60_prefs.txt: rxpgtn_config_enum:4), but not (correctly) restored. Or perhaps simply a zero based versus one based oops? I will tell how much I like 2.0.3 soon as I get to FLYING it after all. It's too late in my corner of the world now... Best regards, and thanks again for 2.0.3 !!!

Great news! A (very) small first observation: The acf_version.txt says 2.0.3 (as to be expected), but the .acf files (xsMU2B60_4B_GLASS.acf etc.) all still contain "P acf/_version 2.0.2". Which obviously means they are displayed in XP with "2.0.2" on their tile for the A/C selection. Just did confuse me a bit at first

Hi all, just to confirm this issue, had the same (forgot about the GPU). But I did see it just in time (dragging the GPU with me while taxiing) and was stll able to dismiss it via Gizmo