What we mean is that your mod is altering navsystems.js file from the stock one, and it affects the rest of the screens that read that file. Whatever your file does, it ultimately ends up in user complaints when an SU update comes out and our screens stop working for users using your mod since they read your custom file the way you have it configured. That is what you should fix.
Let’s see, we don’t care what your mod does, as long as people don’t come to us to complain when a screen stops working and it turns out that it’s your fault if you don’t do the maintenance in a timely manner. And as long as your mod is configured to modify the shared files used by the other screens, I’m not going to have a good opinion of it. Your mod should work independently without affecting other systems that use the same shared files.
Yes for that you are right.
We need to do that for all aircraft builders that provide GPS switching in the cockpit in order to block the update of hidden GPSs. There is some missing functionality in the Asbo code for managing that and this can’t be done in a specific mod file.
The modification we made are minor ones (2 lines of code) and this doesn’t change the behavior of the original Asobo code.
Anyway, we are always publishing the updated file at the same time the SU is released. Updating the GNT750 to the latest version solves the issue at this time. We have asked Asobo to include this GPS switching management in the navsystems.js file.
Since the sim is always evolving, every sim update requires also updating the mods to their compatible version.
I think the problem is that many users don’t see the relation and can’t fathom that a GNT750 mod could affect Concorde which clearly doesn’t use it. Thus the support burden on other developers.
I don’t know if there’s any way you can make it more clear to users that they should uninstall your mod before any sim update and only install labelled compatible versions.
Yes for sure, I understand that.
Every sim update has consequences on Mods and often on aircraft too.
It’s a normal situation to get into trouble after a sim update and for sure, the first thing to do is to check the Mods and aircraft and verify that all this stuff is compatible with the new sim update.
For finishing the subject, the modifications we are doing on navsystems.js are the following ones:
We block the update of a GPS if the cockpit builder has set a specific L variable. This is to avoid conflict with a hidden GPS. If this variable is not set (and for sure the Concorde will not set it) the update occurs normally.
We block the automatic activation of the approach in the flight plan because it should be done at the GPS level. We do that only if a specific variable is set in the cockpit so again one time this can occur only if the aircraft builder decides to do it by setting the corresponding L variable.
You can trust the minor navsystems.js modifications we made at 100%. We have a very good knowledge of the Asobo code and architecture and we exactly know what we are doing. We’d prefer to not have to modify the navsystems.js but there is currently no other solution.
The navsystems.js is not concerned by the autopilot and we are not modifying any stock Asbo behavior around that. More generally, the GTN750 is like an interface to the sim, we send orders and we get the sim state for displaying the GPS pages. We are not changing the sim behavior.
For max climb mode I feel it somehow weird at high altitude. Cause it kept wanting to achieve max speed but vs would be kept at approx 3000ft/min and so at times, the IAS goes way higher than 550knts as is the max in Concorde’s gauge, at times even at ~650 and triggering the wing overheat or over speed warning, which when arriving FL600, it goes idle for a while and settle down at Mach 2.04
Any chance it’s a bug or imo the max climb should try maintain the ias to 550knts and the rest of energy goes into climb speed? Then max cruise will be trying to achieve Mach 2.04
I understand that but there is a difference with the real concorde and it is that the gauge does not show IAS but CAS, while ours is IAS. An example would be that at 60,000ft, the mach 2.04 to CAS equivalence would be 440, when at IAS it would be 540, just as at 50,000ft the IAS would be beyond 600, which exceeds the gauge limits, while the CAS would be around 540CAS. The speeds are being applied correctly. We simply don’t have or don’t know how to calibrate that gauge right now to show CAS instead of IAS right now.
It is not a simple display problem, but even an FMC stops working because of that file, and therefore cannot perform the autopilot operations that it has configured.
Everything revolves around that file, and any modification you make will affect it to a greater or lesser extent. And I feel very sorry for the users, but for us the world is not going to revolve around your mod. If a function of the FMC is not going to perform as it should because your mod is interfering, we will advise against uninstalling it
The other way around. It is IAS and not CAS, I explained it a few days ago:
This official chart shows the envelope limits of the Concorde, and we thought this chart was IAS when in fact it is CAS and I even compared it to one from the F-15. That said when you are at 60000ft the gauge is showing 540IAS when it should be showing 440. Similarly, at 50000ft your gauge will show more than 600IAS when it should be showing 540 at mach 2.0. You are not overstepping the limits since we use mach as a reference to not overpass, we simply cannot calibrate to CAS right now as its value depends on each aircraft and a different conversion factor. In MSFS at the moment IAS, TAS, Mach, but not CAS can be displayed without problems.
The correction we made was that you can reach mach 2.0 at 50000ft even if IAS exceeds 540 IAS since IAS is not calibrated for the Concorde and therefore when before you were limited to mach 1.9 by the autothrottle now it does not and you can travel to mach 2.0.
It’s not your fault guys, but the GTN-750 does, as CodenameJack has pointed out, interfere with other user products such as Concorde. Removal of the mod solved their issues ( likely your update has also fixed things by now ). That was all I was referring to.
Ic, then the trouble/bug comes the other way. Currently at max climb the Mach speed can goes through the roof to something like 2.14-2.17 and the over heat warning goes off. And only when it climb to set altitude of FL600 it will reduce throttle from full to idle for a while to let speed drop to 2.04. Any chance to make it kept at M2 max and prioritise climb speed?
Oh so you mean when climbing with max climb, it reach even 2.17? That’s weird, happens all the time? what’s the ISA degrees of the temp gauge displaying? i can give a look.
yes in the climb. but that only happened once. otherwise the concorde “only” reaches that at 60000 feet. In general, as has already been written, 2.17 is not a rarity! I would like to record this but that is such a thing with the xbox!
I usually past FL 300 would just engage max climb, ins and alt acq to FL600, it will just keep full throttle but after initial reaching climb speed at ~FL330? And keep the v speed max at 3000ft/min, and so the speed keeps climbing to M2.17 and only when it reached FL600 will suddenly goes idle and maintain speed at M2.04
