• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v2 Custom autogen and the default.xml - what's the latest?

Messages
1,521
Country
unitedstates
By that I mean I have some custom autogen that I would like to append to the default.xml. After researching several sites on the subject I guess I have been introduced to a long-standing issue among developers who insert custom autogen into the default.xml file... they tend to overwrite others work. One name that coame to miond is that ORBX overwrites rather than appends the file.

Is this still the case? I did a little test and noticed at first ORBX overwrote the default.xml with their own and thus deleted my autogen entries. I think I had to overwrite their file to get mine back. Why aren't devs. just appending their work to the file or am I missing something here?

So what are developers doing?

thx,

Clutch
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,883
Country
netherlands
Hi,

Good question, developers should indeed merge their new entries into the existing file. Not only for the default.xml, but also for the SPB files.

I'm planning to write a blog post about this for a while already and I also have an idea for a tool that might ease these problems, but when had time yet to write that down. Will try to do that soon.
 
Messages
7,450
Country
us-illinois
Hi Arno:

I believe it is very important that the FS development community have and use a tool such as you describe to "Merge" all installed and active autogen definitions.

This IMHO would be preferable as a possible workaround to some developers methods which arbitrarily swap out, or worse yet, simply "over-write" existing FS default and/or custom autogen definitions on the inconsiderate (...if not arrogant) premise that:

"if you want to use our scenery in FS, you will be subject to our way of arranging the entire FS world" :stirthepo

BTW: I wondered what had transpired with your intended work on the ESI "MergeES" code base, after discussions in this thread: :idea:

http://www.fsdeveloper.com/forum/threads/installing-custom-autogen-configuration.428760/


GaryGB
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,883
Country
netherlands
Hi,

It was during debugging of the ESI merge code that I realized that we need more than a simple merge tool during install, we need to be able to merge again afterwards as well, since it's easy to destroy modifications done by others.

Also during debugging I noticed that part of the problem was that two versions of the autogen configuration for one scenery were being merged. Since a merge tool can never see from the spb file which one is never, it's impossible to merge them. That make me aware that developers should always only distribute their own modifications. Any attempt to ease things by including the work of others, only complicates things in the long run.

So while doing that debugging I got a lot of these ideas and I also discussed them with Darren a bit. But then my second son was born and things got low priority for a long while.
 
Messages
1,521
Country
unitedstates
Just read the blog. Great idea to approach the issue. Right now I was planning on having one of my coders write a simple app so that during install only my agn text is injected into the default.xml. Then if it is overwritten by another developer they can just click on my app's icon to once again inject my code. Not the best but seems pretty simple. I much rather have your way for everyone but I need something for now.

Not up to speed on those SPB files? I had no interaction with them to get my agn to work. Is this something I need to worry about?
 
Messages
1,521
Country
unitedstates
Be happy to be a "guinea pig" for this as well... also again for the AI road traffic when you want to dive into that for scenPROC.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,883
Country
netherlands
The spb files are for custom roofs, vegetation and those kind of tweaking. So it sounds like you have only been customising library objects until now.
 
Messages
412
Country
ca-britishcolumbia
It might be useful if the tool you describe is able to extract any custom autogen from the autogen descriptions and put them in a separate file in case of an older or bad addon that just overwrites the file. It would then be able to merge it back in properly with all the other separate files, and can handle installing multiple addons that just overwrite the file as long as the tool is run once between each install.

How many addons replace the existing groupings with their own version? If multiple addons do that you might have a hard time merging them. I guess you could look at the scenery order and merge them in that order if this situation occurred.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,883
Country
netherlands
I see what you mean about the reverse way to extract custom definitions. But I was planning on focus a way to let developers merge nicely, not necessary on a way to fix bad approaches.

If such a tool would merge correctly at startup, we don't even have to fix addons that just overwrite, since they do no harm anymore.
 
Messages
203
Country
unitedkingdom
Hi Arno, is there any news on an autogen merge app at all pls? Family permitting of course... K
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,883
Country
netherlands
Hi,

It's one of the things I plan to work on (soon), but time is still a bit limited, so it usually takes longer than I would like.
 
Top