A very “professional workaround” to remove proven, working 3rd party data only that a confirmed bug in the sim (whereever it is and what name you give it him) can be “solved”, without any specific timeline when it’s fixed.
And I see this as much more critical, when you wrote that this is a hidden bug since SU4, what can be happen, of course but than, you should try to fix it immediately and not in 6 weeks plus because some 3rd party companies had trust the system since SU4.
Sorry, but thats not acceptable and we will discuss and escalte this internally now. To remove our working data, is not an acceptable “solution” without to know how long. You exclude deliberate, Navigraph user to use stock sim feature.
really, with 40-th anniversary SU it can be also big problem. If i can highlite again my last previous bugs discovered:
hook of keyboard during set of field inside NXi with keyboard feature (Icon), still sim’s commands are executed at background.
NAV1 DME not correctly functional, ADF DME presented, colors.
If any one can also confirmed, pls report. I had hook keyboard with NXi problem just with that non sence ‘P’ pause feature after click in field key ‘P’, that put my sim to some not clear state, sitting in cockpit at ground (no speed) I completely loose sound there, like position with pilot were set some where outside???
I agree absolutelly with Richard from Navigraph, this must be solved ASAP and is not acceptable to leave users in this problem. This must be solved ASAP.
So should it not be possible to revert to the old package load system with a hotfix until you have a reliable fix for this critical bug? Otherwise it sounds like weeks to come without the ability to use Navigraph data in G1000Nxi, PMS750-WT and VFR map “only”. This seems absolutely critical to me and I wouldn’t be surprised if this affected the upcoming releases of the CJ4, G3000/5000 and GNS 430/530 also.
A worrying thing to happen, since we have often been told that old FSX era code was gradually being ripped out, and replaced, rather that re-integrated.
The PMS GTN 750 in WTT mode is currently working with Navigraph data. As a test you can easily find the Austrian intersection BRENO. Tested in the steam gauge caravan with the beta-WTT-package from PMS and in the Cessna 414 with the PMS GTN 750 + WTT livery. This is very helpful since all of PMSs replacement packages that put the GTN750 into the G1000 bezel are now also using WTT mode. However PMS succeeds maintaining Navigraph compatibility in WTT mode, I hope he can maintain this for the future. So I have to omit the G1000Nxi “only” when using my Navigraph data.
As i said already in my previous post with Seneca screenshot.
I said, with GTN750 with WTT system, all ok after test with Navigraph. Only pure NXi aircraft I expect as problem with Navigraph. Aircarft with default sim NAV Blue nav data working ok, also NXi. I have some temp solution, will do in few minutes, PMS offer also bezel to C172 G1000 and any other NXi aircarfts so maybe now is this good temp solution but no NXi planning system. Very big THANK YOU to Scorpion. Hope all relevant devs understand this critical problem and will do fixes ASAP.
Update: C172 G1000 with GTN750 bezel working perfectly. You need use only GTN750 nav device for flight planning and other option, no PFD FPL and DCT-TO.
Unfortunately, this will not be possible no, due to timing (the cert/publishing/testing process at this point would take more or less very close to SU11).
Sorry, my deepest apologies, my intention is not to have folks leave this uninstalled forever, but we do just want the best user experience for everyone, as we know you folks do as well. As folks on your way and pointed out and I apologize for, the upcoming Navigraph airac will be more up to date than the sims FAA data when that releases until the sim updates the airac.
As we’ve already described the issue as deeply as we can here on this thread, these are the last comments I’ll be making here on it. We understand the frustration that this causes for all the affected users and teams are working towards a solution.
Folks - in the interests of keeping this topic on-point, I direct all interested parties to review Richard’s bug report linked below, and contribute accordingly. Let’s have ALL the conversations and input associated with this sub-topic routed there.
I’m not totally sure where I gave the impression that some code is being “re-integrated”, if I did I apologize. As is often the case in software development, legacy systems that have yet to be replaced oftentimes become sudden candidates for replacement or modernization when knock-on effects in those systems caused by other modernization work in otherwise unrelated areas crop up.
There’s no sound reason to throw out legacy working code that has stood the test of decades of use “just because”, but sometimes these effects can become the “because”.
I couldn’t think of what “legacy pre-MSFS” code could be other than FSX code. Using old code is fine if it works, but if it’s causing issues, maybe rethink that? Perhaps it’s a case of that old code being used in a way that was not originally intended?
In a codebase double-digits millions of lines of code in size spanning decades of work over multiple development teams, “just don’t use old code” is not a reasonable global decision point. As in all things large scale enterprise development, when and how to modernize or replace legacy systems is a complex case by case analysis involving dialing in risk factors, existing code limitations, bug exposure, testing time, potential for large or small scale regressions, and the like.
But, we do appreciate all the well-intentioned development advice.
Engine pages are enabled by the aircraft developer by providing the correct page tags in the aircraft panel.xml. You would have to ask Carenado about what they do or don’t support.
Is there any point using the github G1000 or G3000 versions because they are now part of the default MSFS aircraft software? ie just use them for payware aircraft if required?
Bit confused but thankyou for you help
One question: having a VFR flight plan loaded in the G1000, I can see the TOD to my destination. But, once I select the active runway in the flight plan (after hear the ATIS) the TOD disappear. Why? maybe a bug?
Another one: I understand that the TOD is calculated based in the destination airport elevation. Is any possibility to change that elevation and set the traffic pattern altitude instead? If I remember correctly it’s possible in the real one, isn’t it?
