Wrong stands names on some aiports

[Tolo303sq]

At some airports [f.e. LOWS Digital design] in the .ini file names for parking spots are not correct and instead of [parking 1] I got [none 1] and so on [none 2] etc. Previously it was correct and it starts after reinstalling GSX Pro 

[virtuali]

If the parking in the airport .BGL has been set as type "None", GSX shouldn't call it "Parking", it was a problem in a previous version, and it could cause problems when identifying a parking, if there was another parking with the same number that was called "Parking".

Since "None" wasn't very nice to look at, we updated GSX to show "Ramp" instead of parking, which is how those parking spots with "None" as their name are shown in the Main Menu map. However, this means that any .INI file that was made *before* this change should be updated as well.

If you remove the .INI, you should see those "None" gates being listed as "Ramp".

[Wimma]

Well, first of all I am glad to see this implemented, as it was a pain not being able to make profiles work due to multiple stands with the same name. However, this updated raises a few questions, to be precise, two.

Firstly, why are you not allowing us profile creators to rename them to the correct real world name?

Again, using LOWS as an example: the real world stands are called W1,2,3 etc. and E1,2,3 etc. In the .bgl, and therefore also within GSX profiles, they are named parking 1, like you said. So why rename it to some "random" name when you could just allow us to chose the name, making profiles more realistic and fixing "lazy" .bgl development. (I made a post a day after release pointing out this very issue btw.) It is clearly possible, so I beg you, Umberto, let us profile creators do the same thing somehow. Maybe make the positioning coordinates global for the whole airport and not parking position specific so it doesn't have to correspond with the name in the .bgl, or Idk how, but please! This is a much needed feature!

Another thing I don't get is that you said "we updated GSX to show "Ramp" instead of parking, which is how those parking spots with "None" as their name are shown in the Main Menu map", however, why does it say none 6 then when in the menu map this position is named E8, which is the correct real world name?

Secondly, why have we not been informed clearly about such a drastic change to the .ini system?

This update fucks so many profiles (sorry for my language) and I've never heard about that, whilst talking to god knows how many profile creators a day, until a user reached out to me telling me about the fact that his .bgl now has a none 6 parking position in it. GSX is pretty much relying on custom made profiles on 95% of airoprts out there coz, let's be honest" without them it just breaks the immersion rather than contributing to it. So the fact that we know have to check every profile we made is a fucking massive and time consuming undertaking...

[Wimma]

Profile creators basically now need to to make adjustments to an empty proflile on every single stand on every airport to get the new entries into a new. ini file and compare it to the existing profile. Jesus christ this is so flippin time consuming!

Or do you have an easier method of doing that?? Because I don't know how else I could check if any and which of the parking spots changed names?

[Copper]

Is there any way to go back to the previous version (from 25th of September) for the time being to give profile creators time to sort this out?

Do we have any means to replace affected positions manually in the INI file by looking for certain names and changing their names? Or is this totally unpredictable which name GSX assigns to the position?
I can see for instance in the LOWS profile mentioned here that the positions there are called [parking #], so if we know that this specific airport has no actually "parking" named positions, could we just rename them to [ramp #] so they would match again? I'm not sure I understand the change in GSX and the impact in the ini files it causes.

I'm really struggling with these kind of changes since without proper profiles GSX would have been uninstalled for me. And right now it seems like a roulette choosing a departure/arrival position if it will work according to the profile or if it won't.

Are only apron positions affected or also gates? Can we see from the kind of name of a gate/position that it is certainly not affected by this change so we have at least a workaround that we can rely on?

Sorry Umberto, but this change requires a LOT more information to the users and creators rather than just replying in a small thread that the profiles need to be adjusted. This is a huge PITA for all of us.
Also consider doing such changes with a Beta that is made available to profile creators first. Especially since the change was nothing urgent that could totally be held back for a few weeks to collect feedback.

[Wimma]

Couldn‘t have said it any better my friend… GSX without profiles is nothing other than immersion breaking and unrealistic  at most airports and this update ruins a lot of them, I assume. I already talked to a few creators on our GSX discrod and a lot of them can‘t be bothered to look up each stand that was changed and therefore probably won‘t update their profiles.

I am sorry so say that but this update could break the whole GSX Community…

[virtuali]

Firstly, why are you not allowing us profile creators to rename them to the correct real world name?

That's something GSX already can do internally, but it's a planned feature, it only needs to be added to the UI.

Secondly, why have we not been informed clearly about such a drastic change to the .ini system?

That's not a "drastic change", it's a absolutely required bugfix because, in the previous version, if you had this situation in the .BGL, let's use default RJFU airport as an example:

- A spot named "Parking" and number 11

- A spot named "None" and number 11

Before the update, in order NOT to show "None" in the edit and the menu, we used "Parking" for both, BOTH in the menu AND in the save .INI, and this would have caused a problem because, just to prevent to show "None", we created a conflict when the original .BGL was just fine! Because the way it worked before, since .INI files by definition cannot contain duplicate section names, when you edited one, it would mix-up with data from eventual edits on the other one, since editing either spot would always end up in the same section named [Parking 11] this would of course cause a big mess with airports containing parking spots named "None" and others named "Parking".

After the update, these spots with a "None" name will just SHOW as "Ramp", but that's only a visual thing in the menu or the editor UI. As far the .INI is concerned, such spot would end up in a section named [none xx], preventing a conflict with a Parking with the same number, which would have occurred in the old version. Now, the .INI will always contain the "real" name + number of the .BGL, which will prevent any possible conflicts, unless the conflict was already there in the .BGL.

That's why we was a really required fix: if you had a scenery with parking spots named "None" and spots with same numbers named "Parking", it was basically un-editable with GSX, now it will work.

[Wimma]

Yeah I get that and, in its core, this is a very welcomed and needed update! However, it is still unclear to me and many others why this hasn‘t been communicated better and clearer with the community…

One more question: how will this effect „triplet“ stands? At the Freeware EGSS there are L, R and C stands that all use the same name. E.g. STAND 15C, 15L and 15R are all called Parking 15. Is this update going to make all 3 available to edit or just two? I am asking because for now we only talked about two stand having the same name.

[virtuali]

Yeah I get that and, in its core, this is a very welcomed and needed update! However, it is still unclear to me and many others why this hasn‘t been communicated better and clearer with the community…

This was an absolutely needed bugfix, and only affected specific cases of parking spots with the "None" name which ALSO had other parking spots with the "Parking" name which ALSO had duplicate numbers so, it shouldn't have affected that many airports.

However, that's not really the point, the point is the problem should have been fixed in any case, and the sooner the better, precisely to not have too many custom profiles affected by the change. Note that, before the update, trying to edit those conflicting spots would have created a faulty .INI in any case, unless you recognized the conflicts and purposely avoided to edit any conflicting spots, so they won't even appear in the .INI file.

One more question: how will this effect „triplet“ stands? At the Freeware EGSS there are L, R and C stands that all use the same name. E.g. STAND 15C, 15L and 15R are all called Parking 15. Is this update going to make all 3 available to edit or just two? I am asking because for now we only talked about two stand having the same name.

That is the Parking Suffix, and in this update we also fixed another problem. Before the update, parking with suffixes were only recognized as different if there was a Jetway. On stands with no jetway, they would also be treated as one, generating a single .INI section, which would have cause a lot of problems.

Now both cases should be recognized properly to be separate spots, regardless if they have a jetway or not. That's another important bugfix which was really needed for the long term growth of the creators community.

[Wimma]

Note that, before the update, trying to edit those conflicting spots would have created a faulty .INI in any case, unless you recognized the conflicts and purposely avoided to edit any conflicting spots, so they won't even appear in the .INI file.

Yes I did realise it and found a workaround to get at least one stand working correctly. I think for just a random user I have a pretty decent understanding of how GSX creates .ini files and reads .bgls. Please, don't get me wrong here. Of course I am not saying "I know how GSX works in general". I just think that I have spent such a long time looking into how it works that I now have sufficent knowledge to find workarounds, if there is one, and how to figure a few things out myself. These bugfixes and updates really were neccesary, like you said, and I am thankful this is implemented now, although this means a lot of profiles need updates now. But again, like you said, better sooner than later. Thanks for the heads up on this issue!

[Dave_YVR]

 Asobo also randomly named and numbered parking at most airports including gates, they are not accurate to the real world. 

[Copper]

Asobo also randomly named and numbered parking at most airports including gates, they are not accurate to the real world.

To be fair, this topic is not about wrong names in the BGLs but how GSX was changed regarding mapping them in the INI file.

I just had to update every single gate in the CYVR FSDreamTeam profile since the BGL has the "A" suffix set for each of them but GSX so far ignored them. Now it doesn't, so all the contents in the profile were ignored.

However, that's not really the point, the point is the problem should have been fixed in any case

Actually the point is that profile creators should get explicit information in advance about the upcoming change that will impact their work. With clear indication how they best adjust their profiles to avoid too much efforts.
Being thrown into facts of broken profiles and needing urgently to fix them frankly isn't the right approach to a community which your product heavily depends on.

[virtuali]

I just had to update every single gate in the CYVR FSDreamTeam profile since the BGL has the "A" suffix set for each of them but GSX so far ignored them. Now it doesn't, so all the contents in the profile were ignored.

Which is why, together with the update, we ALSO released an updated for CYVR AND a GSX profile for it.

And note that, even if GSX didn't change anything, your custom profile would still have to be changed in any case, because in this CYVR update we also changed several parking spots in the .BGL itself for that precise reason: to add the missing suffixes we didn't had before.

Actually the point is that profile creators should get explicit information in advance about the upcoming change that will impact their work. With clear indication how they best adjust their profiles to avoid too much efforts.

That's not a change, it's a sorely needed bugfix, that affected ONLY very specific cases:

- Airports with some parking spots with the "NONE" name which ALSO have other parking spots in the same airport named "Parking" which ALSO use the same numbers as the "None" ones.

- Airports with some parking spots using Suffixes at non-Gate location ( without a jetway )

As I already explained, in BOTH these cases, those parking spots were UNEDITABLE before, because in the previous version, GSX considered these cases to be the same parking, and customizing one would affect the other, since changes would end up in the same .INI section.

This would result in a big mess if, for example, you changed a parameter in the "None 10" spot ( which was previously called AND saved in the .INI as "Parking 10" ), then went on changing another parameter in the actual "Parking 10", so your "Parking 10" section in the .INI would contain a mix-up between parameters belonging to both spots. And the same was for suffixes.

I'll try to make it even more clear: before, if you had the following parking spots in an airport .BGL:

"None 23"

"Parking 23"

"Parking 23A"

"Parking 23B"

Editing ANY of these parking spots would result ALL changes being saved in the SAME .INI section:

[Parking 23]

Because the previous version translated "None" into "Parking" ( conflicting with the real "Parking" spot ) and didn't support suffixes for non-gate spots, so all 23s were treated as the same spot.

After this absolutely required fix, the same situation now results in the following .INI sections being used:

[None 23]

[Parking 23]

[Parking 23A]

[Parking 23B]

This way all parking would be correctly differentiated as they should have been.

That's why it's just wrong saying this bugfix should have been announced in advance, it's a bugfix NOT a "change", it's how GSX was always supposed to work and if anybody tried to edit those kind of parking configurations before, his .INI file was likely already messed up by containing a mix-up of data belonging to different parking spot in a single section.

[Copper]

That's not a change, it's a sorely needed bugfix

Are you kidding me? Of course is a bugfix a change?!?

That's not a change, it's a sorely needed bugfix, that affected ONLY very specific cases:

- Airports with some parking spots with the "NONE" name which ALSO have other parking spots in the same airport named "Parking" which ALSO use the same numbers as the "None" ones.

- Airports with some parking spots using Suffixes at non-Gate location ( without a jetway )

As I already explained, in BOTH these cases, those parking spots were UNEDITABLE before, because in the previous version, GSX considered these cases to be the same parking, and customizing one would affect the other, since changes would end up in the same .INI section.

Sorry, I said my CYVR was from FSDT but I meand FSimStudios.
There ALL gates were always with suffixes, but since GSX didn't read them, the profile created was without suffixes.
With your change now, each of the gates (they almost all have Jetways!) was changed and the profile was ignored entirely.
The profile worked totally fine before your changes, there was nothing "messed up" since there were no conflicts.

So it is wrong to say that only parking spots with suffixes which were non-Gate locations were affected, every single one gate at that airport was affected!

I am not sure if you misinterprete the impact of your change, but those are facts.

Nobody is arguing that the changes were needed and were not bugfixes. But you need to be aware of what the impact really is. And of course even bugfixes that have a broader impact on existing profiles should be announced beforehand, it doesn't matter that they are bugfixes. It broke stuff that worked before, hence an information is crucial at the very least with the release to have an explicit hint in the changelog that profiles need to be checked and recreated.
I contacted the creator of the CYVR profile that it got broken entirely, they were surprised and fixed it.

[virtuali]

There ALL gates were always with suffixes, but since GSX didn't read them, the profile created was without suffixes. With your change now, each of the gates (they almost all have Jetways!) was changed and the profile was ignored entirely. The profile worked totally fine before your changes, there was nothing "messed up" since there were no conflicts. So it is wrong to say that only parking spots with suffixes which were non-Gate locations were affected, every single one gate at that airport was affected!

The missing suffixes for non-gate spots are one part of the fix, the other part of the fix was the parking spots with "none" names were wrongly saved in the .INI as "Parking", which was a problem and fact THAT particular airport you are referring to wasn't affected, it was only because there weren't any proper "Parking" gates with conflicting numbers OR you never tried to edit them, but it was something that could have happened everywhere.

Nobody is arguing that the changes were needed and were not bugfixes. But you need to be aware of what the impact really is. And of course even bugfixes that have a broader impact on existing profiles should be announced beforehand

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 ? We found it, and we fixed it as soon as we could.

I contacted the creator of the CYVR profile that it got broken entirely, they were surprised and fixed it.

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.

But that's even besides the point, let's forget for a moment the GSX bugfix, and look at another case:

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 ?

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. On the other hand, OUR duty is to be sure GSX performs as designed and any obviously problems, like this one, are being fixed as quickly as possible.