Wrong stands names on some aiports

[Copper]

Those are bugfixes and should be fixed as soon as possible. What are you suggesting, make a poll or create a committee and wait for their deliberation before releasing a fix ?

Where did I state anything like that? Clearly I did never ask for a poll or a committee.
But that derails the discussion from the point I made - to inform the community *before* pushing out the fix or at least CLEARLY communicate what was changed and that it potentially breaks profiles and what to do if it does.

But if you're keen in putting words into my mouth and then arguing against that, you clearly are not open for that kind of feedback/criticism.

If this was an airport that had multiple parking spots with "None" names AND parking spots with "Parking" with numbers conflicting with those Parking spots AND possibly Suffixes too, if we didn't do the fix, it was even IMPOSSIBLE to create a GSX profile for that airport let alone fix it, unless the author realized the problem and decided to not touch any of these spots.

*sigh* Its NOT about the changes themselves but how this change was rolled out. Please read what I and Wimma wrote once again. It's getting tiring to tell you that it's all about communication, not the change itself.

what if the original developer of a scenery makes major changes to the airport, like renaming lots of parking spots, because the airport changed, the first version had issues, any reasons (totally possible and completely within his right), should he supposed to contact all GSX profiles authors or just users of that scenery to alert them of the change, because it might break their profiles ?

It's a difference if ONE profile breaks compared to MANY profiles breaking. Don't you think? Hence your comparison is invalid in this discussion.
And of course if a dev is interested in supporting the community, they could add a proper changelog informing about which changes have been done and informing third parties.

The point is that GSX profiles are an integral part of GSX, but they are not an integral part of addon airports. Hence bringing airport changes into the discussion of this GSX change is totally derailing the discussion again.

That just to say: GSX profile creators should try to stay on top of things, especially when they are doing a profile for a scenery they didn't do.

"should", yeah. But you're making that task with intransparent and sudden changes more than hard.

I wish you would realize HOW important those community profiles are for YOUR product GSX and would treat that work of others with more respect since they are a big reason for your sales.

[virtuali]

Where did I state anything like that? Clearly I did never ask for a poll or a committee. But that derails the discussion from the point I made - to inform the community *before* pushing out the fix or at least CLEARLY communicate what was changed and that it potentially breaks profiles and what to do if it does.

Now I see you are conceding we shouldn't have delayed the fix just to announce and explain the changes. So yes, we'll try to explain it better. Even communicating takes time, and it's not as if we are not already working overtime to improve GSX day by day.

"should", yeah. But you're making that task with intransparent and sudden changes more than hard.

And again, you continue to confuse a change with a bugfix. The program is now finally working as it was always supposed to. BEFORE it was "intransparent", since you couldn't possibly figure out, when editing those parking spots, where all your changes ended up.

Now it just works: each section name matched the name of the actual parking spot in a scenery, very simple, it shouldn't even require to be documented, it's simply working correctly now.

I wish you would realize HOW important those community profiles are for YOUR product GSX and would treat that work of others with more respect since they are a big reason for your sales.

This kind of comment seems to miss the point entirely: how much time/money you think has been spent on MAKING the GSX editing features available in the first place ? How do you explain a very significant part of the manual is dedicated to the customization features ? And why when a bug in the editing features is found, is fixed with the highest priority ?

[Copper]

And again, you continue to confuse a change with a bugfix.

A bugfix is a change. And in this thread it actually doesn't matter since the bugfix did in fact CHANGE the behavior and broke profiles.

Please take the required time to (clearly!) communicate changes/fixes if they have impact on other's work. Even if that means to delay the release by a few hours.
Since you dedicate so much of the manual for the tooling, please reserve the time to communicate code changes if they have impact on existing stuff.
Just saying that creators "should try to stay on top of things" isn't enough. You are the one that needs to make that possible, they are relying on your communication as noone else could provide it.

As for the upcoming airport data API usage I really hope that either it doesn't break profiles or it comes with some migration support or at least an early access for people to test against.

[virtuali]

A bugfix is a change. And in this thread it actually doesn't matter since the bugfix did in fact CHANGE the behavior and broke profiles.

Sure it's a change, but it's not a change that is supposed to be communicated in advance, because it would just make the program to work as documented, when it wasn't before.

As for the upcoming airport data API usage I really hope that either it doesn't break profiles or it comes with some migration support or at least an early access for people to test against.

That's a good point.

Of course it will have some effect on profiles creation, but for entirely different reasons: now profiles are "tied" to a specific .BGL, because GSX "knew" which .BGL was active when that profile was created, which came as a result of GSX having scanned all the MSFS content for airports, to be placed in the airport cache so, GSX knows which .BGL is active when you enter an airport.

Using the new Navdata API will change all of this, which will of course make GSX so much more reliable, because it won't have to read .BGL files, but the downside of it, is precisely that GSX will no longer "know" which .BGL was in use, and the Navdata API doesn't provide that information, because is not really important to know which .BGL contains an airport, when you can just ask all data from it to the sim.

It's clearly a major change, and it would be the first time ever we could get data about an airport without having to open its .BGL, which is a massive improvement in simplifying our code and reduce problems.

So, how do we tie a custom profile to a specific variation of an airport ? Assume an hypothetical user wanting to edit KORD going through the following steps:

- Started with MSFS Standard version, editing the bare default KORD

- Later upgraded to MSFS Deluxe version, which has an Asobo handcrafted ( and encrypted ) version. The old .INI file is no longer valid, so we should start a new one

- Later upgraded to the FSDT KORD. A 3rd .INI file should be created.

The current GSX will work in this situation (not entirely, because it couldn't read the encrypted KORD), because each time the .BGL changes, a different .INI file will be associated with it, but what to do when we don't have the .BGL file anymore, because of the usage of the new Navdata API ?

We are considering several possible solutions:

- A check to match parking spots names. To be loaded, all parking spots in the .INI should match the ones obtained from the Navdata API for that airport, otherwise the .INI won't be considered valid. It won't be a problem if the airport has more parking spots than the .INI but, all the ones in the .INI should match the ones in the airport. This solution is less likely to be affected by bugs, but it's more restrictive in case, for example, a 3rd party developer updated a scenery and changed the name of a single parking spot which was customized, it might result in the whole file being rejected.

- A partial matching system, loading all parking spots that found a match in the airport data, and discarding the ones that didn't. This will ease the loading, but it will potentially result in losing data about non-matching spots that have been discarded.

Both solutions have advantages and disadvantages, but assuming we are doing everything right, they shouldn't require actual *work* by the profile creator, because once the .INI is considered valid, all data in it should work as before.

[Copper]

- A check to match parking spots names. To be loaded, all parking spots in the .INI should match the ones obtained from the Navdata API for that airport, otherwise the .INI won't be considered valid. It won't be a problem if the airport has more parking spots than the .INI but, all the ones in the .INI should match the ones in the airport. This solution is less likely to be affected by bugs, but it's more restrictive in case, for example, a 3rd party developer updated a scenery and changed the name of a single parking spot which was customized, it might result in the whole file being rejected.

Please don't implement this approach. As I discussed with other creators, that would be a nightmare to figure out which of the parkings is causing GSX to ignore a certain profile.
Make it tolerant, at least for some time. And add log output that there are unrecognized/invalid parkings. This way users can still enjoy it mostly working while creators have time to fix their profiles if there are discrepancies.

[virtuali]

Please don't implement this approach. As I discussed with other creators, that would be a nightmare to figure out which of the parkings is causing GSX to ignore a certain profile. Make it tolerant, at least for some time. And add log output that there are unrecognized/invalid parkings. This way users can still enjoy it mostly working while creators have time to fix their profiles if there are discrepancies.

It's not as easy as it seems.

How much "tolerant" should be this check ? How many unmatched parking spots should we allow, before deciding that, maybe, that .INI was meant for a different version of the same airport ?

And, you shouldn't forget the issue I already explained of editing a scenery with a version of an airport, and then continuing after having changed the scenery, something GSX can detect now (it will create a new .INI), because it knows about the .BGL, but it won't anymore when it will just ask the sim for the airport data.

If the check is strict, it would be extremely unlikely that two versions of the same airport would have exactly the same parking spots, so we could be reasonably sure than yes, maybe it's time to open a new file for editing. But if the check becomes tolerant, it's very difficult to decide how much tolerant should be, for example:

- A .INI created when Scenery A was active, featuring 100 parking spots, all edited with care, including all GSX vehicles starting positions and custom Stops to match the scenery ground markings, and custom pushbacks to match the scenery taxi lines.

- You buy Scenery B, which has 120 parking spots, 80 matching names found in A, 20 not matching.

Let's assume we set the tolerance level at 20% so, in this case, we decide to not open a new .INI file, because the new Scenery B is just barely inside the tolerance level, so we load the existing .INI and as soon you enter the editor, you realize that even if we had 80 spots matching, they are not in the same positions, which will result in all your existing carefully placed GSX vehicles start positions, all your custom Stops not matching the ground marking of the new scenery, all your custom pushback not ending on taxi lines as they did, because the new scenery has a different taxiway layout as well.

So, you need to fix all the spots again and, if for any reason you want to switch back to Scenery A ? You must fix the .INI again, and don't even have a backup, because GSX being "tolerant", decided there wasn't any need to open a new .INI file and let you continue on the existing one.

Lowering the tolerance level might reduce this chance, but still you could reproduce the same issue if we had 90/10 matching/unmatching spots, with the matching ones all in different places.

So no, it's not as easy as if seems, maybe we can do something like calculating a matching "score" and present a list of .INI candidates sorted by score, so users can choose which profile to load.