This post is a request for commentary (RFC) – that is, it’s the beginnings of a discussion on the specific topic of mesh and overlay scenery packs. A quick note on moderation: unlike normal blog posts, I’m going to kill all off-topic comments for this post. We’ll have non-RFC posts and the discussion will be more free-wheeling, but in this case the goal is to have the comments for the post really flesh out possible solutions to one specific problem.
With that in mind, our topic of discussion: how best to separate mesh and overlay scenery packs?
New Scenery Packs Can Cause Chaos
Here’s how scenery packs work now: all scenery packs in “Custom Scenery” out-rank all of the scenery packs that ship with X-Plane. Except we put some of our scenery packs into “Custom Scenery”, so that strict “customizations bypass default rule” is already a bit broken.
Within the custom scenery folder, the scenery_packs.ini file defines the priority order of packs (and can bypass packs). When the sim runs, new packs discovered at startup that aren’t in the .ini file are added to the front in alphabetical order. So “newly installed wins” is the effective policy.
Here are some things that go wrong:
- When a new mesh scenery pack is installed, it goes to the top of the priority list, hiding default Gateway airports below it. Custom mesh authors often want the latest Gateway airports to “show through.”
- If a user manually reorganizes their scenery packs, they need to keep custom overlay airports above the default Gateway airports but custom meshes below the Gateway airports. If the user just puts the Gateway airports at the top of the list, custom overlays get replaced.
We regularly see user logs with 500-1000 custom scenery packs, so while I think a nice UI to organize pack priority might be nice, I don’t think it solves these problems. Telling users “go rank 1000 random items in priority order” is impractical.
Separate Custom Overlays from Custom Meshes
So my first naive idea is to simply have two custom scenery folders: one for overlays and one for meshes. Every pack in the overlay folder would completely outrank the meshes folder. This idea begs a bunch of implementation questions:
- What happens if a custom scenery pack is put in the wrong folder (e.g. a mesh in the overlay folder or overlay in the mesh folder)?
- Where do Gateway airports go? Do they live in custom overlays (and if so are they always ranked last)? Or do they get buried somewhere inside Resources and always rank between overlays and meshes?
- Where do library packs go? Library use isn’t mutually exclusive with overlays or meshes.
- Is either folder “Custom Scenery” for compatibility? If not, do we simply have no “Custom Scenery” folder, or does that break too many add-ons?
One of the strengths of this idea is that it’s really dumb and simple, and sometimes when the problem is “we have a complex mess,” simple and easy to understand is better than “really clever.”
Automatically Prioritize Packs Upon Discovery
An alternative to two install locations would be to have X-Plane determine the pack type upon first discovery and then rank it in the priority list in the middle if it’s a mesh.
If this were to work, the win would be that it would “just work” with no changes for third parties or users. However, I think in practice it may not be practical – it would be a lot of file sniffing by X-Plane at startup, and the categories of mesh and overlay are a little bit fluid. If a pack contains an overlay and a mesh DSF, how do we categorize it? If the scenery packs are in some scattered order with meshes on top of overlays, where do we put the new scenery?
Author-Selected Rankings
Another lever we can pull is to allow scenery authors to annotate their packs (perhaps with a text file or new library.txt directive) indicating the appropriate installation ranking for the pack. This approach would be similar to automatic prioritization, except priorities would be explicit and cheap to discover.
Authors would opt in; some kind of default behavior would have to be defined for legacy packs. Some open questions:
- How would authors define where they want their packs installed relative to other packs?
- Would users still be able to customize ranking? If so, would weirdly-ordered packs make it difficult to prioritize new packs?
Author-Selected Sub-Folders Within Packs
This idea came up during some discussions in the third party developer Slack channel: we could introduce a scheme within scenery packs to allow a single scenery pack to include both base meshes and overlays. X-Plane would automatically load all overlays from within these packs first, then global airports, then all base meshes. There’s some nice wins here:
- This scheme puts the burden of correct organization on authors, not users, which is better for support load for third party authors – third party authors already need to know how the scenery system works in detail.
- This scheme solves a related problem: packs that contain a base mesh and a few custom airports can now be distributed as a single pack rather than several packs that are each installed separately.
- Categorization of packs is cheap, as it is simply based on file location.
I don’t think I can give you much useful input on the main problem. But as far as the UI for the scenery organizing goes I think it might be something worth looking into. I have been using xOrganizer and it did a really good job sorting the scenery automatically by type and even country as well as making it easy to order the few it didn’t do automatically. It also has map view with everything. Something like that built in XP or as separate program shipped with it could help a lot of people who struggle with scenery ordering.
Separating all LR scenery from custom one might be a good idea too, I have had issues with the demo areas getting out of order because I didn’t think about them being there.
One of the things I like about X-Plane, is it’s simplicity to maintain. So using different directories for the custom sceneries would be the right choice in my opinion. It’s simple and rven helps to organize the ever growing list of installed sceneries.
I would probably even go so far, to introduce several subdirectories within custom_scenery. Airports to into the airports folder, libraries into libraries, and so on. Technically speaking you have airports, libraries, overlays, orthos and meshes. That’s five types (== directories) or did I miss anything?
I Like your Idea, but in case that they do that, we would still have to organize the specific order, so it means we would have to do that in 5 different folders, correct?
I mean, we would have a scenery_pack.ini for each subfolder, and if we make a mistake on one of them this could break a lot of scenery…
Is my understanding of this correct?
I think multiple folders _does_ imply multiple ini files, but I’m not sure the consequences of screwing them up would be worse than they are now – they might be less brittle.
– You could nuke an .ini file in one folder and not the other for a partial reset.
– You would not be able to bury an overlay with a base mesh by an .ini mistake.
– Overlays might not need a lot of ordering if they’re for different airports.
Just wondering if ini files would be required anymore. Because of the different folders, you already know the type of the custom scenery. For airports, the order is probably not important. Same applies to libraries. For overlays and orthos the order could be important, especially with overlapping sceneries.
Why not just read the packages in each subdirectory in an alphabetical order. It’s simple enough and most people already use prefixes like y and z for overlays and orthos. This would save you and the users the hassle to deal with INI files at all.
Ok, in that case, what if an under custom scenery we had an Airport subfolder with priority one which we would use to place very specific regional scenery (it would also accept mesh, ortho and overlay data if it is contained on the specific scenery folder), than a Mesh subfolder with priority 2 with mesh data for larger areas, so if a mesh is not found for a specific area on the P1 folder, the mesh available on this one should be used for that region, also an Ortho folder with the same priority and specs of the mesh folder for Ortho data, and for the last a Library subfolder just for organization purposes?
That could make custom scenery easier to work with and to debug when a scenery fails!
Wouldn’t it be possible to indicate that mistake somehow? E.g. it’s depicted in red or something like that?
Personally I would prefer having 2 separate folders, one for mesh/autogen overlay scenery, one for 3rd party overlay scenery (airports landmarks etc). Additionally, it would be ideal to have the mesh folder just be read alphabetically, no ini. It would also be nice to have Global Airports being placed somewhere in resources and being inserted between Custom Mesh and Custom Scenery.
The reasons I would like 2 separate folders are:
1.) Like you said, it’s simple. Simple is good, especially for users.
2.) Users won’t have to mess with the ini. As is, most developers use the naming convention Z Mesh, Y Overlay, so everything in the mesh folder would be naturally sorted, and without an ini it won’t be abused by developers (they’ll be forced to use a proper naming scheme vs the user having to edit the ini) and users won’t be able to accidentally mess it up.
3.) Even if a user does put something in the wrong folder, when they come to a developer with an issue it will be incredibly easy not only to identify the problem, but for the user to fix them.
4.) Installation of complex packages will be substantially easier, especially for non tech savy users.
Having Global Airports and other X-Plane default scenery outside of Custom Scenery would ideal because:
1.) The folder structure for users would be cleaner.
2.) User’s can’t accidentally delete them.
3.) User’s can’t accidentally put them above a custom scenery they shouldn’t.
4.) User’s would never have to touch the ini for any reason as far as I can tell.
A sample structure might look like
> Custom Scenery
> KDEN
> Custom Mesh
> Prefab Airports
> World2X-Plane
> Y KDEN Overlay
> Z KDEN Mesh
> Z Ortho4XPTiles
Resulting in a load order in X-Plane of
KDEN
Global Airports
Prefab Airports
World2X-Plane
Y KDEN Overlay
Z KDEN Mesh
Z Ortho4XPTiles
IMO having no user-customizable .ini is not a good idea. I think ordering only based on the alphanumerical sorting of the pack names is significantly more unpredictable, unwieldy and less clean than maintaining a separate .ini which can be easily edited with a text editor and even annotated with comments for better readability if necessary. Users and authors should be able to name their scenery packs as they please without the need to use weird prefixes…
Also, keep in mind that any scenery ordering WITHIN overlay, mesh or library categories is entirely up to the user’s preferences and thus there is no “correct” way to do it that can be pre-determined by the scenery authors or X-Plane itself for that matter.
Keeping custom airports in Custom Scenery would not break plugins that are dependent upon apt.dat. Meshes – Custom Terrain. “Mesh” may not mean much to Joe User, but the idea of terrain == dirt and rocks and water, etc., would probably help in the semantic journey to a new folder system in X-Plane 12.
Meshes found in Custom Scenery would just pop up one of those friendly “You’ve Got A Problem” messages.
The simpler and more subtle the change, the less the churn.
The “Author-Selected Sub-Folders Within Packs” sounds really good at first except in cases where the user wants to override either the overlay or mesh parts (or both) with DSF’s from “legacy” packs (i.e. without sub-folders). Since prioritization won’t be obvious from the location of the scenery pack in scenery_packs.ini it will make it even trickier for the user to understand and debug correct scenery ordering when she or he requires that option.
Therefore to make this more predictable/visible it could be advisable to automatically create separate entries in scenery_packs.ini for each of the pack’s sub-folders so the user can shuffle them around if needed. A possible default ranking for overlay sub-folders would be at the very top and for those containing meshes it would be just below Global Airports.
I would not advise to change the load order “internally”. Make sure scenery_packs.ini always reflects the actual load order including any pack sub-folders.
Combining everything into one folder (mesh, overlay, objs) sounds great but it won’t mitigate users’ confusion. The problem is that most users look at a folder full of folders and a bland text file and their neurons short out (especially 100s of folders). Debug session over.
The GUI resolves more issues than you give it credit for. Retaining the current single folder (Custom Scenery) is certainly the easiest installation process for said users. The ability to then configure these packages in a GUI with search functions, shift+click selecting, and more detailed enable/disable options would resolve much frustration. Otherwise users will still get confused among the order and ranking of default scenery vs. Ortho4xp vs. overlays vs. custom meshes at airports, etc., as described in the thinly versatile scenery.ini.
My thoughts on this, is that pro developers will do the correct annotate to their packs… but a lot just won’t, they are either (usually) lazy, or don’t understand the correct system requirements or even naive… I see this all the time.
I’d not change folder structures at all. Here is my counter proposal:
Just do a subset of what xorganizer does to keep the scenery_packs.ini in a meaningful order:
– move everything with an apt.dat in it to the top.
– move everything with base mesh scenery (only have to test the very first .dsf to find out) to the very bottom
– everything else (like libraries, autogen overlays, landmarks) always will be put in the middle group.
XP should do all that while maintaining the relative order of the objects within the same group. So anyone getting the .ini sorted out “right” or using xorganizer – these scenery_packs.ini already comply with this heuristic and will therefore still work the way they are.
Example:
I
1200 Version
SCENERY
## Airport group ##
SCENERY_PACK Custom Scenery/My_KDPX_V1.2/
SCENERY_PACK Custom Scenery/KSEA Demo Area/
SCENERY_PACK Custom Scenery/Global Airports/
### Middle Group – Libraries, Autogen Overlays, Landmarks ####
SCENERY_PACK Custom Scenery/OpenSceneryX/
SCENERY_PACK Custom Scenery/ORGX_Part A/
SCENERY_PACK Custom Scenery/MrX_Library/
SCENERY_PACK Custom Scenery/KSEA Demo Area/
SCENERY_PACK Custom Scenery/Global Airports/
SCENERY_PACK Custom Scenery/ORGX_Part B/
### Base mesh Group ###
SCENERY_PACK Custom Scenery/UHD_MESH/
SCENERY_PACK Custom Scenery/ORTHO+45-123/
SCENERY_PACK Custom Scenery/ORGX_Part C/
SCENERY_PACK Custom Scenery/HD_MESH/
Next – _within_ each of the three groups, there may be some sceneries that like to be installed in a certain order. Like Landmarks above Autogen overlays. Both have no apt.dat in them, both are no base mesh – so they go into the middle.
Let Authors optionally add a file “Priority.txt” in the root of their directory, specifying a number of +1 (or higher) or -1. This forces X-Plane make more specific changes within a group – sort all priority 1 to come first sceneries first, all priority -1 at the end and the rest that have no priority file will never be moved, so user can put then anywhere within the group they want – even above any priority 1 library. If a new file that wasn’t yet in the .ini is encountered by the sim – its added as per its priority – 1 at the very top, -1 at the very bottom, no priority just below the last existing one of priority +1 within that group it belongs into.
So in the above example – the ORGX Part A (Landmarks) should have priority +1, ORGX Part B (the autogen overlays) priority -1 or better no priority file at all, as that implies in the middle.
And the Global Airports get a priority file saying -1, so they will be at the end of the airports group. But otherwise – for airport the priorities make no sense as any user should be allowed to freely move airports around.
Now in the rare case than an user _really_ wants to override these priorities set by a sceneries author – delete the priorities.txt files and x-plane will no more enforce its position with its group at all.
For base mesh sceneries – a good recommendation would be to make low-res mesh priority -1, high res/UHD mesh get nothing (so its ontop of low-res and locally replaces it) and only single-tile meshes like for custom airports that are absolutely essential should ship with priority +1.
X-Plane’s Global Scenery continues to be loaded below anything in the scenery_packs.ini, so it behaves, sortof, like a base mesh with priority -2, below anything else a user could put in the scenery_packs.ini.
IMO enforcing load priority via author-specified priority.txt file upon each start is a double-edged sword with the potential of making the debugging of scenery ordering issues even more difficult than it is now since it won’t be immediately obvious which scenery packs provide a “custom” priority and which don’t – making it difficult to understand why any particular scenery pack ended up at its current position in the .ini. Also, It will provide an additional layer of potential screw-ups by authors not understanding the concept properly and potentially abusing it.
I could see some added benefit only if this is applied once upon detection of new scenery packs and/or with a special entry in the .ini/log.txt that highlights their desired author-specified custom priority group for easier debugging (eliminating the need to peek into each priority.txt to get an idea of what’s happening).
Displaying or even modifying/disabling the priority meta data would almost certainly be picked up by tools like xorganizer.
“We regularly see user logs with 500-1000 custom scenery packs, so while I think a nice UI to organize pack priority might be nice, I don’t think it solves these problems.”
This is very true. Always favored a text base organization over an gui such as xorganizer which I think do the same job as you described..
So how about an installer as a devkit tool?
When example an airport developer has completed his scenery, it can then ba packed with a custom installer. This installer then package the airport and assigns a file id labeling system.
Example for “Aircraft packages”
002_EGKK_Airport_Roads
001_EGKK_Airport_Main
where lowest id always has the highest priority.
It gets then installed automatic into i.e. “Airports” folder under Custom Scenery
Anyway, just an small example for what it is worth.
I currently utilize file shortcuts for for all of my Ortho mesh files, keeping them on a separate drive which keeps my XP11 drive available capacity high. By doing this, its very easy to organize the current scenery.ini file and recognize these mesh line items. This is similar to the Ben’s suggestion about having 2 separate locations. I really like using a single file to control the priority loading of both overlays and mesh. The difficulty is some of the custom scenery is difficult to determine its priority, especially when it contains both mesh and overlays… and also what the priority of a specific overlay is among all the other overlays you have loaded… it gets confusing very easy, meshes are easier for me. I like the idea that developers at least report this, which is similar to putting it in the readme file under installing. I suggest classifying a given overlay and/or mesh, which would match a section within a single scenery.ini file that has sections for the different mesh and overlays, based on priority. So this way the developer who knows the scenery best, specifies what section that falls within your scenery.ini file… it takes most or all of the guess work away from the user. If a scenery package has multiple items of priority, that would be specified in the package. This I believe could be coded and would populate it to the top of that particular section. An example of a sectioned scenery.ini file may look like this: meshes, photoscenery, large area overlay, regional overlays, small area overlays, global airports, custom airports.
I have 2.7TB of scenery (mostly ortho) on a secondary drive that’s linked to XP on my SSD (500GB). I’d like to be able to link XP12 in a similar way.
A few thoughts based on experiences in customer support and as a developer:
What does a user want? Definitively not messing around with sorting and prioritizing hundreds of sceneries and dependencies. A user just want to activate (or deactivate) a certain scenery-package for a certain region. Such a scenery-package then consists of sub-packages like airports, other overlays like autogen, base mesh, and dependencies like libraries. A user, however, should not have to worry about all of these sub-components. I’m, however, very skeptical that a prioritization can take place completely automatically. This requires imho additional info from the developers of the individual scenery-packages.
What does a developer want? Personally, I like the idea of scenery-packages, because that’s actually exactly what we already provide, for example, with our Maps2XPlane sceneries – they consist of several sub-packages: 1. Custom Airports and Helipads, 2. Custom Overlays / Autogen, 3. Custom Base Mesh, 4. Custom Libraries. So why not put together scenery-packages that contain these sub-sceneries in sub-folders. A simple “definition file” can then provide info about the priority with which the individual sub-sceneries should be loaded, and possibly also whether they are exclusive or not. In addition, allow to define dependencies like third-party libraries or even other scenery-packages.
Just my first thoughts…
I fully agree. End users should not be expected to fiddle with file structures, ini files, or any internal configuration of the sim.
It is a great strength that XP allows a lot of fiddling for power users (that’s one reason why it is my favourite sim, and why there is so much free content for it), but it should never be expected of a regular user that wants to add some scenery.
So information on how to layer a scenery should be part of the scenery. XP 12 should have some logic for roughly organizing legacy scenery, but from there on, developers and home brewers alike should provide information on what level to stack their scenery pack. If things don’t work right for specific legacy scenery packs, the community will probably fix it.
Add show/hide controls to the sim configuration gui, all the rest should be defined by the scenery maker. If a scenery messes things up, pro users can still tinker with some new kind of scenery specific .ini file, and consumers will shy away from the scenery until someone fixes it.
I think a handy tool like xorganizer that is either coming as an addition with the xplane installation or even better, directly integrated in the software, would be the best solution.
While different folders sound like a solution too, it would probably cause problems especially for inexperienced users when debugging. it wouldn’t be as easy as just sharing your scenery.ini in a forum post anymore.
On a side note (hope this isn’t too off-topic, sorry) I really hope that the way mesh works in xplane is something that can be improved in general. You can’t really do airports with prominent terrain features because we don’t have tools for terraforming. commercial scenery developers have to outsource the mesh part to guys like maps2xplane because mesh editing in xplane is actual rocket science.
you could make a hybrid solution between (making scenery authors annotate) and making x-plane overrule bad annotations where necessary.
similar to websites having a sitemap and a robots.txt file, versus the crawlers who benefit from robots directives, and can over rule to index pages marked as no-index. ——– in a way, the author annotations are like recommendations but not mandatory.
try to make a SWOT analysis of each approach and merge the good idea streams.
Here’s my thought on it. I like the idea of separating mesh, and overlay sceneries. I also think that for 3rd party libraries, could there be a “Resources/Libraries” or something to that extent? That would also keep them from being included with airports overlays or meshes. I don’t know how much reverse engineering that’d take, but I feel that would eliminate some other issues I’ve seen before from “hard-linking” scenery libraries (hard to explain but if it’s not exactly installed a specific way it’ll not recognize the objects, etc).
I think the x-organizer way of sorting the custom scenery folders is probably the easier one without losing compatibility with all the existing addons.
So either create a similar tool integrated in XP12 GUI with an option to reload the custom scenery from within the sim or send a big check out to Matthijs and buy the tool
We regularly see user logs with 500-1000 custom scenery packs, so while I think a nice UI to organize pack priority might be nice, I don’t think it solves these problems. Telling users “go rank 1000 random items in priority order” is impractical.
Answer:
I have no problem with this!
For Europe alone, my Custom Scenery contains no less than 2475 folders: individual scenes, SimHeaven, Ortho4XP tiles and ibrairies (about 2.5 TB)
Each time I add a scene, I rename it according to a precise protocol: “Country ISO code / Scene ICAO code / Place name”.
Moreover, contrary to what Laminar wants, I destroy Scenery_packs.ini at each launch. So I rarely have any problems.
The layout of my Custom Scenery can be found here : https://www.x-plane.fr/showthread.php?t=65076&p=552308#post552308
INteresting problem.
Is there a way to make scenery have “families” in the way that modern code uses object oreinted things or classes, i.e. a defined decendency-dependency to any scenery add-on?
XP would have a pre-defined scenery set of “classes”. Authors would need to add a class definition of their scenery – whcih class it belongs to in the scenery file.
When a custom scenery gets loaded it automatical identifes missing items on which it is dependent (not just the item itself but also the version required) and then downlaods them if necessary. If a missing item needs to be bought the user is notified.
Each cusotm scenery item would require its class definition and all depedencies.
For conflicts, users can be notified of the particular conflcits and then they can choose what option they want.
This would probably be beast executed with a custom scenery pre-processor – not done when XP is started.
When a new custom scenery item is added the pre-proceesor is opend automaticaly to prepare the custom scenery data for XP use. Or the only way to add or change items in the custom scenery folder is to startup the custom scenery manager program.
I wonder if it is possible drag a scenery pack from thirdy party to the X-plane app icon, and X-plane app moves automatically/’automagically’ the scenery pack to a correct place?
G’day Folks
My perspective as a plain, simple user:
When I buy/download a scenery pack for a geographic area I expect to see that scenery in that area. Full stop.
When I buy/download a scenery pack for a particular airport I expect to see that scenery at that airport. Full stop.
If I buy/download a scenery pack I like better than one I’ve bought/downloaded previously I want to be able to simply turn off the old one and turn on the new one.
Mesh, ortho, overlay, etc mean diddly squat to me.
How about a simple GUI which gives the following options when loading scenery:
1. Default scenery
2. Custom geographic area – overrides 1 for that area
3. Custom airport – overrides 1 and 2 for that airport
4. Manual scenery – does whatever the user wants it to do; essentially the existing system. It comes with a big warning “Advanced Scenery Options: Only use this if you are sure you fully understand how it works.”
Cheers, Gobit
How many scenery packs are in your custom scenery folder?
Hi Ben
.ini below
I
1000 Version
SCENERY
SCENERY_PACK Custom Scenery/——1-Custom Airports—————————————-/
SCENERY_PACK Custom Scenery/NZWN – Wellington International/
SCENERY_PACK Custom Scenery/_NZPM – Palmerston North V1.00/
SCENERY_PACK Custom Scenery/ShortFinal – EDDM – Munich Airport/
SCENERY_PACK Custom Scenery/DD EPWA Warsaw Chopin Airport XP V2/
SCENERY_PACK Custom Scenery/PuF_Lower_Silesia_Airfields/
SCENERY_PACK Custom Scenery/NZCH_with static/
SCENERY_PACK Custom Scenery/——2-Aerosoft Airports—————————————-/
SCENERY_PACK Custom Scenery/Aerosoft – EDDF Frankfurt/
SCENERY_PACK Custom Scenery/Aerosoft – EDLP Paderborn-Lippstadt/
SCENERY_PACK Custom Scenery/Aerosoft – EGLL Heathrow/
SCENERY_PACK Custom Scenery/Aerosoft – LEBL Barcelona/
SCENERY_PACK Custom Scenery/Aerosoft – LFMN Nice Cote d Azur X/
SCENERY_PACK Custom Scenery/Aerosoft – LFPO Paris Orly/
SCENERY_PACK Custom Scenery/Aerosoft – LPFR Faro/
SCENERY_PACK Custom Scenery/Aerosoft – Static Aircrafts/
SCENERY_PACK Custom Scenery/——2a-Custom Cities and Landmarks—————————————-/
SCENERY_PACK Custom Scenery/DD Warsaw City XP Layer 1/
SCENERY_PACK Custom Scenery/DD Warsaw City XP Layer 2/
SCENERY_PACK Custom Scenery/DD Warsaw City XP Layer 3/
SCENERY_PACK Custom Scenery/Aerosoft – EDDS Stuttgart_1_Parked_Cars/
SCENERY_PACK Custom Scenery/Aerosoft – EDDS Stuttgart_2_Roads/
SCENERY_PACK Custom Scenery/Aerosoft – EDDS Stuttgart_3_Scenery/
SCENERY_PACK Custom Scenery/Wellington Airport NZ Orthophoto/
SCENERY_PACK Custom Scenery/_Wellington City NZ/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – New York/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – Washington DC/
SCENERY_PACK Custom Scenery/LOWI Demo Area/
SCENERY_PACK Custom Scenery/KSEA Demo Area/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – Dubai/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – Sydney/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – London/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – Chicago/
SCENERY_PACK Custom Scenery/X-Plane Landmarks – Las Vegas/
SCENERY_PACK Custom Scenery/Global Airports/
SCENERY_PACK Custom Scenery/——3-SFD Global—————————————-/
SCENERY_PACK Custom Scenery/SFD Global 1 Urban Textures/
SCENERY_PACK Custom Scenery/SFD Global 2 Terrain Textures/
SCENERY_PACK Custom Scenery/SFD Global Autogen/
SCENERY_PACK Custom Scenery/SFD Global Forests/
SCENERY_PACK Custom Scenery/SFD Global Landmarks/
SCENERY_PACK Custom Scenery/——4-Sim Heaven X Europe and X Australia-Oceania—————————————-/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-1-vfr/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-2-regions/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-3-extras/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-4-scenery/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-5-forests/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-6-autogen/
SCENERY_PACK Custom Scenery/simHeaven_X-Australia-Oceania-7-network/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-1-vfr+corr/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-2-regions/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-3-extras/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-4-forests/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-5-scenery/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-6-add-autogen/
SCENERY_PACK Custom Scenery/simHeaven_X-Europe-7-network/
SCENERY_PACK Custom Scenery/——5-Libraries—————————————-/
SCENERY_PACK Custom Scenery/000 Drzewiecki Design Library/
SCENERY_PACK Custom Scenery/Airport Environment HD/
SCENERY_PACK Custom Scenery/PuF_Libs/
SCENERY_PACK Custom Scenery/RE_Library/
SCENERY_PACK Custom Scenery/Windsock Real flag sync/
SCENERY_PACK Custom Scenery/The_Handy_Objects_Library/
SCENERY_PACK Custom Scenery/3D_people_library/
SCENERY_PACK Custom Scenery/CDB-Library/
SCENERY_PACK Custom Scenery/ff_library/
SCENERY_PACK Custom Scenery/MisterX_Library/
SCENERY_PACK Custom Scenery/simHeaven_Vegetation_Library/
SCENERY_PACK Custom Scenery/OpenSceneryX/
SCENERY_PACK Custom Scenery/R2_Library/
SCENERY_PACK Custom Scenery/ruscenery/
SCENERY_PACK Custom Scenery/THE-FRUIT-STAND Aircraft Library v3.0/
SCENERY_PACK Custom Scenery/world-models/
SCENERY_PACK Custom Scenery/——6-Ortho—————————————-/
SCENERY_PACK Custom Scenery/——7-Mesh etc—————————————-/
SCENERY_PACK Custom Scenery/z – ShortFinal – EDDM – Mesh/
SCENERY_PACK Custom Scenery/zzz_new_zealand_overlay/
SCENERY_PACK Custom Scenery/zzz_new_zealand/
SCENERY_PACK Custom Scenery/ZZZ DD Warsaw City XP Terrain/
Cheers, Gobit
To be honest, why change what we have? With a couple of ground rules, it really is not that hard to get the order right. For example, adding standardized prefixes to different file names/types, for me at least, always ensures my files go in the right order. Adding more complexity via different folders etc, I personally believe will just confuse people more.
I would suggest that every author includes following configuration info for the (parts of the) scenery pack:
-Type of scenery (is it a mesh, an Orthophoto, a library, an airport and/or city scenery)
-Area of significance (local, regional, global)
First of all, XP12 would assume that add-ons have a higher priority than stock and demo assets.
Secondly, any local add-ons would stack above regional and global add-ons.
Third, airports stack on top of city sceneries. Those stack over Orthophotos, meshes are the bottom layer.
That will cover most collisions. Those that remain will probably need to be resolved by the end user by simply enabling/disabling an add-on in the gui. Say you have an “Alps trees” package and a “Switzerland nature” package, the user needs to decide, there is no algorythm that can sort those out.
If a scenery is missing that information, XP12 takes a guess (geographical size, does it have a runway, does it have buildings, does it provide a mesh)
I’m not deep in the details, but I think X-Plane should automatically order things guided by some metadata provided by additional scenery.
Maybe like this:
Requires: the other scenery packs this pack requires. Maybe with a version number (at least that version)
Provides: Name and version this pack provides.
Replaces: The other pack this pack replaces.
X-Plane would arrange ordering and replacing of packs guided by such metadata defining a partial ordering.
Maybe X-Planevshould also have an “import pack” function that reads a pack and distributes the components into the corresponding folders. Compndated by a “remove pack” of course 😉
Hi
I like the idea of a “metadata” block that defines what the pack contains, how it should be displayed and what additional elements are needed for this pack.
For orthophotos and additional object packs (VFR marker for example) a separate folder would be nice and a graphical thing to activate/deactivate them would be nice.
When I start X-plane I always know which flight I am going to make and all the scenic packs on my hard drives do not need to be activated for that flight. Today I use a manager the symbolic link and X-Organizer before each flight and I choose which layer I add.
It would be nice to have a tool like that.
Good flights
Hervé
I use an automatic translator because I’m bad for English 🙂 sorry
I agree with the meta data idea that is being floated in here.
The meta data should have a field to indicate “preferred weight” that dictate where it belongs by default. However user should have ability to override and change the order if needed.
This will allow us “3rd party artifact/scenery” to ship with meta data where we (author) intended it belong in the hierarchy.
Personally, I’ve always been frustrated with the idea that the newest pack is always the highest priority. Generally, I’ve manyally managed the priority of my scenery folder not unlike how Linux decides which services to start, and in what order. Then, every time I make a change, I delete the INI file altogether… My folder looks like this:
05 KPOU Update
05 MD88
05 My Custom Stuff
05 My Gateway Airports
30 KBOS – Boston Logan International
30 KBOS – Boston Logan International Orthophotos
30 KBOS – GroundTraffic City
30 KFFA – Kittyhawk First-flight airport
30 KPHX – Phoenix Sky Harbor Intl
30 KSAN – San Diego International
30 KSFO – San Francisco Airport V2
50 Aerosoft – EBBR Brussels
50 Aerosoft – EDDF Frankfurt
50 Aerosoft – EDLP Paderborn-Lippstadt
50 Aerosoft – EGCC Manchester (Premium)
50 Aerosoft – EGLL Heathrow
50 Aerosoft – LFMN Nice Cote d Azur X
50 Aerosoft – LFPO Paris Orly
50 Aerosoft – LPFR Faro
50 Aerosoft – LSGG Genf
60 simHeaven_X-Europe-1-vfr+corr
60 simHeaven_X-Europe-2-regions
60 simHeaven_X-Europe-3-extras
60 simHeaven_X-Europe-4-forests
60 simHeaven_X-Europe-5-scenery
60 simHeaven_X-Europe-6-autogen
70 Global Airports
70 KSEA Demo Area
70 LOWI Demo Area
75 X-Plane Landmarks – Chicago
75 X-Plane Landmarks – Dubai
75 X-Plane Landmarks – Las Vegas
75 X-Plane Landmarks – London
75 X-Plane Landmarks – New York
75 X-Plane Landmarks – Sydney
75 X-Plane Landmarks – Washington DC
80 Airport Environment HD
80 MisterX HD Forests 1.01
80 MisterX Library 1.61
80 OpenSceneryX
80 RA Library
89 HDMesh_superceeded_by_NE_and_MidAtl_Ortho
89 Ortho4XP_Overlays_Arizona
89 Ortho4XP_Overlays_California
89 Ortho4XP_Overlays_Colorado
89 Ortho4XP_Overlays_Nevada
90 (Link) Ortho4XP Arizona_2017.lnk
90 (Link) Ortho4XP Nevada.lnk
90 (Link) Ortho4XP_California_v5.lnk
90 (Link) Ortho4XP_Colorado_2015_1m.lnk
90 Ortho4XP MidAtlantic
90 Ortho4XP New_England
It doesn’t address scenery packs that might have mesh and overlay together, or address the issues associated with that, but if whether you decide on 1 vs 2 folders, maybe consider this as an alternate way to enable prioritization?
I think we should basically keep the current scenery organization within one custom scenery folder and one single ini file to let the user have control about how the sceneries shall be prioritized.
This will also make sure that older sceneries like those designed for XP11 or XP10 will still be compatible to XP12. Users often have spent big money for payware scenery over the years.
But how about introducing a better way to create new custom scenery:
Today a scenery authors create one folder for mesh data, one for airport items, one for a road system as an overlay etc. – there are scenerie packs that come with more that 10 folders that a user has to organize in correct order. Often those orders are named with numbers so the user knows which folder to put first or last in the ini file.
This is horrible!
How about finding a way that allows a scenery to come within one folder – all mesh, overlay, airport and object data? To give an author control over priorities I think about something like the “always flatten feature” that comes with WED. No matter what mesh is below the airport – this feature overrules everything for the respective airport scenery. Now let us think about not just a radio button for on/off but a number feature that allows an author to add even mesh data to WED so an author can setup within the scenery how to handle which kind of data.
This would give an author full control over scenery beaviour, maintain user’s preferences about priority of sceneries and allow legacy scenery to just keep working!
I think maintaining user’s preferences about scenery priority is mandatory unless there will be any smart way to blend in/out overlapping sceneries: Think about some scenery packages that cover huge mesh/ortho areas where other nearby airports are affected, that also bring their own mesh/ortho data.
Regards,
Marc
As much as I apritiate the ability to control my settings through a editable .ini-file I´m in for simplicity for the enduser.
Could it be as easy as you at Laminar decides the mainstructure of this and then provides a small list of structured rules for authors how to name there files so that they “fall in to the right position” by themselfs at first startup of XP after installation? In that case it´s going to be some “hands on” according to addons that we have installed today (that´s not already follow these “rules”) but everything created from now on forward will be catagorized as it should by default.
“Different folders for meshes and overlays..” well, put this within the “Filename rules-list” too.
As long as installation of addons and further updating of Xplane is kept simple and not turns in to something like in MSFS2020 that demands “hands on” and reinstallation of both soft- and hardware after every update of the sim it´s fine by me.
I’d vote down suggestions that add extra burden on the user.
Two folders means the user has to understand which folder to place things.
If the average user is failing to keep a list in the right order, I think two folders wont solve that.
— “Author-Selected Rankings”
I like the idea a scenery pack has a ‘manifest’ that describes whats inside.
Ideally this would replace scenery.ini completely.
I think there could be ranked categories, that dictates display order. eg:
POI, Airport, City, Region-objects, Region-surface, (Library)
I would double these, one set prefixed with ‘User-‘ and the other ‘Default-‘ because user scenery of the same category should always be higher ranking than default scenery.
Although it’s possible to mix mesh and objects in one scenery ‘item’ – perhaps this is becoming an antipattern for user additions, and should be discouraged?
Sensible defaults:
I see the list above almost in terms of geographical size – its kinda like ‘if your AABB is smaller, you should be ranked higher’. Not great for ranking multi-POI above single-airports, but then not many POI and airports overlap, and if they did, the winner is subjective anyway.
Also, can you sniff the scenery to tell if its got mesh, and if it does then its classed in the ‘Region-surface’ layer?
Power users:
There’s going to be a small number who want to bend the rules.
My first thought was an ‘overrides.ini’ that could define a change in load order. Not sure how that’d look – maybe its a list of ‘!important’ items that are forced to be highest ranked, but thats a limited idea. All other thoughts lead to what would just be scenery.ini replicated, or complicated! So, maybe keep scenery.ini as an override of all the manifests.
Ranking within the Categories:
Once you have the categories, some people talk about the importance of order within them. I think we need a list of concrete use-cases. Is it really necessary? What does it fix?
However, I think there should be a case to _disable_ scenery. I like to think this might cover a lot of the order-with-a-category use-cases. It would be great to just move scenery out of the scenery folder – eg into ‘Custom Scenery Disabled’ and back again.
Another side-idea as an extension of the manifest idea, was to have some identification in the scenery, eg ‘author’, ‘scenery-title’, ‘version’ – (or just a plain hash for backwards compatibility) and a public site like the scenery gateway as a central registry for scenery authors.
As a scenery publisher, I register my scenery (and hash) on the site, and publish its manifest there.
X-Plane would need to get a daily update of the changes.
LR then has scope to fix manifests and load order problems.
Caveat: user has to delete any scenery.ini (with manifests I’d like to see it as an optional file).
Let’s really complicate things: How about an ‘updates’ URL in the manifest, where XP can offer to open a browser if the registry detects the users version is outdated.
I’m getting carried away…
Thanks a lot Ben for looking into the scenery organization.
It definitely is a stumbling block especially for beginners, and I suspect many fly the stock XP for a while before taking the step and reading an hour or so through the doc or watching stuff on YouTube (at least that was the case for me).
From a pure user-experience point of view, all the scenery ordering should be completely automatic and transparent to the users.
One question is probably: if somebody has essentially all the scenery that exists, would there be more or less an order that would work? If so, then indeed the ordering could be done automatically and the fiddling with the scenery_packs.ini would not be needed any more.
I quite like the idea proposed by others here that the order is purely based on the directory names. LR could specify and document some prefixes or first characters for fine-grained alphabetical/numeric categories together with the properties of each category (as suggested above). That would make it simpler for scenery authors to select the right prefix/first letter/number.
In my case I have plenty of scenery symlinked from a separate disk which is not always mounted. XP then adapts the scenery_packs.ini, but when I launch XP the next time with the mounted disk, the scnerery_packs.ini is screwed up. I had to write a script to automatically fix the ini file. It would be great if for XP12 that would not be necessary any more.
All I can say is please team up with the lovely people who make xOrganizer. Even if you don’t want to offer their functionality as standard – because a significant number of users may not need to structure lots of meshes, overlays, libraries, airports etc – their logic is superb. They understand both your (Laminar’s) hierarchy and the tendency of us users to throw all sorts at it.
I run XP11 with self-made orthos for the whole of Europe, lots of third party libraries, many gateway airports that I have updated in WED to reflect the huge amount of opportunistic re-alignment of apron layouts that has happened during the ‘down-time’ of Covid, x-Europe overlays from SimHeaven, various odd landmars and city buildings pulled off Setchup galley and more besides. xOrganiser keeps me neatly listed, and flags up my errors!
Ben – I like the idea as the way I read it, it also paves the way for (later) localized mesh patching.
I’ve shared before that from the end-user perspective, combining both mesh and overlays in one “pack” causes chaos sometimes depending on who’s pack is on top so this adds flexibility on the authoring side and simplifies on the end-user side.
I think separating those out will also make the organization of scenery “cleaner”.
I like where this is going.
I knew this subject would come up eventually, you can spend a ton hours and a thousand lines of code and you wont get what you can get for free with some simple mandates,,and that all I got ta say bout that
I
1000 Version
SCENERY
SCENERY_PACK Custom Scenery/3D_people_library/
SCENERY_PACK Custom Scenery/_Apt_Arctic_Alert-Airport/
SCENERY_PACK Custom Scenery/_Apt_Arctic_BGHD Danmarkshavn/
SCENERY_PACK Custom Scenery/_Apt_Arctic_BGIN Innarsuit-HLPN/
SCENERY_PACK Custom Scenery/_Apt_Arctic_BGKQ Kullorsuaq/
SCENERY_PACK Custom Scenery/_Apt_Arctic_BGMO Moriusaq/
SCENERY_PACK Custom Scenery/_Apt_Arctic_BGNU Nuussuaq/
[edited]
Ha ha ha well played. I did cut out about 1000 lines of your comment though so everyone else wouldn’t have to scroll past it to comment it.
Now nobody will get my point, but I hope you do
And there was only 500 lines 🙂
They certainly won’t read the post like it wasn’t meant to be.
“You have not experienced Shakespeare until you have read him in the original Klingon.”
Don’t know nothing bout Shakespeare, but after 50+ years of being a commercial captain I know the easiest way out of a jam is the simplest, and sometimes it’s the hardest to see
Again I post short version
I
1000 Version
SCENERY
SCENERY_PACK Custom Scenery/3D_people_library/
SCENERY_PACK Custom Scenery/_Apt_Arctic_Alert-Airport/
SCENERY_PACK Custom Scenery/_Apt_Caribbean_MBPV Turks&Caicos-YD_Design/
SCENERY_PACK Custom Scenery/_Apt_Caribbean_TVSV ET_Joshua_AP/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_ALTA_CYYC-CFXP-summer/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_ALTA_CYYJ CFXP/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_ALTA_zPak_HEMS_Phase_1/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_BC_CZST BetiX_A/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_BC_Machmell-Fisheries-Camp-2.0-C4XP/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_NB_CYYT St. John’s-Intl-AP-JustAsia/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_NS_CYQY Doug_McCur_AP-AirfieldCanada/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_NU_CYRT Rankin_Inlet/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_ON_CYBW/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_ON_CYYZ Toronto_AP-Pearson_v1.6-summer/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_QC_CYUL Montreal/
SCENERY_PACK Custom Scenery/_Apt_NAm_CAN_YT_CYXC Cranbrook_1.0/
SCENERY_PACK Custom Scenery/_Apt_NAm_Mexico_MMUN CanCun-FSimStudios/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_AK_19AK/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_AK_PATK Talkeetna_v1_10/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_AL_KMGM Montgomery_Reg_AP/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_CA_KTNP Twentynine Palms/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_CA_zPak_KNZY_KNRS_KNUC_KNFG Priviteer/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_CA_zPak_ZZ SoCal_Airports-Orbx/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_GA_KATL Hartsfield_Jackson_2.2_roads-NS/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_IA_KCID VS1.2/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_ME_KBHB A_Bar_Harbor-Orbx/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_MI_KTTF/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_MI_KTTF addon_roads/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_MS_KGPT Gulfport_Biloxi_Int_1.1-NAPS/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_NY_KTEBv2-summer/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_OH_KCVG Skyline_Simulations-A/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_OR_KPDX addon_Flightbeam/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_TN_KCHA Chatanooga_Lovell_Field_AP/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WA_WA56 IsraelsFarm-Orbx/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WA_WA79 WalterSuttons-Orbx/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WA_zPak_KSEA_KBFI_RNT_PAE-DD_V1.1/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WI_KGRB GreenBay/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WY_KJAC Jackson_Hole1-Axonos/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WY_KJAC Jackson_Hole2-Axonos/
SCENERY_PACK Custom Scenery/_Apt_NAm_USA_WY_KWYS Yellowstone-RE2019/
SCENERY_PACK Custom Scenery/_Apt_NPa_USA_HI_PHPA KAUAI_Port_Allen_AP_v1.0/
SCENERY_PACK Custom Scenery/_Apt_NPa_USA_HI_PHTO HAWAII_Hilo_Intl_v3.0/
SCENERY_PACK Custom Scenery/_Apt_SAm_Argentina_SAEZ Buenos_Aires/
SCENERY_PACK Custom Scenery/_Apt_SAm_Brazil_SBSV Salvador_Inter_Airport_v2.0/
SCENERY_PACK Custom Scenery/_Apt_SAm_Chile_SCSE La_Florida_AP_v1.3/
SCENERY_PACK Custom Scenery/_Apt_SAm_Chile_SCTB Tobalaba_&_Santiago_City_v1.0/
SCENERY_PACK Custom Scenery/_Apt_SAm_FrenchGuyane_SOOK Kourou_CentreSpatial/
SCENERY_PACK Custom Scenery/_Apt_SAm_FrenchGuyane_zPak_SOXX_SOOG_SOOR_SOOS/
SCENERY_PACK Custom Scenery/_Apt_World_zPak_ZZ_Global_Airports X-Plane/
SCENERY_PACK Custom Scenery/_OvlaLoc_Caribbean Puerto_Rico Ship_Docks/
SCENERY_PACK Custom Scenery/_OvlaLoc_NAm_CAN_ALTA Banff_CableWay/
SCENERY_PACK Custom Scenery/_OvlaLoc_NAm_USA_WA_KAWO ARLINGTON-B/
SCENERY_PACK Custom Scenery/_OvlaLoc_NAm_USA_WA_KAWO ARLINGTON-C/
SCENERY_PACK Custom Scenery/_OvlaLoc_NAm_USA_WA_KAWO ARLINGTON-D/
SCENERY_PACK Custom Scenery/_OvlaLoc_SAm_FrenchGuyane_SOOK Kourou_VilleEtPort/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_CA US_NoCal_TE_A_Custom-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_CA US_NoCal_TE_B_Overlay-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_CA US_SoCal_TE_A_Custom-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_CA US_SoCal_TE_B_Overlay-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_WA EXT_washington_lights/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_WA TE_A_Custom-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_WA TE_B_Overlay-Orbx/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_ZZ all-xTremeTrees/
SCENERY_PACK Custom Scenery/_OvlaReg_NAm_USA_ZZ_w2xp Ortho4XP_Overlays/
SCENERY_PACK Custom Scenery/_PhoLoc_NAm_CAN_BC_CZST_BetiX_B/
SCENERY_PACK Custom Scenery/_PhoLoc_NAm_USA_CA_KHAF Ortho/
SCENERY_PACK Custom Scenery/_PhoLoc_NAm_USA_NV_KLAS LasVegas-FlyTampa/
SCENERY_PACK Custom Scenery/_PhoLoc_NAm_USA_OH_KCVG Skyline_Simulations-B/
SCENERY_PACK Custom Scenery/_TerLoc_Caribbean_TFFJ Mesh-AWD/
SCENERY_PACK Custom Scenery/_TerLoc_Caribbean_TNCM/
SCENERY_PACK Custom Scenery/_TerLoc_NAm_USA_NC_KRDU Raleigh_Durham_Int/
SCENERY_PACK Custom Scenery/_TerLoc_NAm_USA_NV_KLAS LasVegas-FlyTampa/
SCENERY_PACK Custom Scenery/_TerLoc_SAm_Brazil_SBSV HD_1.0/
SCENERY_PACK Custom Scenery/_TerReg_NAm_USA_CA C_NoCal_TE-Orbx-summer/
SCENERY_PACK Custom Scenery/_TerReg_NAm_USA_CA C_SoCal_TE-Orbx-summer/
SCENERY_PACK Custom Scenery/_TerReg_NAm_USA_FL C_Florida_TE-Orbx-summer/
SCENERY_PACK Custom Scenery/_TerReg_NAm_USA_OR C_Oregon_TE-Orbx-summer/
SCENERY_PACK Custom Scenery/_TerReg_NAm_USA_WA Washington_TE-Orbx-summer/
SCENERY_PACK Custom Scenery/_TerReg_NPa_USA_HI Hawaii/
SCENERY_PACK Custom Scenery/AFL_LIBRARY/
SCENERY_PACK Custom Scenery/KSEA Demo-Library/
SCENERY_PACK Custom Scenery/OpenSceneryX/
SCENERY_PACK Custom Scenery/Orbx_iBY_Library/
SCENERY_PACK Custom Scenery/Orbx_OrbxlibsXP/
> So my first naive idea is to simply have two custom scenery folders
A variation of that to consider is the linux /etc/whatever.d approach: a single custom scenery folder, as today, but rather than scenery_packs.ini being a single file, it’s a directory of files in the current scenery_packs.ini format, read in numeric order. Something like so, analogous to say /etc/grub.d/*:
Custom Scenery/…all the sceneries, as today…
Custom Scenery/scenery_packs/10_airports.ini
Custom Scenery/scenery_packs/70_libraries.ini
Custom Scenery/scenery_packs/80_meshes.ini
That’s compatible with the ideas of automatic management (given a few standard files defined by LR), with user overrides (by adding a new file with appropriate numeric prefix), and simplified management by adding new sceneries to a known file rather than having to find the proper subsection of a single master file, which becomes a bit ill defined and difficult to do procedurally.
> a lot of file sniffing by X-Plane at startup
I’m all for sniffing minimization. I have an unhealthy number of ortho tiles and custom airports, so anything to improve startup time is good.
Also, thanks to the whole LR crew for all the work on XP12.