It would appear that the entire set of updates this morning through FMS Data manager have been released with a Cycle Info file identifying them as cycle 2101 valid 28 Jan 2021 - 25 Feb 2021, but dated as 7th July 2023.
First observed when opening SimToolKitPro, then also confirmed when looking at other datasets downloaded at the same time.
I have not yet had a chance to see whether this is also a factor in the MSFS navdata hub, but I’m sure you’ll figure that out quickly from your side if it was a simple file copy error.
Just as info, this file is ONLY for us, for our support and should not be used by any third party addons becuase we can’t guarantee that this file will not be removed or changed by us.
Hi,
how have you identified that the cycle is not updated? I have checked the navdata files and all are build from 2307. There is only one internal file called cycle_info.txt which is outdated but this file is only for internal usage and was never be designed for external usage.
This file will not be updated any longer, if some addon uses this file, please inform the 3rd party developer.
Hi,
thank you very much - this file will not be updated any longer. This file was only be designed for our support and internal usage but never for 3rd party addons. There is no documentation for this file, nor have we accept that this file can be used.
Normally this file should be removed with this cycle but due a wrong copy process here, it was still added but outdated.
There is a cycle.json file, which contains following:
This file will be used by our new Navigraph Hub to identify which cycle/revision is installed - it´s a kind of replacment of the old cycle_info.txt file. But also this file should be used because we can´t guarantee that we don´t change the file from time to time.
The recommended way is to add the information directly in the addon dataset like STKP as an example. Simtoolkit uses an database and here you have an own “header” table with all the information:
The cycle info file is used by XP 12 and all other 3rd party add ons to the degree that when you load up an aircraft with an FMS, the FMS is reporting the wrong AIRAC cycle. Thats not a good thing and so what will happen when Navigraph stop issuing this file in future updates? What will the FMS show then?
Hi,
no thats not correct. XP11/12 don’t use this file, possible any 3rd party addons for X-Plane but we don’t know which because again, this file was only for us to identify which cycle is installed.
This file is un-documented and we never have official supported this file, sorry.
This is helpful to know it’s an internal file but third parties have been using it, and it’s been included in all of your downloads for quite some time. The only reason it created an issue is it was coded incorrectly for the date of the actual NAVData. Wouldn’t it be better for your paying customers to simply state it was an error and will be fixed vs. stating it’s an internal file only? Also, vs. pulling the file from said third-parties, are you offering another way for the developers to identify the correct cycle?
Hi,
we have offered a fix for this cycle but again, we don’t know which addon does use this file. The normal process for 3rd party devs are, that they request the data specification or they send us their specification. When I look back, in example LevelD 767, the requested a own fmc-file with specific AIRAC information to display this in their addon FMC … that addon was for FSX!!
It is easy for us to implement it, but we must know this - currently, we don’t know it because it seems that some developer had used this file automatically without talking to us.
Again, I have created this file and you can download it via the link for the current cycle - with AIRAC 2308, this file will not be included any longer:
We are open to talk any other solution or about our prefered/recommended way (ie. the new cycle.json file, which still contains the cycle and revision number) to offer the AIRAC information, but the initial contact must come from the devs.
Would it not have been better to give a deprecation notice, well in advance, and allow time for things to adapt? Perhaps folks should not have been using this, but it does seem to be the case that several are. Maybe update this cycle and replace it, and then give more advance deprecation time than a month?
I’m not sure if you have understood me correctly. This file is a complete unstructured file, only for US but was not designed for any 3rd party addon.
We haven’t receive any questions/request if the file can be used or not, it looks that the addon developer has used it without asking us, if it can be used or not. Again, if you open this file you will see only text, but no real structure.
We don’t know which 3rd party developer used this file. I have uploaded this file now for 2307 but we will stop to support it with the next cycle, which is nearly 3 weeks away - so enough time I guess, to let us know what information, which 3rd party dev needs what. Again, we have no information of it because it was since day one a un-documented/un-supported file.
We are ready to offer any information in a structured way - a good example is now SimToolKitPro, or also Pilot2ATC. The devs told us his requirements and we are currently implement it.
Oh my goodness. As the OP of this topic I must say (with every bit of respect intended) I am sorely bewildered by the direction it has taken.
I have to pick you up on your repeated statement that this file was internal to your project as some kind of irrelevance, and that some other folk appear to have failed to understand this.
I respectfully must point out that your project team appear to have failed to understand the idea that if you release a massive and chronologically sensitive dataset for absorption by hundreds of differing end-user simulation platforms - which also includes within the dataset a file that appears to identify “which batch of data this is” - that people might actually use that file in an attempt to identify “which batch of data this is” - at all levels from the thousands of end-users, to the developers of the interlinked platforms themselves.
I do sincerely applaud you guys for responding so rapidly to this issue and seemingly connecting with devs to establish workarounds, but I have been quite perplexed by the coupled reaction that these devs had got the wrong end of the stick and should never have been looking at that file - which sticks there looking like a big happy label.
Once you release something its all out there, externally. Analogously, in another walk of life I sometimes write and record music - I don’t then tell people “Oh hey, don’t listen to the drums man; they are only there for my internal reference!”.
Have to agree. The solution offered is to pull back something that was internal, but clearly useful. Even if not used by third party developers, it’s useful for all users of the nav data to determine the effective dates of the cycle that they have installed. While one could look up the AIRAC dates elsewhere - why should they have to? It seems incredibly backwards to say that something is an “internal file” after having discovered that third parties are indeed using it in a rational and intelligent manner. Not documented? Sure. Then document it, standardize it, and do something useful with it.
Playing “keep away” with the cycle_info.txt is just plain petty. Arbitrary. You don’t see Aerosoft doing this with their cycle_info.txt, do you? The value of a standardized “readme” with cycle information is something that I think any sensible developer would want to share - and share aggressively - rather than to take a stand on a trivial point of order.
If this silliness continues, consider me a former customer.
… to come to an end of these really unfair discussion, without any understanding of the arguments I have decided to keep the file and I’m working on the revert of my coding.
I will create a second revision of the whole cycle as soon as I’m ready with the development and adaption of my code.
