I mean, I've literally never seen this issue before a couple months ago, seemingly before upgrading to HF1 or HF2. Not on 5.0, not on 4.5, not before that.
Of course, the bug appeared only in 5.1. If this wasn't enough proof for you it's not a GSX problem, I don't know what else could convince you.
I also don't see this issue with any other menu-based applications, such as ActiveSky or the SODE menu.
It happens with those as well, maybe you haven't noticed but, it's a very well known fact that, sometimes, when calling Active Sky menu, it shows up with GSX entries, or the opposite, you call GSX and see the Active Sky menu entries.
Further and undeniable proof it's not a GSX problem, is the fact it's not fixed by choosing "Restart Couatl" and requires a simulator restart. This because it's NOT GSX "stuck", it's the simulator own menu that is stuck instead.
You seem to have a very long history of deflecting blame for issues with your products. Third-party development is a multi-way street which not only involves responsibility for the first-party to support you developing your product, but you also taking responsibility to keep customers happy.
Many times I've been shown "history" of an issue happening with an FSDT product, be it GSX or sceneries, you're quick to deflect blame onto someone else, usually LM.
Wrong. You have seen what you THOUGHT it was an "issue happening with an FSDT product", when it wasn't.
If you checked how the "history" ended and, guess what, it always ended that it was FIXED WITHOUT OUR INTERVENTION, clearly proving we were always right pointing to a bug in the sim.
Some examples:
- A certain P3D point release had a bug of menus auto-select themselves, making GSX impossible to use and, guess what, the problem WAS FIXED BY LM, with no need to do any changes in GSX.
- A certain P3D point release had a bug of menus causing crashes in VCRUNTIME after being called many times, and again users were quick to put the blame on GSX, just because it's the most popular app that use the menu. Guess what, it was "fixed" by LM by switching to the new Html menus, because the crash wasn't obviously caused by GSX, but the dying Scaleform platform the old menu was based on that was out of support for years, after Adobe killed Flash and sold Scaleform to Autodesk.
- Still not fixed, the menu size sometimes becomes too small, not allowing to see all GSX entries. Again, users come here, expecting we should do something but, of course, it's a known P3D bug that happens only with some 3rd party airplanes, resulting in the Simconnect menu being too small. Not all users are aware it can be resized with the mouse, so they assume GSX is "missing entries", when of course GSX doesn't have anything to do with this.
- P3D 4.0 had a bug with multi-liveries in vehicles appearing black. GSX has thousands of multi-liveries variations and users were of course quick to put the blame on GSX, as usual. Guess what, was fixed by LM in 4.1
- The floating building at KORD V2 ? Another example of a bug which WAS fixed by LM in a subsequent patch. But since we *could* find a way to side-step this, we were able to release a workaround, clearly proving two things at the same time: that we were right about being an simulator bug ( the hotfix proved that ), and we DO release workarounds when we CAN, even if the bug was NOT our fault.
So no, history shows here that each and every problem we said it was a simulator bug, WAS a simulator bug in the end, and was always fixed with an Hotfix.
(and in some ridiculous cases, tomato for TS)
The only thing ridiculous here is that you would expect we'd chase issues in modded shaders too. Just visit PMDG or Aerosoft forum ( these are only the ones I know of ), and read about their opinion of issues with their products and modded shaders.
It's clear there's been some change in the way menus work in P3D, most likely with 5.1 and the defaulting to HTML-style menus.
Sure there has been, that's precisely the reason why reverting to the old menu fixes the problem.
Your mistake here is assuming is there anything we could do from our side, as if the changes to HTML required any changes on our code. As explained so many times already on this forum each time P3D comes out with a new bug in the menu system that users mistakenly assume it's a GSX bug, the Simconnect call to create a menu hasn't changed in YEARS, and doesn't give the application developer much control over its appearance and much less its behaviour. We just set a title and a list of entries, and make a Simconnect call that hasn't been updated since FSX so, it's entirely LM burden to be sure it works to specs.
There's no such thing as a "new 5.1 SDK for menus", in case you were wondering if we should have done something different "just" because the menu changed to Html. The Simconnect API call to create a menu is still the same, how the simulator creates and process the menu is entirely outside our control.
How about instead of immediately tossing the issue back over the fence, maybe try and come up with some workaround (one that's built into the product so the issue doesn't come up, rather than pointing people to a thread when they experience an issue in the sim) instead of blaming other people?
I don't know if you haven't read my previous reply entirely, or you chose to ignore the 2nd part, which does EXACTLY THAT: providing a workaround, which is switching to the old Scaleform menu system, that is still supported and will fix this problem until LM will fix it properly.
I'll post the link AGAIN:
http://www.fsdreamteam.com/forum/index.php/topic,24661.msg163780.html#msg163780That user, of course, immediately realized it's an LM bug.
