No jetways...

[Ankh]

Hi all, I wonder what I did wrong here: I used to have an exclude file for LSZH (scenery by Aerosoft) to get rid of their default jetways, and the corresponding gsx files for SODE jetways. While this works perfectly, I do not see any jetways in Prepar3d v5. Now I wonder why? I have other airports where SODE jetways are working correctly. Why are they absent from an airport where I added them manually? Thanks for any hint,

Regards
Chris

[Ankh]

No one? I now tried it from scratch, sitting on LSZH, excluding the default jetways and adding my own, this somehow works. But as soon as I replace the .ini file with the one from v4.5, no jetways visible. Do all the .ini files need to be adjusted with v5?

[hotbso]

Same with Aerosoft EDDF.

[virtuali]

P3D5 has updated A LOT of default airports and, because of this, if a scenery came with an Exclude file made for 4.5 ( which uses a database that hasn't changed from 2006 ), it will likely not work with V5.

This because lots of developers ( including us, our older sceneries ), have used in the past the "micro-exclude" method, to fix an old bug that is still there from FSX times, that if you created a "global" exclude, it would end up excluding even jetways from the scenery own layer, not only the ones below it ( as it should be ). The way to fix this, was to create many small micro excludes, centered around every object of the default scenery.

This wasn't ideal, because it added a whole new set of problems, like seeing double objects if you had another scenery for the same airport that wasn't default, but at least allowed jetway to work.

This affects only default jetways, SODE/GSX are entirely unaffected by this bug so, in our later sceneries that always came with GSX/SODE jetways, we stopped using the micro-exclude method and when P3D V5 came out, we also updated almost all our AFCADs to use the single exclude method, and in some cases ( PHNL, for example ), we replaced its default jetways with GSX/SODE version, to prevent the bug from happening without using a micro-exclude.

So, basically, every scenery that was made with the micro-exclude method, will likely have to be updated by the developer, because the default scenery has been updated.

[Ankh]

Thanks for this clarification, Umberto. But this still does not explain why I can generate an .ini file myself in v5 resulting in jetways visible at LSZH, but if I use the .ini file from v4.5, no jetways are visible. Possibly related to your answer, but it would be nice if you could also shed some light on the .ini files.

[virtuali]

The jetway positions in the .INI file creates the FSDT XML Exclude, which were in turn base on the original scenery. Could be the scenery you are using HAS been updated already by Aerosoft ? Most of our updates for V5 were, in fact, new AFCAD with new exclusions.

[Ankh]

Hmm, interesting. So you basically need the exclusion .xml file for the .ini to work? Might be the issue then, I am almost sure that I just tried adding the .ini file, but not the exclusion .xml file, as for Zurich after the update, jetways must be disabled by naming two .bgl files to .off in the scenery folder of the airport. I thought that if I do not have to exclude something, I also do not have to have the .xml file. Wrong, obviously...

[virtuali]

Hmm, interesting. So you basically need the exclusion .xml file for the .ini to work?

If the scenery you are customizing originally came with standard jetway ( anything that moves with CTRL+J is standard, even if it looks custom ), you need to exclude them first, and then you can start customizing it with GSX.

To Exclude them, you need .BGL Exclude, which is compiled starting from the Exclude XML. The Exclude .XML is created by GSX when you click the "Exclude Radius" checkmark, with positions based on the AFCAD which was active when you ORIGINALLY started that customization

That's why, if the scenery changes, even if it's only the exclusion, you'll have to redo the GSX .INI and recompile the Exclude XML/BGL.

[Ankh]

Ok, I think I did not describe my issue precisely enough, I start again: the Aerosoft LSZH scenery is exactly the same that I use in v4.5, it was not updated. It is included in v4.5 and v5 via the add-on.xml variant, so all the files from the scenery are 100% identical in v4.5 and in v5 (as it is the same folder).

To have GSX Level 2 with SODE Jetways working on AS LSZH, I need to disable two .bgl files in the AS LSZH folder. It does not work with excludes (also not working in v4.5, there I have double jetways if the two .bgls are not renamed). However, I have a working .ini file for v4.5. I have all jetways replaced.

Now, I thought that it will simply work as that in v5, but it does not. Using the exact same configuration in v5 results in no jetways at all, that is why I asked.

EDIT: it seems that it was just my non existent patience. I now repeated the process and clicked twice on "restart couatl and rebuild airport cache" and after several seconds, there was a short stutter and all jetways appeared. Strange. I guess I made a mistake somewhere when I was trying it the first time. Means: the .ini that works in v4.5 also works in v5. Perfect. This prevents me from a ton of new configurations, as long as the AFCAD stays the same, good to know.

[virtuali]

I now repeated the process and clicked twice on "restart couatl and rebuild airport cache" and after several seconds, there was a short stutter and all jetways appeared. Strange.

Not strange. Is this scenery coming from alternate AFCAD files, with different names ? For example, depending on wind conditions, or with static/dynamic AI, etc ? If yes, and if the scenery comes with some kind of external utility that switches between the two, there are the following issues to take into account:

- You'll need a separate GSX .INI file for each of the different AFCAD the scenery can possibly use. If the AFCAD have different names, that's fine, because GSX will track of each .INI file associated to each different AFCAD, but you'll still have to create them.

If, instead, the AFCAD name is always the same ( hope not ), but different ( and not compatible ) files are switched externally, that will be very difficult to sort it out, since you cannot be sure the same GSX .INI will work for both, if they are different, for example using different parking assignement. I haven't seen many developers using this method, but you'll never know...

- Also, depending on the way the external configurator works, if it renames, copies, it might result in GSX not being able to automatically detect a scenery change, that's why there's the "Restart and Rebuild the airport cache" option to begin with: to manually force an update in those cases when, due to external switches, a change in AFCAD might not be detected automatically.