• 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.

One last test please

Status
Not open for further replies.

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi all,

After the release candidate I posted a while ago, I now have a version of Autogen Configuration Merger that is ready for non-beta release. But I would like to ask a few of you to perform a last test. So could you try the attached version and check if it works with your scenery?

I have also attached the latest user and developer documentation.

Thanks and once I get some feedback that you have tested it, I will do a release soon.
 
Hoping to try this out this weekend (may turn out a week or so), but I read the manual and I have a question that I did not see any reference to in the manual:

1. One can name their autogen folder (and file) anything they desire so long as the file is an .xml file and is in their main scenery folder? For example, my add-on might have this as a directory:

Airport X
Scenery
Texture
Autogen
my airport agn.xml
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Nope, the names need to match the name of the global agn configuration file they need to be merged into.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Anybody tested this release candidate already?

Since this tool not only goes to developers, but also to end users I prefer it's tested well before I release it.
 
Sorry Arno, am in the middle of moving house halfway across the country - all possessions boxed up and ready to go, so my sim gear is packed up sorry :(
 
Plan to test it tomorrow Arno... can't today what with work. You've been great so good creating this for us it's the least I can do. I'll give you a pure "layman's" impression since I haven't tried it yet and I need to.
 
I had really wanted to test this, but am still over-commited with other existing projects and the intermittent and immediate learning curve(s) those commitments require of me ...for the near future. :oops:

But, I would like to know, however, if the original impetus to this (as a result of the inquiry by Darren Vincent of Earth Simulations Inc. (aka "ESI") when Lars Hoyer's code 'wasn't working' for a while) ...has resulted in a way to easily incorporate the multiple ESI autogen definitions for the scenery location packages such as Alderney, Channel Islands etc. and the TreeScapes product line ...via Arno's Autogen Configuration Merger ? :scratchch


Thanks for any clarification of the current feature set and capability regarding the above specific products from ESI. :)

GaryGB
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi Gary,

This tool was indeed born out of trying to help Darren with a problem in his ESI Merge tool. While looking into that issue I found out that part of the trouble there was that the different files being merged contained different versions of the same definition. That's something no merge tool can handle well, as the merge order then starts to play a role.

So the approach of this tool is to only define the definitions that a scenery needs and store them locally with the scenery. The tool will then merge them into the global autogen configuration at startup.

I know some people tested this with definitions orignally not made for Autogen Configration Merger and it seems to work. But the desired approach is that the developer of the scenery prepares the definitions, not that end users have to fiddle with it themselves.

It might work for the ESI products you mentioned, but since I don't have them I never tested it. And I haven't heard other did. But the Autogen Configuration Merger tool is also compatible with sceneries that don't use it and merge into the global definitions themselves.
 
Thanks, Arno; when I get some free time, I'll test how a current build of Autogen Configration Merger works with merging ESI definitions, and will share my results here. :)

GaryGB
 
Thanks, Arno; when I get some free time, I'll test how a current build of Autogen Configration Merger works with merging ESI definitions, and will share my results here. :)

GaryGB
Gary, I tested ACM with the most recent set of ES autogen files and apart from the one error it generated which I reported to Arno, (and was subsequently fixed I believe?), it seemed to work successfully :)

I have just tested again by adding a few historic backups of autogen files and ACM appears to have merged them successfully :D Cheers K

EDIT: for some reason it appears that I'm now getting the message saying autogen files have been merged every time the sim runs, regardless of whether I added anything new or not.
 
Last edited:
Hi Kevin:

Thanks for that encouraging report ! :D

I shall look forward to seeing if any final un-resolved issues with the ESI AGN definitions merge process are successfully addressed by Arno. :scratchch

Many thanks to Arno for all his work with this project ! :wizard:

GaryGB
 
Ok, I wanted to report back what I am seeing (and not seeing). I do not have an installer for my scenery yet so I am doing this step-by-step following the manual. I am testing this against P3Dv3's default.xml file to see if my files will merge.

1. I used the command prompt to install as instructed. In the install window I selected P3Dv3 and attempted to use the browse button to install my path for ACM location. Would not work. I had to manually type in the path. Installed fine after that. Can see my EXE.XML file has been updated.

2. Created a custom default.xml file and created a custom 'autogen' folder in my own custom scenery folder as instructed. So I have scenery, texture and autogen folders.

3. Scenery is active.

4. Instructions say:
"The first time you run Flight Simulator after installing you will be asked if you
want to run the tool at startup. Confirm this and it is advised to add the tool
as trusted as well."


This does not happen. P3D loads and the flight starts but no message and no merge. This is as far as I have got. :scratchch
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Kevin,

Let me check, you shouldn't get the notice every time. The only condition I can think about is that you have some definitions that appear in multiple files so that it is changed every time.

Clutch,

What's in your exe.xml file? Does it contain the right path to the tool?
 
Kevin,

Let me check, you shouldn't get the notice every time. The only condition I can think about is that you have some definitions that appear in multiple files so that it is changed every time.

Clutch,

What's in your exe.xml file? Does it contain the right path to the tool?
That may be the case, I quickly tried to merge several old backups of autogen config files due to time constraints and its almost certain some definitions were duplicated.

Maybe I was wrong assuming ACM would cope with that? To ensure all definitions across multiple file versions are merged correctly, would I be better adding each set sequentially, merging it in and then deleting it? I've tried to avoid having to decompile the ES spd files to delete unnecessary entries due to time and relative ease :p

The reason I opted to go with multiple sets containing a lot of duplicate entries was that the last set of autogen files produced by ES:
1) have I think an error relating to some models in Shawbury Fields, leading to non-display of the control tower..I thought the merge of historic versions with the newest version may correct this?
2) are superceded by latest OrbX definitions, which require to be merged for seamless operation..
 
For my exe.xml file, it is pretty simple and straight forward. Double checked how ACM installed and the path checks out ok:

<?xml version="1.0" encoding="windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
<Descr>Launch</Descr>
<Filename>exe.xml</Filename>
<Disabled>False</Disabled>
<Launch.ManualLoad>False</Launch.ManualLoad>
<Launch.Addon>
<Name>Couatl</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>fsdreamteam\couatl\couatl.exe</Path>
</Launch.Addon>
<Launch.Addon>
<Name>SPAD</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>C:\Flightsim Programs\SPAD\Spad.exe</Path>
<CommandLine>-run</CommandLine>
</Launch.Addon>
<Launch.Addon>
<Name>SPAD</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>C:\Flightsim Programs\SPAD\PanelsIO.exe</Path>
<CommandLine>-run</CommandLine>
</Launch.Addon>
<Launch.Addon>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Name>GoFlight Hardware Interface</Name>
<Path>C:\Flightsim Programs\GoFlight\GFDevP3D.exe</Path>
<CommandLine>
</CommandLine>
</Launch.Addon>
<Launch.Addon>
<Disabled>False</Disabled>
<Name>GoFlight P3D Data Bridge</Name>
<ManualLoad>False</ManualLoad>
<Path>C:\Flightsim Programs\GoFlight\GFDevP3D.exe</Path>
<CommandLine />
</Launch.Addon>
<Launch.Addon>
<Name>AutogenConfigurationMerger</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>C:\Flightsim Design Toolbox\Autogen Configuration Merger\AutogenConfigurationMerger.exe</Path>
</Launch.Addon>
</SimBase.Document>

As for getting the message, it just sounded like I would get it the first time, which I did not. I did not expect to get the message every time P3D loaded.

Now your comment about multiple definitions... well that could have some bearing on the issue but I will let you tell me. I am taking some library objects and some autogen objects and creating my own custom agn groupings from these. So yes, some individual items do have the same name and the same GUID. But they are grouped in their own unique class GUID and a unique class name. For example:

<?xml version="1.0" encoding="utf-16"?>
<AUTOGEN>
<REGION>
<CODE>B</CODE>
<CLASS>
<NAME>SWS factory</NAME>
<GUID>75D4269442c625D7C48BA09B78889C7B</GUID>
<WIDTH>0</WIDTH>
<DEPTH>0</DEPTH>
<LIBRARYOBJECT>
<NAME>ag_usfactory02</NAME>
<GUID>b9dc3ae141495c5f102bd8952cceac1a</GUID>
</LIBRARYOBJECT>
<LIBRARYOBJECT>
<NAME>agn_industcompbuildingsl_1</NAME>
<GUID>5ede86504203bbf1d74cf28f6687831b</GUID>
</LIBRARYOBJECT>
</CLASS>
</REGION>
</AUTOGEN>

You can see the two listings are taken from the default autogen but I have wrapped them up in a new custom class 'SWS factory', for my use. Could this be the issue?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
No, as long as the class guid is unique it doesn't matter if objects are used in multiple ones.

Could it be you have classes being defined in multiple xml files with the same guid? In that case it could be they are always seen as modified.
 
I'll double-check. Let me ask. Say I have 10 custom classes I have added but one of them, by accident, is a duplicate, would ACM still update nine of them or would that cause a fault where none of them would update?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
It would update all of them. But if you have two sceneries that define the same class it might trigger an autogen definitions have changed at every startup.
 
It would update all of them. But if you have two sceneries that define the same class it might trigger an autogen definitions have changed at every startup.
That is exactly the situation I have experienced. I presume this can be countered simply by removing one of the offending duplicate set of files after the first merge...?
 
Status
Not open for further replies.
Top