Merging autogen configurations

Now that I can use scenProc to easily create new autogen, the urge to add custom autogen models increases as well. To make the autogen even more realistic I want to add custom roofs, custom vegetation models, etcetera. But all these modifications to the autogen configuration files give developers some headache when trying to deploy their scenery. How to make sure that the end user gets these modifications as well?

The problem is that there is one autogen configuration that all developers modify. So if not done correctly a developer might wipe out the modifications done by another developer. There are a few approaches that are used nowadays:

  1. Some developers just copy their modifications over the existing files, whiping out previous modifications
  2. Some developers merge their modifications into the autogen configurations files
  3. Some developers merge their modifications and the modifications of sceneries often used together with their product into the autogen configuration files

Obviously one approach 2 is the right way! Approach 1 is bad because it just erases any modification done by other developers. Your scenery will work fine, but others will stop working. Approach 3 might sound like a nice service to the end user, but what happens if the other scenery you include the modifications from update their custom autogen configuration? In that case your product would still include the old one and in that case the order of install will determine the result the end user gets. That’s not good.

So I would say the only way developers should distribute their custom autogen configurations is to only distribute their own modifications (not the default MS configurations, not those of other developers). And developers should properly merge their configurations into the main configuration file.

But of course we will have the issue of developers who don’t play it nice and remove other developers modifications, how do we deal with that? It would be annoying that end users have to reinstall your scenery again just to restore the autogen configuration files.

So I would propose that we make a tool that mimics the behaviour the Microsoft should have added out of the box already. A tool that allows each scenery to have their own local autogen configuration files. Each developer will put his own modifications in a folder within his scenery and the tool will scan all these custom autogen configurations at startup of FS and merge them into one main autogen configuration file. And if this is done at each startup of the sim, developers who wipe out your configurations don’t do any hurt anymore.

I plan to try to create such a tool soon. But I would love to hear back from other developers if this sounds like a good approach. Do you have other use cases in mind that such a tool should cover? Or would you like to help me develop and test this tool? Just let me know!

7 thoughts on “Merging autogen configurations

  1. Kevin Firth says:

    Sounds like an excellent idea Arno, happy to help test it when it’s in development.. K

  2. Bill Womack says:

    Ideally, autogen configurations would have been stored in a structure similar to scenery and textures, with local versions simply taking precedence over those down the tree. Since they didn’t seem to think we’d need this functionality, keeping local configurations that are merged at runtime is probably the best option.

  3. Ian Wright says:

    Arno – spot on. ES had done something along these lines hadn’t they? I thought you had some conversations with them…
    I’d follow any standard you come up with for my own products and also be very glad to help put it together and, in particular, test as required.


    • arno says:

      Yes, I have been trying to debug their merge tool. Based on that work I came to the conclusion that the problem is not only the tool, but more how developers try to merge the data. Such a merge tool can newer known which data is newer, if both sets contain the same GUID, but with different content.

      So that’s why I feel that we should go one step higher and make sure developers only distribute and merge their own stuff. And that can hopefully be made easier by having a tool that merges automatically at startup.

      But just ideas at the moment…

  4. Kevin Firth says:

    Arno, I’ve been looking at trying to do customised extrusion bridges and similat issues obviously affect materials.spb and extrusions.spd (although to a leaser extent I think as fewer people try to mod these?)

    Perhaps you could in future incorporate merge routines for these as well? I can imagine a plethora of easily sharable extrusion effects….

    Cheers K

  5. Scott Armstrong says:

    Sounds like a fantastic idea to me Arno. Like you said, I wish that Microsoft had included this functionality out of the box, but your proposal sounds like the next best option indeed :). You create the tool and set the standard, and developers will follow!

  6. Barry Friedman says:

    Something like that would be great for airports that install custom altitude changes or other changes that have to be placed in the global scenery folders. If the airport could just have it in the local scenery folder and a tool like this just moves the file to the right place when FSX start up.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.