Thanks to everyone who came out to see us at FlightSimExpo – it was great to get to meet so many people in person. Just a few quick notes:

I don’t have an ETA yet on video of our talk that was shot by the event coordinators (the cameras you might have seen dead-center). We’ll post slides soon. There is an audience-shot video that some people have seen – the audio is understandable.

Regarding the new particle effects system, the biggest single question has been: will it work on scenery objects? The answer is: yes, eventually. Right now you can attach a particle system to an object attached to an airplane or created with the XPLMInstance API. Scenery-attached particles are on our road map, and if they don’t make the initial release in 11.30, we’ll get them as soon after as we can. (The same thing actually goes for FMOD sound – we intend to have FMOD sound on scenery objects, but we don’t have this done yet.)

Regarding “research mode”: the intent here is to have a non-versioned beta flight model available for longer periods of time in an otherwise final sim so that people doing experiments on the flight model or building new aircraft designs have access to the latest in Austin’s physics without having to build a new permanent version for the physics on every single release. Up to now, it has been really hard for Austin to get useful feedback on the FM because it is either hidden (non-beta) or locked down, except for tiny 8-week windows, during which the rest of the sim is so unstable that aircraft developers don’t want to touch it.

So you can think of research mode as getting access to in-progress 11.40 physics within 11.30. If you’re the kind of person who holds a flair over the air-stream of your aircraft, this is a useful way to compare the real world to Austin’s latest work.

Research mode is not available in Plane-Maker as a setting because there’s no versioning control, so an add-on that depends on it is asking for trouble. When we reach a point where the research-mode physics seem well-behaved, we’ll make a real “version” and make them default for all non-old aircraft (as defined by when saved in Plane-Maker).

A lot of the new systems announced (new engine types, new auto-pilots), etc. are strictly opt-in. e.g. the old behavior is unaffected if you pick an old autopilot or engine model. This is a case that’s fairly easy for us to do without compatibility problems.

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.

29 comments on “Back From Vegas

  1. So, when the now-experimental flight model will become default (say, in 11.40), this means that an “old” aircraft (i.e. not re-saved in Plane Maker 11.40) will use the “old” flight model?

    1. Yeah, that’s the plan. This already happens now for a number of FM changes. If you re-save, you get the new one. (We haven’t decided on whether old vs new FM will be selectable or just “if you resave you get the new one”.)

      1. After a bit of rooting around in the .acf, I discovered the parameter “acf/_file_writer_version.” I’m deducing this is the setting that determines what flight model that X-Plane would use in the scenario you describe, Ben. It makes me wonder what impact editing this parameter “backwards” would have after saving in the latest version of Plane Maker. 😉

        It seems to me right now that if a developer needs to maintain stability with a certain flight model, that they must retain a copy of X-Plane of the desired version and only save an .acf with that version, but test in the latest version of X-Plane.

        1. Hi Steve,

          If you hand-edit the parameter backward, all hell breaks loose and I don’t want to hear about it when your aircraft goes nuts. For real.

          The reason is that some upgrades are done via file writer version but some are done by saving new values into new key-value pairs. The reader may simply read for the existence of the new key-value pairs and NOT look at the writer version for SOME features. So you risk getting a random mish-mash of old and new.

          1. Entirely what I thought you would say, Ben. No worries, I wouldn’t dream of doing this with a production model, nor would you ever hear of it. I recognize a cliff when I’m about to jump! 😀

            I guess that when I first heard of versioning, the manner in which 3DSMax can save backwards came to mind. I can create a 3DS file that would open in an earlier version for someone that only has an older version of the software.

            I deduce that this is not what was meant by “versioning” in X-Plane. In order to provide a similar capability in X-Plane’s Plane Maker, you would have to maintain all of the various file writer versions going forward, selectable during a “save as” operation.

            So my last paragraph is really what a developer needs to do going forward. If their product is built and focused on the functionality of a particular flight model version, then they can only save and re-save their product in that particular iteration of X-Plane. In that way we will always get the flight model that our product needs, and it won’t change with subsequent improvements or other alterations of the flight model. This would be how I would maintain the fuel flow characteristics and jet engine model so that my fuel use prediction code would remain reasonably accurate.

            And it follows that I have complete control over when I want to re-save the ACF in a newer version of X-Plane, and thus determine when I want to adjust my plugin code.

            Does this sound better? Sorry for tweaking you a bit there! 😉

  2. Very impressed with Vegas! Was there no notes about the ATC because Tyler wasn’t there?

    The effects of the water coming off the wheels on takeoff was very impressive, but my thoughts were could the same effects be used to simulate the engine thrust on the ground in the same wet conditions, it would have to be connected to the throttle position as well and in that is the one thing very noticeable out of aircraft windows… heat haze was also excellent. Will you also provide a tool to put out spot fires!

    1. There’s no relationship between Tyler’s absence (he had a previous commitment) and our not mentioning ATC. Chris is working on ATC now but what he has wasn’t far enough along to make the talk.

      In the movie, engine spray on the runway was actually in there too.

  3. Hi Ben,

    sounds like Vegas went well. I did not follow / see any announcements, thus not sure how in depth the particle system is. Beyond that, are there any additional eye candy items you can share? ie- weather updates, new aircraft ( such as that Citation )

    Thanks

  4. It was great to meet most of the X-Plane team at FlightSimExpo. The openness of the team to answer any question was quite refreshing.

    Indulging me in my question related to my quest to fly Linux X-Plane in VR was very much appreciated. I plan to get some Steam VR games that run on Linux to help me resolve any issues until Vulkan comes to X-Plane.

    It was also great to meet the many people that I only knew from a screen name or a email.

    Lastly I was quite impressed with the X-Plane presentation that clearly showed the passion and depth of the developers at Laminar. I have precipitated in some of the Q&A secessions but being in person was a whole different level.

    Thanks again Bill

  5. Can’t wait to start working with the particle system here at ASDG! AND we are super hyped you guys are FINALLY getting tail dragger issues fixed!

    11.30 HYPE!

  6. In the presentation I remember a bar chart, with (I think) versions up to 11.30 along the bottom, and FPS up the side.
    And side by side were bar graphs of (I think) OpenGL vs Vulcan (or maybe previous render path vs refactored render path)

    Can you expand on that chart? Is it showing work done already, or setting an expectation of whats to come?

    1. There were two charts. One showed fps on two FPS tests across versions 11.05, 11.10, 11.20, and 11.30. It basically showed small improvements through 11.20, and then a significant improvement in 11.30 – that test was run on our in-testing branch. What you’re seeing in that 11.30 number is that some of the reorganizations to get ready for Vulkan have ended up being more efficient than the original code, even when run with OpenGL drivers.

      The other chart was the actual driver function calls made by Airfoil-Maker, OpenGL vs Vulkan, since we have AFL Vulkan running as of last week. There the Vulkan implementation uses 69% less driver calls to do the same higher-level drawing, as requested by the app. What you’re seeing there is the design differences between Vulkan and OpenGL. Vulkan is big on pre-initializing things and then re-using them; as a result the per-frame drawing is simpler and a lot of “use that thing I already told you about.” While there is _no_ guarantee that 69% less driver calls means 69% faster (the actual numbers will be less), it shows that the structure of the drawing on Vulkan is radically different (and better) than OpenGL.

      1. have you looked more decoupling the frame rate and simulation this seems to be the hold up for frame rate in VR

        if you havent get Oculus Tray tool and turn on your performance monitor hud you will see that the graph hangs around 60 to 70 % but when the sim proper is running it drops off chart to -100% meaning the compositer is wating on frames from the sim this is cause the frame rate to cap out at 45fps EVEN WITH all settings at the lowest or it seems that your running the sim twice as some times itll bounce back up to maybe 10%

        1. I’m not sure how you came to this conclusion. If you _pause_ the sim do you see some massive win in performance compared to flying around?

          Or by ‘simulation’ do you mean decoupling the VR screen refresh from X-Plane _entirely_ (e.g. so X-Plane can run at 15 fps and it will get reprojected up to 90 asynchronously)?

          1. i mean the flight model simulation from the render you know like every other modern game engine does

      2. In other words, I guess we can expect a significant performance improvement in 11.30.

        Coupled with the news of Active Sky Next being release, hopefully, till the end of the year, the new particle system, and Vulkan being released (even in beta), this is shaping up to be a fantastic end of the year!!

  7. It was nice meeting the team at the expo. Ben thanks for making sure those shadow params were still editable =)

    Also, I’m sorry I don’t remember the Art Directors name but, looking forward to those new trees!

    Everything looked great at the show and I’m looking forward to riding along with X-Planes progress. Keep it up everyone.

    1. Sorry, I’m too curious about new trees…
      Are there new additional 3D-model trees coming, or is it about an hi-res rework of the old billboard trees?
      Are they planned to be released with 11.30?
      Judging by the previous new artwork, new trees will be a huge improvement.
      Many thanks for making XP better and better!

      1. I just want to piggy-back off of this and give a big shout-out to the art team. The stock art assets are getting better and better, and whatever has been added with all the recent releases is absolutely top notch.

  8. Hey just want to Say Thank you for your Great product especially the gns and g1000, it Helped me, especially on IR procedures to Save about 5 expensive real world flight Hours for my ME IR checkride in Europe ! Used VR , it is simply great!

Leave a Reply

Your email address will not be published. Required fields are marked *

Please do not report bugs in the blog comments.
Only bugs reported via the X-Plane Bug Reporter are tracked.