Release Schedule – A Rough Timeline

Here’s a rough road-map for getting X-Plane 10.20 and friends out the door:

  • X-Plane 10.20: if all goes well, release candidate 2 will be posted overnight and you’ll get a crack at it this weekend.  RC2 fixes a few crash bugs and sets up Lua memory allocation the way we want it to be for 64-bits going forward.  (I also plan to post the rest of development materials for Lua plugins tonight.)
  • X-Plane 10.21: we are planning a 10.21 bug fix release.  It will include bug fixes that we have already coded but didn’t want to put into 10.20 late in the game.  It will also include new apt and nav data from Robin once he gets the next release done, and possibly more autogen. (If 10.21 goes out before the next autogen drop, we’ll do a 10.22 for autogen.)  We’re not looking to do anything major or disruptive in 10.21.
  • WorldEditor 1.2: WorldEditor finally has some (desperately needed) time on the road map; this should allow me to close out the major bugs in 1.2 and get it posted.  This is a high priority for us; we’ve done most of the work for the new airport system, but it doesn’t do anyone any good until WED 1.2 goes final.  (Yes, you are reading correctly, WED 1.2 is earlier in the road map than an X-Plane release.)
  • X-Plane 10.30: we don’t know when this will be or what will be in it with any kind of certainty, but there are some areas we’re looking at, like fog and visibility (where we have a mix of bugs and feature requests that might go well together).  I think that even for 10.30 we’ll be in “fix what we already have” mode, not “add more stuff” mode; we want to make X-Plane 10 as stable, solid and fast as possible.

One of the goals of this roadmap is to make sure that 10.20 itself is a stable 64-bit release that authors can target and users can run.  One reason why late bug fixes are going into 10.21 is to avoid delay in getting a solid, ‘final’ 64-bit release to everyone.  (We also expect that at least one major bug that was not reported during the long 10.20 beta will pop up as soon as we hit “final”, hence the expectation of 10.21.)

Please do not turn the comments section into a guessing game about 10.30; we don’t have a precise list of what goes into it, and if we did I wouldn’t post it anyway, because it’s likely to change over time as we get new data.

I have some specific comments on airports and ATC, but that’ll be another post.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
This entry was posted in News. Bookmark the permalink.

26 Responses to Release Schedule – A Rough Timeline

  1. JazAero says:

    Hello Ben:
    Now that it appears and you’ve got a better handle on 10.20 are there any projections in the works for the AC 3-D plug-in to be brought up to speed and incorporate 10.20 features for aircraft developers? I just think it’s long overdue and deserve some attention at this point, what do you think?

    Keep up the good work
    Jim
    JazAero

    • Ben Supnik says:

      Not right now, no. Ac3d plugin updates are lower priority than WED. We have to get WED done and out first before we can look at any other scenery tools.

  2. Eric Demers says:

    Will you do a scenery recut for all of us flying VFR with no lakes or roads?

    Open street maps has evolved a lot since the original release of X-Plane 10.00 and it would be much more enjoyable to fly in remote regions.

  3. Luca says:

    That’s great news, would vfr atc be considered an atc update/fix or a brand new feature?
    :-)

    • Ben Supnik says:

      VFR would be a large brand new feature. The ATC has the brains to track and talk to IFR pilots, mostly. It doesn’t have the logic of a tower controller looking at the pattern out the window. It is something we want to do, but we intentionally cut out all of VFR to create a smaller self-contained set of features; having half of IFR and half of VFR would be really useless.

      • Ilari says:

        We at TruScenery are amazed by what you guys are doing..please consider VFR ATC at some point..would go great along with the smaller airport sceneries :)

  4. chris says:

    Good post ben thanks, should the new autogen be including Lit’s for buildings; a realistic feature limiting the night experience.

    have a good weekend

  5. carrotroot says:

    I absolutely love WED, but I’m keeping my expectations low about the road creation feature graduating from it’s current gimped status.

    • Ben Supnik says:

      Right – road creation is _not_ scheduled to go into 10.2. I wrote some experimental code to be sure the atc network code could someday be used for cars…but it doesn’t make sense to delay 10.2 a lot to finish it.

  6. NLS says:

    So when is 10.30 coming?

    (ok joking joking! :D )

  7. Robin Peel says:

    Just an update on the airport and nav data …

    I have fixed two bugs:

    1 – PAPI/VASI lights that have been missing from some airports have been reinstated. This impacted older airport designs (pre-WED), some of which still lurk in my database. This bug was introduced when I added a new primary key system to my database last year. A missing join criteria deep in the underbelly of a set of SQL Server stored procedures caused some PAPIs to be placed at the wrong end of the runway (you can see this on one of KCMH’s runways in my current data release). Took a while to spot it.

    2 – A small number of duplicate glideslopes and marker beacons have been eliminated, at airprots that have multiple ILS systems for a single runway. This was triggering issues in the sim at KSFO runway 28R (which has an ILS *and* a separate, offset LDA-GS). This was caused by a subtlety of my new primary key structure in my database (again!), coupled with some ancient code (dating back to the DAFIF era) that was used to auto-align some localisers, glideslopes and marker beacons with their associated runways. This has all been simplified and fixed.

    I have also accumulated 350+ airport updates – each update can contain dozens of new airports, so I am working through this list. About 160 still to process. Sorry for the delay in processing these – a change in job last year, plus some other time-consuming activities. Getting to Burning Man (yes, really) and organizing a National Narrow Gauge Convention sucked all my spare time out of my schedule. When I get these remaining updates into my DB, and have tested as many as I can, I will release an update. Lost of great updates, including some major new airports. It will likely be release 2013.03, hopefully in the first week of March.

    - Robin

  8. Michael says:

    Would it be possible to sneak in longer contrails? They are already part of the simulation, so changing the lenght wouldn’t be a big deal, would it? It’s a pretty small feature but it makes a huge difference.

  9. Steve says:

    Ben — Will WED 1.2 address the airport exclusion zone problem for the new scenery types? Some rather nice sceneries are getting corrupted by housing in rather odd places. The .org has it that you were thinking that would be handled by a change to X-Plane, but with the most recent RC for 10.20, the problem persists. As X-Plane counts on scenery devs to make product to populate the world outside of northwest Washington state, t’would be a favor to get this bug squashed.

    • Ben Supnik says:

      Hi Steve,

      I have no open bugs on exclusion zones. Someone should file a bug on that. I believe that the problem is _probably_ user error, perhaps caused by poor documentation, but only with a real bug report can I even know what people think they are seeing.

      cheers
      Ben

      • Steve says:

        Thanks, Ben. Will do. I’m surprised — after digging about this issue on the .Org, with even the likes of Tom Curtis having issues in one thread I stumbled on, I would have thought this would be known. They even invoked your name. But no matter, I’ll be happy to file another bug that happens….with *any* aircraft. :)

  10. Alain Lafortune says:

    Visibility, is all I need.

  11. Greg says:

    Transonic and supersonic aircraft took too much of a performance hit in a past update. When will the F-4, B-1 etc performance get back to their real world numbers? 10.30

  12. Sven says:

    Hi Ben,

    are there any plans on changing / improving the antialiasing algo´s to get rid of this awful looking texture flickering? Also the next question: When i fiddle around with AA i only have the CPU being maxed out, the gfx card still idles around (well… 0.2 to 0.999). Could it be that the AA is not computed on the GPU in certain cases? (GTX 570 and GTX 680 tested here, both nearly the same results, on an i7 3770). Thanks!

    • Eric says:

      I have same issue with the flickering. Its seems like its certain apartment buildings and certain types of comercial buildings that flicker. I haven’t noticed the residential housing flicker. When you zoom in with the camera, you will notice the roof flickering from white back to black.

      • Eric says:

        There is some flickering with HDR off as well. I think its the same buildings. Maybe there is an error with the art work ?

        • Ben Supnik says:

          A few things are clear from this thread:
          1. No one should be posting bug reports on this blog. This is not a bug reporter!
          2. “Flickering” is a really vague term. I have heard the term flickering applied to Z-thrash (flickering of two near surfaces due to incorrect depth testing on the GPU) and also to temporal anti-aliasing) the flickering of small 3-d details as the camera moves.

          So I guess I can say two things:

          If you see a particular art asset flicker, even when you are close to it, that’s a bug. File a bug using the bug report. Here’s what we need: take TWO screen shots in a row, capturing the art asset in both phases of flicker. For example, if the roof is changing color, take a few screen shots in a row and send in two where the camera is in ALMOST the same place but with different colors on the roof. We can then go find that art asset you showed us and see what’s wrong.

          Over time we will continue to adopt better anti-aliasing technology as it is invented and becomes available. In the meantime, users who are unhappy with the anti-aliasing in X-Plane can do a few things to cope:
          * Turn up X-Plane’s anti-aliasing setting and turn down the screen resolution to compensate for the fps hit.
          * Turn off HDR, then run at a high non-HDR anti-aliasing level like 16x.
          * Turn down the world level of distance: temporal anti-aliasing is heaviest for small features on screen, which come from far draw distances for 3-d.