Unmerge?

dave hoeffgen

Resource contributor
#1
If something like that was already added please correct me but I'm not aware.

A feature I find necessary is for ACM to unmerge configurations that are no longer found in any active addon.
For example if an end user uninstalled an addon the autogen configurations are no longer needed.
Also as a developer I made mistakes in my configuration and had to change it. Later I saw that ACM had merged it into the main files twice which messed up everything.

My suggestion is the following approach:
There is a reset function (e.g. a button in a control panel or via command so a scenery uninstaller can call it).
The reset function overwrites the autogen files with a backup made when ACM was installed. Then the merge will be done to everything that's still there.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#2
Hi,

I have thought about this before, but I feel unmerge is quite tricky. Because if you do it wrong other addons might be broken as well. That's why currently it's not implemented.
 

dave hoeffgen

Resource contributor
#3
Of course the safety of not breaking anything should be at a higher priority. There is especially a risk if changes are made through software other than ACM, e. g. the files simply replaced by ORBX addons.
Maybe there's a way to take this into account :scratchch

Maybe it is possible to track the actual disapprearance of a configuration or entire files and remove the according entries?
 

MOUSY

Resource contributor
#4
I'm also struggling with a similar issue. My idea was to send out updates to my autogen files via an updater that ACM would then automatically merge into the users files, but now I realize that things may not get updated because of pre-existing definitions. Example: updated groupings with new models will not get updated if the name/GUID of the group already exists in the file.
It seems the file would need to be "cleaned" first, but, as Arno says, how this is done could be tricky.
Perhaps if the original autogen files could remain unchanged and we could simply add the new definitions at every runtime, and then remove them when done. That way updates to 3rd party files never cause conflicts.
But then would that would require continuous restarting of the sim?... :confused:
Perhaps I may have to try to program a cleaning tool for my definitions, although I've been trying to avoid that and stick with ACM.
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#5
Are those groupings custom for your scenery? In that case updating the autogen configuration in your local autogen folder should do the trick.

The only problem would be when another scenery with the old definitions is present, that could give conflict. So if you use the same definitions in multiple products all have to update at the same time.
 
Top