FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: Tolo303sq on September 28, 2022, 12:11:15 pm
-
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
-
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".
-
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...
-
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?
-
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.
-
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…
-
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.
-
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.
-
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.
-
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!
-
Asobo also randomly named and numbered parking at most airports including gates, they are not accurate to the real world.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 ?
-
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.
-
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.
-
- 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.
-
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.