One of the changes to X-Plane 10.10: custom scenery packs now are tracked in an .ini text file called “scenery_packs.ini” that sits in the custom scenery folder.  This blog post explains how the .ini file works and what problems it was trying to solve.

The Old Days

Long ago, in X-Plane 10.05r1 (and every version before it dating back to X-Plane 8) X-Plane would load custom scenery packs in alphabetical order from a folder called “Custom Scenery”.  This simple convention was a work-around for not being able to “manage” scenery pack load order.

In the old days, you could change priority of a pack by renaming it and disable it by moving it to a different folder.  I have a number of packs called a_Some_Overlay and z_Base_Mesh and I’m sure others do too; I also have a folder called Custom Scenery (Disabled) that I dump stuff into.

Unhappy Installers

The problem with the old way is that users have to manage scenery packs by renaming and moving them.  If an installer has installed a pack, it won’t be able to find what it installed again.  We started to see this with X-Plane reinstalling the Aerosoft custom scenery packs that come with the global edition of X-Plane; users would delete or reprioritize the pack and our installer would not be able to update the pack because it had moved.

scenery_packs.ini: Explicit Priorities

scenery_packs.ini simply contains a list of scenery packs to load in priority order: top of the file is highest priority.  Listing the pack as SCENERY_PACK_DISABLED disables loading entirely.

This means that a user or third party utility can now organize and prioritize scenery without having to rename files.  Installers will still be able to find their installations and packs can have their “factory” names.

How Does scenery_packs.ini Get Updated?

What happens if the file system and scenery_packs.ini are out of sync?  Here are the rules:

  1. Any scenery pack listed in scenery_packs.ini but not present is removed from the .ini file on load.
  2. All scenery packs present in Custom Scenery but not in the .ini file are added to the top of the .ini file in alphabetical order.

Note that this means that your new packs are installed in alphabetical order relative to each other, but they are installed with higher priority than any existing packs.

We can’t easily install new packs in alphabetical order compared to all packs because all packs may not be in alphabetical order if the packs have been reorganized.

Ways to Reorganize Scenery

There are a few work-flows I can think of to easily re-prioritize scenery:

  1. Edit the .ini file.  It’s just a list of files, and can be reordered as desired.
  2. Remove some packs, run x-plane, quit, and add them back.  Those packs will go to the top of the list.
  3. Delete the .ini file.  The entire file will be rebuilt in alphabetical order.

The Future

Someday I do hope we’ll have a UI to organize scenery, but we don’t have one yet and won’t have one for 10.10.  My thinking is that it’s still an improvement to not have to gum up scenery packs with prefixes to control their load order.  But this does cause some work-flow changes.  (If you want to continue to use alphabetics, simply delete the .ini file after editing.)

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

23 comments on “scenery_packs.ini: What Was I Thinking?

  1. Now that I understand this file, I find it a really good idea. Of course a UI would make it complete.
    Could this be done with aircraft as well? What about a hangar program, which would manage aircraft, scenery and plugins?

    Love it …

    Jochen

    1. And yes, put all the config files under Preferences and build a version control UI around … 😉

      1. Lol, you got a few immortal planes in X-Plane that are kinda crap, that keep coming back no matter how many times you delete them.

      2. Ben,

        it’s not only about managing priorities, but as well about activating/de-activating without moving directories around this would make sense for aircraft and plugins as well.

        Jochen

    2. Now that I understand this file I realize this solves a minor problem by creating other problems. I am going to have to think about it a lot more but so far it has made scenery management more of a chore.

      You have a choice of letting it do its stuff and manage the list or trash the ini after every installation of scenery (and woe if you forget) and manage the names. There is no mixing of methods. If you do the former, the load order becomes more haphazard in time — yes, there’s always the Finder for certain tasks. The more ordered by installation date it becomes, the more difficult it becomes to manage new order-dependent scenery. Conversely, the more the list is customized the bigger the hurdle if you ever resort by name. There’s the hd mesh to deal with, osm scenery, custom mesh, the airport itself, towns and other landmarks, if any….

      There are lots of plusses and minuses in either method. You can put a U.I. on it but what it will eventually demand is a full blown scenery management app able to deal with rules of dependency — or a new paradigm in XP scenery management — either of which is neither a desirable nor intended outcome at this moment. We’ll know in time.

  2. Would it be possible to make this an in-sim option (like: “start on ramp”)? Becasue I not only rename because of the priority loading, but also in order to keep track of the hundreds to thousand of folders of my harddrive (1831 folders). As far as I see it at the moment, from now on it will be: “remember deleting this file!” when I do anything to the scenery folder… Or I need to manage my scenery folders and the file. In any case it is one step more to remember.

    Example: “zzz_Treelines_Farms_USA” by Andras. How would that work in the future? Just copying will never be enough now.

    And so I’d like to disable it until there is a GUI for it that makes sense and replaces the need to manage the folders themselves.

  3. What is the syntax to use for scenery packs outside the x-plane folder ?
    I tried to put a full path in Windows but X-Plane removed it at startup.

  4. Yes it would be great if you could do this for plugins that way you could choose between plugins such as GIZMO and sasl that don’t like each other

  5. Not sure if I like the .ini idea. When I changed to X-Plane, I was happy that installing and prioritizing scenery was done so easily compared to the need in MSFS to use the builtin scenery manager to move packages up and down. The Aerosoft problem (scenery being reinstalled each time after rename) I solved simply by not renaming the Aerosoft scenery …

    I will probably write a batch file that deletes the .ini file everytime before it starts X-Plane and put a shortcut to this batch file on my Desktop …

  6. Thanks for the info Ben. I’ve been doing a lot of work on XAddonManager lately, so I’ll also incorporate scenery pack ordering for the next release. I think XAddonManager should switch to disabling packages via the .ini file too, rather than moving them to a different folder (causing the re-download issue you mentioned).

  7. Ben, the idea of a simple file is fine, but I see one problem to you approach: Scenery makers can’t suggest a default priority any more. By default, a new scenery will be added at the top of the list. This requires manual editing of the file by the user for each “low priority” scenery (eg. photo scenery that shouldn’t cover other object sceneries).
    My idea would be to add a “priority” parameter in the file, after the folder’s name. A single digit (eg. 0-9) would be enough. On top of that, allow the scenery makers to add a file in their folder which contains the “preferred” priority parameter. When X-plane loads new scenery, it adds the scenery at the top like now, with a medium priority (eg. 4) by default, or the number found inside the scenery folder if it exists. Now, X-plane just have to load first all files marked with “0” priority in alphabetical order, then 1, etc…
    This way, no manual editing would be required from the users, and scenery makers don’t have the hassle to explain how to edit the ini file in their readme.

    1. Yeah that’s what I was thinking too – some way to hint that ‘this is a base mesh, put it near the bottom’ vs ‘this is overlay, keep me on top’.

  8. Sorry, my mistake, this is correct:

    “Now, X-plane just have to load first all files marked with “0″ priority from top to bottom , then 1, etc…”

  9. Rather than asking newer or inexperienced X-Plane users to venture into the game’s file structures and delete a file (*where they could blow out a lot more than just the .ini), perhaps a button somewhere in-sim which will delete the .ini file and restart the simulation on the fly?

    A quick “Scenery Management” menu item off the top can initially contain this “Reset Ini File” button, and in the future perhaps contain the proper UI for manipulating scenery pack priorities.

    Granted, if a user is adding scenery they are probably comfortable with going into the file systems, but it could make tech support requests a bit easier.

    The new .ini file also opens the doors to a resourceful freeware developer to whip up a quick little external utility to manage the file for you, too.

  10. This file looks nice. Is it now also possible to place sceneries outside of the Custom Scenery folder?
    Maybe an entries like this
    SCENERY_PACK AerosoftScenery/EDDM/
    Would be inside the X-Plane root or better somewhere else
    C:\Users/myUser/mySceneries/EDDM/

  11. Aussi’ XplaneManager is oh so easy. But sounds like Aussi is working to
    integrate his manager with the new scheme. That’s good as I rely on his
    manager a lot to keep me out of wrong scenery troubles, unlike another flight
    sim that I had lo so long ago and is now gathering dust.

    Chuck

    1. Yeah Aussie does good work. 🙂 This change is friendly to third party managers in that it lets them “manage” by data and not by taking a whack at the file system.

      1. Cheers guys, I’m glad it’s useful 🙂 I’m just working out an elegant way of migrating existing scenery packs from the old ‘(disabled)’ folder to the new ini file method. Then will take a look at building a nice UI for ordering. There are some other big new features coming in the next version too.

Comments are closed.