Posts by jpx

    If I understand, all messages will be string based and parsed by the sim (with strstr or regexp), and it the will be only one float per message.

    if I have to send all hand's bones at 60 or 120Hz like this it will probably "suck" no ?


    Thnaks for you long answer,

    Yes of course if you decide to add support for the leapmotion, it could create some conflict. But do you think support this soon or one day ?

    My goal is to create a cockpit in hard having button/handle at the same place than in the virtual cockpit. so one modif for one plane is not a problem at all.

    To do that, I need to know in realtime where are my hands/fingers exactly. Leap motion or Z cam can help me to do that.

    I already did an interface between openvr and aerofly to catch/overload datas on the fly if needed. (I didn't find any option in the sim to hide virtual hand or to bypass vrcontroler interraction with the sim, so I did that). I could add some 3D/overlay by this way too, if I cannot do it via the standard aerofly sdk.

    Could you explain me which message I should send to modify the human body via the dll ?

    What will be the data update rate reachable in Hz ?

    Many Thanks

    What would you like to do with this?

    In theory this should be possible with the option.tmc (per aircraft repaint/option) that were added a while ago. But I haven't tested that myself. In theory this option can be bound to a aircraft repaint (you could copy the default one) and it enables you to load additional models when the aircraft is initialized.

    If you want to create a sort of knee-board, this should work. A map or chart rendering is probably not possible, other than what's already in the executable.

    Hi Jan,

    thanks for answering,

    My goal is to add skeletal hands inside cockpit with leapmotion for example but only for visualization, not for interraction with the virtual cockpit.




    did you see the external dll sample from the sdk ?

    At line 73 of this source file, you will find the list of datas you could retrieve in theory...


    The oculus window has to stay in the background as far as I know.

    If you remove the "-othervr" it should use the steamvr. I don't think the start tag "-steamvr" is recognized, it may just ignore that and work as if you had no tag at all.

    Give us some time to try and reproduce this issue.

    From what I understand it is working for you now when you leave the oculus window open or when you start with steam vr?

    I tried steamvr since I thought that if -othervr exist, -vr or -steamvr should exist too

    -steamvr is recognized, since without, aerofly standalone version start without any VR engaged.

    -othervr is for oculus, so it's probably why it starts oculus first and switch after to steamvr since occulus is not connected

    Thanks for your help

    Thanks for quick anwsering

    OK, so you have two versions of Aerofly FS 2 installed on the same PC, Steam and DVD/direct download version?

    They will likely write to the same user documents Aerofly FS 2 main configuration file and if either of them has a newer update this could cause issues on the other installation.

    Yes, but Standalone version crashes before any start of the Steam version.Just before to launch standalone version installation, I renamed the AeroflyFS directory into AeroflyFS.Steam, so Standalone crashed with its own AeroflyFS directory created by the install process and the two consecutives updates and without any pollution of the steam version.

    I will catch the tm.log asap...

    One precision, I have my oculus driver installed too, but not connected. Aerofly Standalone Version starts first Oculus and then SteamVR. Aerofly Steam version doesn't do that since we can choice the VR fronted at startup.

    Is it any way to force the VR frontend of the standalone version with some argument like -othervr ?

    Here is the tm.log just after a crash always same default airport and airplane (San Martin, Cessna 172...)

    idem after deleting the main.mcf

    Hum, when I don't close the oculus window, it seems to work better. Is there anyway to force Aerofly to use directly SteamVR and ignore libOVR even if oculus and/or oculus revive are installed ?

    Hum I tried to replace -othervr with -steamvr option and it's seem to do the job...


    • tm.log

      (26.44 kB, downloaded 5 times, last: )
    • tm.log

      (26.57 kB, downloaded 3 times, last: )


    I have both version of aerofly. When we like...

    the standalone crash in VR (index, gtx980ti) after several seconds, on the defaut airport San Martin of the fresh install, without any addons installed and fresh aeroflyfs Folder in home directory (I didn’t test other airport or non VR mode yet).

    SteamVR doesn’t crash, it’s only aerofly.

    On the same PC with the same Aeroflyfs folder in mydocument directory. The steam version of aerofly doesn’t crash.

    That was with last version available for each version the 22 mai 2020 at 11h pm Utc 0

    Standalone :

    Steam :


    Nvidia driver : 445.87

    OpenGL mode




    Thanks even if I would prefer an other answer ;-)

    It not too complicated to implement, and very usefull for VR users.

    People have asked about that forever. It's one of those things that is just never implemented, and eventually you feel you are just talking to yourself.

    Hi HiFlyer,

    I did some investigation with some piece code, and it seems that the openvr resetseatpose function is never called by aerofly (automatically) during startup.

    I tested with my valve index (with only one sensor) and it seems to be reproductable. I have always the sensor at my left when I look forward. I tested only the default airport of a fresh installation. Have to test other airport to see the first yaw initialisation depends on the QFU. Perhaps the hmd uses its internal compass to initialise it’s yaw offset regarding fixed sensor, I hope he doesn’t.

    In any cases I think initialisation problems are only coming from the HMH and its driver.
    I imagine that with standalone hmd (without fixed sensor) it will be Impossible to have a reproductable frame initialisation at each startup.



    is it a way to force the VR frame and avoid the auto reset at startup. My goal is to have always the VR cockpit at the same place relatively to the fixed VR sensor (Valve or oculus)

    thanks in advance,

    hi Guys,

    Some questions about mesh creation :

    Is there anyway to convert P3D mesh to aerofly ?

    If not do you know a provider of DEM for France compatible with "aerofly mesh" creation tools ?

    At last but not least, is there any tutorial somewhere to help me to create "aerofly mesh" from srtm1 files ?

    Lot of thanks in advance,



    great ;)

    Hi Paraovski,

    What type of VR headset do you have (Oculus, or open VR compatible) ?

    For Oculus it's particular, VRK has to modify the simulator on the fly (via code injector) to be able to use VRK in the same time. I have an Oculus CV1 too but I did'nt success to run VRK inside Aerofly with Oculus.

    With my valve index (openVR or steamVR) it's more simple and works well with Aerofly. Both softwares VRK and the simulator are speaking directly with OpenVR/steamVR. Actually OpenVR/SteamVR give the possibility to have several VR applications running at the same time. VRK use this natural feature in that case.

    With OpenVR you can use VRK alone too since VRK speak directly with openVR. Just launch OpenVR and look inside your headset. If not, go in Configuration (Gear button), VR tab and set the VRMode you have. I advice to use steamvr).

    If you have an oculus perhaps you can try "revive" software to emulate an openVR headset but you will loose framerate

    good luck,

    My Intuous S has arrived and I like it. I can load in airport info, navigation notes, even screen grabs from google maps for a bit of pilotage navigation - if anyone's interested I found a nifty way of creating a single large JPEG screengrab (8,000px x 8,000px) from google maps and with the kneeboard you can scroll around it like a live google map.

    With my 3d printed bracket it all works very nicely. The slot is for a webbing belt. The right hand clip is for the pen.

    Hi Phil,

    I just received mine !!!
    Could you share your adapter design with us/me? Parasolid or step files should be great ! 😉

    Thanks in advance,