Multiple (tiny) airports in one package?

User Support Hub SDK
1

Is it advisable to have a package with several small airfields bundled together?
The tool tip of the Package Name field suggests otherwise (“Strict guidelines: airport-[icao]-[name]”).

Nevertheless, there are some reasons why it would be at least “nice to have”:

  • Release integrity
  • Fight community folder clutter. Apparently there are issues with slow loading times when there are too many folders.
  • Common assets would be bundled in and could be relied upon.

And a few concerns:

  • The “strict guidelines”
  • Potential attributes or elements that are per package but should be different for different airfields. The things I have discovered so far seem to be scoped by the icao name (but does it really work - or is it really package scope). Things like airport services, living world config etc.

Any opinions?
Or are there other ways to do this at a higher level (like a “package of packages”)?

2

It’s comes down to personal preferences.
Some people prefer one airport per package, others prefer as few packages as possible.
You won’t be able to please everyone.

What I’m doing with my (minimalistic) bush strips is to have individual BGL files for each strip, but put them all in one package, so that people can still disable one if needed: Idaho/Oregon airstrips

1 Like
3

I put 191 seaplane-bases in my latest package. No problem if you are structured :slight_smile: Grouping objects is also important as you soon lose the big picture…

4

I just tried it out with two airfields and some additional assets.
I made an “asset package” (BGL) per airfield and more asset packages for materials and 3d objects. Seems to work so far. Even the services.xml and living world config xml seem to work correctly, identified just by their respective filename/folder name.

By grouping do you mean “GroupObjects”? Are you using these instead of asset packages (i.e. one single BGL) or on top of them?