RXP

Hi, Thank you for asking! The product EULA grants you the right to install on two different computers, provided you're not using both at the same time. The typical use case is desktop simulator at home and laptop on the go. In your case, this should be ok to.

@Sling @rog943 I don't know how Air Manager is handling it, but this would probably be the first step I'd cross check with the vendor (whether they are passing all parameters end-to-end).

Hi, I've been looking at potential explanations but there is none that I can think of at this stage, especially given both the GTN 650 and GTN 750 are using the same database files, except a corruption in the GTN non-volatile memory file. I'd suggest you do the following: - Read the RXP GTN User's Manual chapter "Device Embedded Memory" p18 - Make a backup of the non volatile memory file corresponding to the GTN 750 unit you're using (different files for unit1 and unit2) - Delete the file and load the aircraft with the GTN so that it re-creates a genuine one. Hopefully this will solve the problem.

Hi, I believe you'll find what you're looking for in this mod:

Hi, You most like have to tell your browser to go one step further, as illustrated here: https://textslashplain.com/2021/05/19/download-blocking-by-file-type/#user-experience-for-downloads-lacking-gestures As for the "potential threat/virus" message itself, this is a false positive and it is better documented here:

Hi, There is nothing specific between a mouse or a touchscreen with our plugin, because it displays in an X-Plane window which inputs are therefore handled by X-Plane itself. In other words, if X-Plane is accepting touchscreen inputs instead of mouse inputs, and if this allows interacting with anything within any X-Plane window, then it should also interact with our plugin window as equally.

Hi, Given the chapter title and the picture this reference comes from, there should be no doubt which panel this is about (hint: read the blue font title at the top of the picture): At this stage the easiest would be to cross-check the RXP GTN log files. If the flight plan import folder is not configured correctly, the log file will tell exactly where the GTN is expecting the files to be, and therefore what folders and where you might have to manually create. Did you configure Windows to redirect %PROGRAMDATA% to "E:" ? If this is the case, then it is normal you won't find any C:\ProgramData because you configured Windows not to create nor use one?! In this case, it would be expected the folder you're looking for is also in E:\ProgramData\Reality XP....

.@Lennard78 Hi, you'll find more information about this in the dedicated topic. I'd suggest you start with the recommended posts pinned at the top: https://www.avsim.com/forums/topic/546848-rxp-gns-v2-and-gtn-database-update/

You could* but there is no user setting available for this. However you can change the perceived scale with the OpenXR Toolkit "world scaling" feature Considering cockpit size perception often depends on the aircraft, but not just, this raises the question whether the model is accurately designed. However, if you do find out the model dimensions are correct, this wouldn't change the fact you could still perceive the model too large or too narrow, because it is much more complex a problem that just measuring a model. I've tried to explain some of this here: [BUG/FEATURE] Cockpit Size and World Scale in VR - Virtual Reality (VR) / VR Wishlist - Microsoft Flight Simulator Forums In the end, you might find out that: - You put two VR controllers a certain known distance apart (say distance between 2 C152 doors) - You go into VR with the C152 and find out both controllers are perfectly aligned on the virtual doors in VR - Yet, you still perceive the cockpit either too small or too large nonetheless! Isn't this fascinating? Try looking at some of the cross-eye pictures I've posted in the topic linked above to see for yourself! *very easy for Asobo: just change the projection matrix scaling terms.

I know 😂

It seems like you're looking for an argument. Although I'm sorry the RXP products are disappointing you, this is not the place, and I'm not the right person to argue with.

Hi, First of all, the GTN and the GNS can use real database updates and there is a lot of information about this in the dedicated topic here: NB: I'd recommend you start reading the recommended posts pinned at the top of the topic. As for the Flightcharts, I'm not sure about these in particular but I'll cross check whether is can be "simple" or a little more "complex" to do.

Hi, Are you sure you didn't inadvertently selected XP9 and XP10 in the installer? Sorry I can't resist: will you use X-Plane 12 on macOs 12 ? 😉

@Pilot_Kayden Hi, Do you mean when using Smart Copilot? Is it possible it is not syncing the dataref fast enough, or it is not queuing up enough dataref changes (as in storing pending changes in a queue for transmission)? These would be the first reasons I'd investigate with Smart Copilot. However please note the touchscreen is using a form of "gesture" interpretation and the "cheap" solution we're providing here is merely conveying raw touchscreen events. It is possible therefore that a slight difference in timing between 2 successive touchscreen events ends up to be fundamentally interpreted differently enough at the other end.

Hi, What aircraft is this? Have you cross-check with the 3rd party aircraft vendor whether they are doing a mode switch in these conditions?

Hi, I'm sorry for the complex hoops you had to go through, but I'm glad you've finally sorted this all out.

@btacon I believe you've already posted in another topic to which I've answered a few minutes ago:

Hi, I'm sorry for the delay. There could be multiple reasons but the first one I'd think of is this aircraft could be using a custom autopilot which isn't handling this kind of situation. Probably one way to cross-check the nature of the problem would be: - try the same route with a simple stock aircraft, not a 3rd party helicopter, and compare how the A/P steering is behaving. - it there is a stock X-Plane helicopter with A/P support (I honestly don't know), then maybe trying with one instead. Overall, the RXP GPS is using the "override_gps" dataref when in GPS mode and it is the Master Device. When enabling this dataref, the underlying stock GPS is supposed to stop functioning and stop steering. However SUSP mode is a special case which might need special care at the 3rd party aircraft autopilot code in order to work as it is expected, and in this case, the RXP GTN ouputs the necessary data, but I can't know whether the 3rd party aircraft custom code is using it. I'll be pleased to assist any 3rd party dev if they inquire.

Are you by any chance using any imported GNS database from a real cartridge?

Hi, Thank you for sharing the log file. It looks like there is a problem making the Garmin trainer process quit here. I'll cross check and report back.

@Curtis_1 This is a good question that I haven't revisited since back then. The issue is clearly a swap of command name vs command description in XP11. Which range down/up buttons are you talking about? An aircraft 3D cockpit button? The RXP GNS bezel buttons in the popup window?

@rog943 @Sling Have you made any progress with this? Do you need additional information?

Hi, Re-installation is a very simple process: 1) download and run the RXP e-commerce installer from our website 2) enter your F1 account credentials 3) press the REINSTALL button. As for virus part you might want to cross check this:

@btacon You are right, this is just software and theoretically it is legitimate in my opinion to wonder why not faking VNAV with the RXP GTN. There are multiple reasons but the simpler one I'd say is because it would be fake. Besides, the RXP GTN is already providing all the necessary output data, the same as the real device, and the same that are needed so that an aircraft vendor could opt to fully design an autopilot system operating like its real world counterpart, using the same signals and data logic as the real Garmin devices. Some are indeed taking advantage of this on X-Plane already. Rest assured any 3rd vendor wanting to do it right can contact me and I'll be pleased to assist and try making this an authentic implementation. [edit] On the other hand, you might not get a fake VNAV, but you get many more than what you probably had before, like an authentic Ryan TCAD B990X device simulation (which is using in the back end our authentic TCAS II Mark 7 simulation which is passing the industry standard TSIM tests), the capability to display simultaneously, and without affecting the fps, more than just 1 view of the same GTN at a time (you can display our GTN both in the 3D cockpit AND a popup window - and actually up to 5 instances simultaneously!). You also get probably 10x more fine grained settings covering most if not any integration needs and most if not all user preferences. Let alone all the possible integration with real hardware, be it as simple as keyboard shortcuts up to authentic replicas with integrated screen, and much much more... 😉

Let's rewind a little bit to make sure we're talking about the same things. If you need to custom map the standard Prepar3D XPDR system with the GTN XPDR functionality, this is therefore done already: the GTN is fully synchronizing the XPDR with Prepar3D transponder simvars and modes. -> can you confirm this is working on a simple aircraft (say the default Mooney) as-is (without Vatsim nor PilotEdge in the middle)? If you want to bind the proprietary Vatsim/Pilotedge XPDR handling (their operating modes) into the standard Prepar3D transponder simvars and modes (the public SDK accessible ones), and if you can do this proprietary binding with the default and standard P3D transponder, then it should work as-is with the GTN because the latter synchronize bidirectionally with P3D?! Otherwise how would you do without resorting to using a payware middle-ware (FSUIPC)?