Author Topic: incorrectly parked aircraft at gates using FSLTL  (Read 2934 times)

Transair

  • Newbie
  • *
  • Posts: 32
incorrectly parked aircraft at gates using FSLTL
« on: October 04, 2022, 02:56:17 am »
When I inject FSLTL data into an airport such as YPAD, it places aircraft in incorrect parking spots.  E.g. Jetstar parked In Virgin bays, Internationals parked at domestic bays etc.  I asked the developers of the airport whether they can control/prevent this, but they suggested it is a GSX issue.  Can you advise please?  If so, is there a future edit in gate customisation that limits certain carriers to certain gates, and also that FSLTL would then recognise?
ta

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: incorrectly parked aircraft at gates using FSLTL
« Reply #1 on: October 04, 2022, 01:58:55 pm »
Before discussing any airport, it's always best to be very precise which airport it is, otherwise we can only assume it's the default one, and not knowing this for sure makes the answer longer than it could have been. In any case:

- AI normally park first and foremost by airplane size and type and, secondarily IF the airport .BGL has Airline codes on parking, those will be used to sort out preferences over the other parameters, assuming they match the ones in the AI airplanes themselves.

- Default airports DO NOT use AI parking codes and so GSX jetway replacement files, which are a 1:1 drop-in replacement for default airports, having exactly the same parking spots in exactly the same positions, not using any parking codes either.

This means, when default airports are concerned, having GSX installed or not cannot possibly affect AI placement, it will still mostly random when airlines are concerned, because NEITHER ( pure default or default+GSX replacement jetways ) have ANY airline codes.

If that airport is a 3rd party airport, it MIGHT come with Airline codes in its airport .BGL file, and that that might improve AI placement, but it might affected by GSX, if you don't do what you are normally supposed to do, that is *Disabling* it from Jetway replacement, because that's what you should always do when using a 3rd party airport, and that will remove the GSX Jetway replacement file for that airport, which will eliminate the possible issue of having the GSX replacement file (with no Airline codes, like the default) to possibly affect the 3rd party airport, assuming it DOES have Airline code to begin with.

So, basically, on default airports, AI placement should be identical regardless of GSX, and on 3rd party airport, it will depend on that 3rd party airport having the proper Airline codes in its airport .BGL file, assuming GSX Jetways Replacement has been Disabled there, which is the correct method of operating GSX on any 3rd party airport.

Quote
If so, is there a future edit in gate customisation that limits certain carriers to certain gates, and also that FSLTL would then recognise?

GSX already allow users to both add/change Airline Codes that might be missing/wrong in the original airport .BGL file, but those will only used by GSX when used to service the User airplane.

The MSFS AI system doesn't know anything about GSX customization, it will always use parking types, sizes, positions and airline code from the scenery own .BGL files.

However, considering FSLTL uses custom AI traffic injection, I guess nothing will prevent its developers by adding a feature to READ a custom GSX profile for that airport and use data there to improve AI generation, so any customization already possible in GSX that is normally reserved to the User airplane, might transfer to AI as well.

A custom GSX product is a simple .INI file with a very straightforward syntax, so coding this shouldn't be very difficult.
« Last Edit: October 05, 2022, 09:37:48 am by virtuali »

Transair

  • Newbie
  • *
  • Posts: 32
Re: incorrectly parked aircraft at gates using FSLTL
« Reply #2 on: October 05, 2022, 07:52:58 am »
First Umberto, I thank you sincerely for taking the time to reply and then for your extensiive response.  Greatly appreciated. In the case I quoted, it was indeed a 3rd party airport, among other 3rd pty ones where I've seen this occur.  Hopefully there will be ways around this in future.  Again, thank you for your care and support.