Yes, that is (sadly) intentional. When the new GPS was introduced in X-Plane 10.30, we found that the old 2d instruments had the button commands mapped backwards. So the choice was either to break ALL old panels, or keep the command mapping reversed for compatibility. Sadly that means if you are making a new instrument in 3d, you need to reverse the commands tied to the RNG buttons, just like the old 2d instrument always was.

Ah – there IS an open “bug” that the free-flight doesn’t automatically change to show your new destination when you complete a flight, so if you do nothing, you end up back at the first airport. You can also work around this by picking a start place at the new airport when you pick the new airport. It’s slightly more time consuming but pretty easy in the new UI.

Given that pretty much _everything_ that was not developer-facing has been rewritten, it’s going to take a few patches to get that kind of deep detail into the UI that smooths out the rough edges.

🙂 Thanks for the reply Ben ! I really appreciate the kind words after that rant!

On the nitpick, I didn’t want to change aircraft mid-flight, but just get into another plane when safely back on tarmac … the other option is not something that I even want to consider .. though if I suddenly want to fly a glider at Mach 0.78 at FL 320, I am sure I can figure out how to do it some other way!!!!

Yeah, we know this affects pro customer training too.

+2 you cannot simulate IMC at night presently in this sim.

Well, you could guess that from our call for developer resumes a while ago. 🙂

But…don’t think that “throw more warm bodies at it” is going to change the fundamental dynamics. There’s no way we ever have a development team so big that we can do everything at once or talk to everyone all the time. 9 women can’t have a baby in one month and all that.

Hi Sudipta,

In the end of the day, we hung this release on four tent-poles:
– New UI
– New lighting engine
– New higher quality airliners
– New European autogen

This meant saying no to major upgrades of other parts of the sim. At this point modern flight simming has become too complicated, too detailed, too realistic, and too advanced for us to revise _every_ subsystem in the simulator in a single release. The days of “we upgraded everything” are over. (This was possible in 2002 when everything was a lot simpler and computers were not capable of more.)

The decision to not upgrade everything was very intentional – X-Plane 10 was a _messy_ release – 2 years later than intended and very, very buggy, with a long overhang just to get quality up to par. One of the biggest reasons for this was that the scope was too grand. With ACES gone, our plan was to make EVERYTHING awesome, and the results were unmanageable. The goal with v11 was definitely to make _some_ things really good and have them actually work.

So if the things you most want aren’t on our hot list, I cannot possibly fault you for not being excited about the new release. But we had to make a call, based both on what we thought was most important for our users and what we were most able to develop with our particular development team.

Finally, I’m going to nitpick just one part of what you said, because we do get asked for this feature occaisionally: at no point has it _ever_ been possible via X-Plane’s UI to change aircraft mid-flight, and if it was possible to do so via the plugin SDK, this was due to a lack of error checking in the SDK, not a feature. We design the flight model under the assumption that the physics data about a current flight is _not_ portable to another plane. You can’t take off in the 747 and turn it to a Cessna while you’re doing 400 knots ground speed at 40,000 feet. This is a design requirement of Austin’s physics engine and we have no intention of ever changing it; we believe that at the very, very best we could do a ton of work to get strange results for a feature that isn’t that useful for real use of the sim.

This has been proposed many times, and even tried a few times, including inviting developers to public forums and even making private forums for just the LR development team and users who (in the judgment of the people starting the forum) were worthy of such access.

None of this worked…for several reasons:
1. The development team is made up of…developers – we’re not huge fans of “forum” software as a way to communicate digitally and we absolutely do not use such a thing internally. (Internally we use email, text chat and VoIP, with shared docs/blogs for persist info.) So we’re perhaps congenitally unlikely to “keep up” with a forum full of styling, side bars, wasted space, and giant avatars, with uncurated chronological threads.

I can only speak for myself, but if you file a bug and say “see this forum thread” I bang my head on my desk a little. SOMEWHERE in the thread is probably the info I need, but finding it feels a little bit like mining.

2. The ratio of development team to everyone else is pretty unfavorable, and there’s just too much info to keep up with. My in-box has already totally exploded to the point of absurdity. One of the reasons I keep shouting things like “file a bug” is that it’s one of the few areas where at least we have a _process_. (Albeit that process can still be leaky, something that needs addressing.)

Sudipta is not the only one who has complained about the lack of visibility into bugs, and I agree that it is a problem. (We have the same complaint when _we_ file bugs to vendors like the GPU IHVs and OS developers.)

The flip side of this is that our bug feed is incredibly noisy. The WED bug feed is noisy too (you can browse and see how many “bugs” are tech support requests or badly written reports) but WED is a free product, so letting the bug base just stew a little bit is less of a problem, and the X-Plane bug feed is _much, much_ noisier.

As an interim step, I’ve been considering at least giving out the internal bug numbers (those XPD-xxx you see in the notes) when a bug does make it into the bug base. (Some bugs don’t make it into the bug base because they get fixed immediately, or because they’re dupes, or because we don’t think they’re bugs, etc.) This way at least when you have to go “hey have you fixed my bug”, with the number, it’s really trivial to check.

We also need a better way to collect feature requests. The old mechanism was “email Austin”, but this isn’t great because the entire development team isn’t Austin anymore. I need to talk to the other developers about what they’d like to do for this. The dev team doesn’t read the blog comments diligently enough to scrape -everything-, and our coverage of the forums is poor. (Marty keeps up with the forums more but it’s not the same as scraping them.)

A lot of companies use their bug base for features (we have done this in the past) but I’m not totally sold on it as a way of working.