We’ve been working on 11.20 beta 4 for a while now – the goal for beta 4 is to fix all of the SDK/authoring bugs and have docs for the new VR file formats. We’re making good progress; beta 4 should be this week, barring an unforeseen bugtastrophy. (Linux users: perf should be fixed with beta 4.)

We received a number of bug reports that beta 3 was showing large numbers of _vrconfig errors with third party aircraft. So this seems like a good time to re-iterate our policy on file format stability and betas.

  1. Don’t ever ship an add-on that uses an undocumented file format. You can’t guess what the fine print is from example aircraft.
  2. File formats are subject to change during beta, and are not stable until we go final. Don’t ship your add-ons against beta file formats.

In our case, the _vrconfig.txt file format changed in beta 3 and will change again in beta 4; as Chris wrote docs, he found issues that he is fixing.

Our priority during beta is not stability of your add-on, it is getting the file format right, so we’re not stuck with a buggy file format for the rest of time.

Once we go final, we’ll put compatibility code in to support the final version shipped in X-Plane when needed.

Similar logic applies to the SDK – it’s fantastic that people are using the latest SDK to test their plugins in VR, but don’t hit the “ship it” button until we’re final – it is always possible that the SDK will change in a way that breaks compatibility during the beta.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

39 comments on “Beta 4 and VR Docs Are Coming

  1. I am very happy to see your progress with VR.
    I fly all the time in VR at 30-45 FPS and it’s awesome. It’s impossible to come back with my 3 27 inch flat screen…
    I have also P3D ORBX /AEROFLY… But X-Plane + OrthoXP is the best for me.
    Thanks for your fantastic work !

    1. Same here.

      I have a 6700K and GTX1080 with Ortho everywhere and I just love picking a favorite aircraft and flying between popular airports. I wander all over the states, admiring the landscape and city lights. Helicopters are fun in canyons. The default environment and real-time weather is very immersive in VR (except the known snow/rain head-following issue).

      Laminar is on top of the world right now with flight simulation and has eagerly positioned Xplane to continue ruling the skies for generations to come.

  2. Hi Ben
    It’s been a while since I posted a comment and that is mainly due to your VR production. Not something I am following as I do not have a VR set, but looks cool.
    So there has been little talk of graphics in the last post, I know you are super busy, but I was wondering if you can make a blog post about some of the neat things you guys are working on. Also I do wonder how the XPD-8564 is coming along or if you have had the chance to work on it. (Short: Autogen strings issue in XP, where houses attaches to roads and create strings and not cluster of houses from OSM)

    Anway, good luck with Beta4 🙂

    1. The joystick code had to be restructured for VR – by accident the linux code lost its early-exit case when no hardware change has been signaled by the OS; as a result it was attempting to probe all joystick hardware every frame.

      What’s strange is that this is -not- slow on all versions of Linux, and we never figured out why some were hurt by this and some weren’t.

      1. On my system I just did a test.

        If my joysticks are not plugged in FPS normal but after a few seconds being plugged in the FPS falls below 10.

      2. X-Plane for example enumerates my Logitech K800 Keyboard as a joystick, same goes for the trackstick of the laptop. That’s why I had the problem all the time, with and without a real joystick attached.
        I think X-Plane considers every device with an absolute axis a joystick, and the K800 does report presence of a single absolute axis, for volume control.

  3. Really happy to learn about the performance bug getting fixed under Linux in this release! 11.11 was anywhere from 60-100 FPS and 11.20b3 was 8-10 FPS!! Thanks for getting this fixed!

  4. Is there actually a benefit for Non-VR-Users Besides Bugfixes? Or is 11.20 only a VR release with no major changes for Non-VR-Users?

  5. After 11.20 ticks the VR box, what’s next for … VR?

    Is there a planned ‘polish the VR’ phase?

    (Some ‘polish’ I would like to see would be oculus hands [maybe with finger pointing], and changing the walking so move and rotate are separate)

  6. Nice, the VR ATC window now has a virtual keyboard for entering flight plans. Thank you for this!!! I’ve just finished an entire VR “airline” flight using only touch controllers, and I didn’t have to reach for a physical mouse or keyboard once. I was flying in VR like a BOSS. : )

      1. Folko, I like that!

        I installed the plugin, dropped a .pdf with ILS frequencies into the charts folder and assigned a custom command to my right touch controller middle trigger to toggle the Aviator Tablet. It works like a charm. The document is right there in the cockpit in a user friendly window. Heck, with the frequencies readily available in the AviTab, I think I am now ready to try some ILS approaches in the LR MD-82.

  7. Hello Ben, I just downloaded the beta4, but I found that it still doesn’t fix the cloud shadow flicker problem. Can the final version of 11.20 fix this problem?

  8. Hello,

    Is this possible to introduce OGL screenposition of the SUN/MOON in datarefs? This could be very useful for plugins and I belive it wouldnt be much work on your end.

    Thanks

    1. These already exist..

      sim/graphics/scenery/sun_pitch_degrees
      sim/graphics/scenery/sun_heading_degrees
      sim/graphics/scenery/moon_pitch_degrees
      sim/graphics/scenery/moon_heading_degrees

      what exactly are you looking for?

      1. Hello again, thanks for the reply. I am currently using these, however, I am looking for exact Screen Position in rectangular coords (xy) rather than angles in OGL format x{0-1}, y{0-1}.

          1. Hello again Ben! I have managed to do properly calculations and got what I wanted 🙂

            I am wondering now, if previous data isnt easily available, would you be able to pass proper angular (in this form you have already relative to scenery) but relative to plane / camera position? I’d love to have pitch to sun relative to plane or camera xyz position (to change with relative point altitude/position changes). I am working on some graphic related stuff and would be really useful.

            Regards,

  9. Hi Ben,

    talking about DataRefs: I have no idea how much effort new DataRefs require, or if you want to keep the number as low as possible. So I’m just asking, of course… : )

    In the “Data Output” -> “Frame rate” section we see the “cpu time” and “gpu time”.
    (I don’t think we can read these values via the API, right?)

    Is there a chance to get DataRefs for those 2 values?
    Or sim stats, if that is easier? (I include proper checks and fall backs in my scripts when using undocumented stuff, I promise… ; )

    That would be really helpful to further improve my performance plugin FPS-wizard.

    Many thanks,
    Jörn

  10. It seems like we are taking one step foward and two steps backwards lately !
    Our US Orthophotos are messed up now! We are seeing pixelated white/blue textures. They are especially noticeable at sunset. Please fix it !!!!!

    Forkboy2

    Report reply

    Forkboy2 481

    Posted March 29

    On 3/29/2018 at 4:03 AM, Gronygroovy said:

    I am getting this too 🙁 It is such a shame as the Ortho looks really nice, this ads a sort of pixelated effect to it 🙁 Is there any fix or eta?

    I think what you are seeing is the “gritty textures”. LR must have done something to change how they are displayed. And of course they also removed the ability to easily toggle these on/off with XP11.

    I don’t have time to experiment right now, but can you try opening Settings.txt in your resources folder and change all the “1”s to “0”s. Tradeoff is you will lose the 3d look of textures when you are on the ground.

    Instead of this:

    SETTING_1 renopt_effects_04 0 reno/use_detail_textures 0
    SETTING_1 renopt_effects_04 1 reno/use_detail_textures 1
    SETTING_1 renopt_effects_04 2 reno/use_detail_textures 1
    SETTING_1 renopt_effects_04 3 reno/use_detail_textures 1
    SETTING_1 renopt_effects_04 4 reno/use_detail_textures 1

    Change to this:

    SETTING_1 renopt_effects_04 0 reno/use_detail_textures 0
    SETTING_1 renopt_effects_04 1 reno/use_detail_textures 0
    SETTING_1 renopt_effects_04 2 reno/use_detail_textures 0
    SETTING_1 renopt_effects_04 3 reno/use_detail_textures 0
    SETTING_1 renopt_effects_04 4 reno/use_detail_textures 0

    Daikan 441

    Posted 19 hours ago (edited)

    On 3/24/2018 at 10:04 AM, strid said:

    I updated from 11.10 to 11.20, now my orthos have a blue/white tint to them. Is anybody seeing this in 11.20 ?

    I have this too and my tests concluded this has to do with the ground becoming partially transparent when a certain decal is applied (Ortho4XP default is ” DECAL_LIB lib/g10/decals/maquify_1_green_key.dcl”.

    1. So….NO ONE has filed a bug with this. This is literally the first I’ve heard about it.

      Please file a bug ASAP, and include complete details, e.g. screenshot of the issue, rendering settings and where to get the pack, log.txt for your system config.

      This bug report is coming in really, really, really late – I’ll try to look into it.

      1. Yes. From the docs: “Hotspots are predefined locations that are used to precisely orient the VR user when selected.”
        Is it possible to select the current hotspot via plugin code?

Comments are closed.