virtual reality issues with GNS

[LouP 116]

Anyone else having any problems in virtual reality with the gns 530 or 430 utilizing Flyinside?  Mine either looses the course line, locks up, or reboots right after takeoff after spending a while programming it.  This stuff only started happening since I started flying in virtual reality mode with a Samsung Odyssey.  I have been swapping out the gns units for default gps units and it hurts to do so.

LouP

[RXP 2,336]

Hi LouP,

which simulator are you using Flyinside with?

[LouP 116]

P3D v4.2

[RXP 2,336]

This runs fine for our customers using Flyinside and XPlane, so there is a chance this is unrelated. Are you using any other tool that alters the process affinity/priority (like Process Lasso or similar)?

[LouP 116]

Not even sure what this is so I would say no.

LouP

[RXP 2,336]

You might want to try this: open the RealityXP.GNS.ini file, locate the section for the device you are using (for example [GNS_530_1] and add the following: LogTrainer = 1

This will capture some additional internal trainer events to the rxpGnsSim.dll.log file which might help finding out the cause.

[LouP 116]

So I learned a little more about this issue tonight.  The problem in vr seems to vary depending what aircraft I am flying.  Some work and some don't.  The 530 in my Alabeo Seminole would not work and the screen was black, the 430 in my Alabeo Piper Tripacer wouldn't respond when I pressed any buttons, but the 430 in the Carenado Caravan worked just fine.  This makes no sense to me.  Should these units be performing differently from aircraft to aircraft.  I added them all in the same way using the drop down menu.

LouP

[RXP 2,336]

Hi LouP,

there is no particular reason it fails with some and works with others, except FlyInside conflict. This is the kind of product which intercepts the video card rendering and 'tries' to redraw it from 2 different point of views, calculated on-the-fly (no pun intended) each frame. Therefore, it is by nature interfering/messing with the rendering.

Having said this, our gauges render within the boundaries of the simulation rendering ending only (but they are pushing the SDK beyond its limits for this), which should mean anything the simulation is rendering normally is not rendering differently our gauges either.

Makes me wonder what is causing this, and you might want to enable the setting I've indicated above so that it might catch additional details in the log file.