Installing custom autogen configuration

[arno]

Hi all,

The more I'm exploring autogen, the more possibilities I see. But there is a catch and that is the problem of updating the autogen configuration when distributing scenery. To make sure you don't conflict with other developers also making changes to these files some kind of merge action would have to be done upon install of the addon.

Are there any easy to use tools for that already? I would expect that the big publisher that release such addons have such tools. But are there also tools widely available to everybody?

What I have found until now is the sdk tool to turn XML into spb and the freeware/open source spb2xml tool to go the reverse way. With those tools it should be possible to turn the autogen configuration on the users system into XML, merge in your new XML elements and classes and then compile back to spb.

Is this how others do it as well? And can we even include the sdk tool to make the spb files in our installers?

Any ideas would be welcome...

 

[BASys]

Hi Arno

What I have found until now is the sdk tool to turn XML into spb
and the freeware/open source spb2xml tool to go the reverse way.

Just for info,
so ssshhhh, don't tell anyone,
the SDK tools also convert SPB to XML.

Launch the Annotator.
Open your SPB in Autogen Config Editor.
Save As XML.

HTH
ATB
Paul

 

[arno]

Hi Paul,

But using Annotator would not be so useful for an automatic install process that needs to merge the configuration would it?

Although it's good to know that is possible, never tried that myself.

 

[ibanez737]

This sounds like a very promising idea that would open the door to much better custom AGN in a wide variety of addons.

I don't believe that the tool included with the SDK can be legally re-distributed by developers... It sounds like what is needed is a "xml2spb" program to compliment the already existing "spb2xml". That way, developers could bundle these programs with their scenery installer, and use a script to run them and insert their own custom AGN entries into the user's autogendescriptions.spb file. That way, nothing would need to be done by the end-user, it would all be automated in the installation process. Sounds pretty cool to me

Cheers,
Scott

 

[JRobinson]

I wonder if it would be possible for LM to give us some relief on this while they're working on the new sim? Would it be possible for example to make the sim read and combine multiple definitions? i.e. autogendescriptions_orbx.spb, autogendescriptions_francevfr.spb, etc. all residing in the Autogen folder at the same time?

In the meantime while we're stuck with what we have, someone at VFR Network appears to be trying to come up with a solution in a utility they're calling "Global Autogen X". It's not a bad idea but it requires participation of all developers that supply custom definitions with their products, I tried it (after making a backup) and it wiped out my Orbx definitions because Orbx has apparently not jumped on the bandwagon yet.

Read more here:
http://www.vfrnetwork.com/forums/index.php?/topic/11811-installeur-de-définitions-autogen/

and here:
http://www.vfrnetwork.com/forums/in...lité-france-vfr-orbx-ftx-global-suite-et-fin/

This attempt at a global solution does come close to hitting the mark I think, but it shouldn't actually install files that are simply compiled into the installer. Individual developer's descriptions are still at the mercy of whoever compiles/supplies the installer and any updates require a re-compilation and release of an updated installer. That also requires the end user to check for/download updates periodically and if they fail to do that some things will be broken and support issues will ensue.

IMHO we should be using some kind of online repository similar to these code management programs where individual developers could upload their descriptions, keep them up to date as necessary, and take responsibility for their own definitions. A lightweight universal client side tool of some sort would access this online repository whenever an end user installs a product (and/or periodically check for updates automatically, run manually if instructed by tech support, update if triggered by an event, etc). It would gather the data from all participating users of the repository, and compile a set of up to date and all-inclusive descriptions on the fly.

Of course the decompile/append/recompile method would also work but it would still be susceptible to the descriptions being overwritten by an old existing installer and there must be on average 50 of those sitting around on backup disks for virtually every simmer on the planet. The auto-updating method above would be able to repair any damage caused but those old installers however, bringing the descriptions up to date.

Just my (likely misguided) thoughts

Jim

 

[GHD]

Earth Simulations merge the spb files.

 

[JRobinson]

Earth Simulations merge the spb files.

They do? According to the rant in the link above France VFR was all ticked off at Earth Simulations because they included F-VFR descriptions? Maybe they're not merging them but just supplying descriptions from other developers along with their own?

 

[arno]

Hi,

I doubt that all payware developers are willing to give their custom definitions to others. That sometimes also shows how they achieve certain things.

Besides that if everybody has all definitions it might also introduce problems. People can use autogen objects that they have the definitions of, but they will lack the textures and models that belong to it. That can give all kind of issues in FS.

I think it would be better to have good tool to merge and underage custom definitions. I envision a tool that would be supplied a small XML with your custom code and that would be included in the existing one (or removed again on install).

But I find it hard to believe that nothing like that exists. Are all developers now just replacing the definitions on install? That's really messy.

I thought I heard Aerosoft has something for this in their installers, but I'm not sure.

I'll do some more researching.

If one set of global definitions is what all developers want, of course I would also be willing to support that as fsdeveloper. We could indeed host some kind of repository for it, so that new additions to it can be made easily. But like I said I don't think it's the perfect solution.

 

[GHD]

According to the rant in the link above France VFR was all ticked off at Earth Simulations because they included F-VFR descriptions? Maybe they're not merging them but just supplying descriptions from other developers along with their own?

I think that was because VFR France was installed after the ES product and wiped out the ES mods.

One needs to also supply libraries accessed by AGN files.

 

[JRobinson]

I think that was because VFR France was installed after the ES product and wiped out the ES mods.

Well then ES would have been mad at France VFR, it was the other way around, lol.

 

[kevinfirth]

Yes, Earth Sims developed a utility called MergES which does indeed merge autogen files. It is included in all their sceneries and run on install to avoid their sceneries overwriting existing autogen files. They also offer it separately as a free utility for anyone else (including devs) to use, just acknowledgement required

I've used it frequently whenever I install something new.

 

[arno]

Hi,

Great, I didn't know that tool. Only problem is that it doesn't seem you can find it easily . I only found the manual:

http://earthsimulations.com/MergES.pdf

It seems you first need to download some other installer tool to get it. I'm now on the iPad so can't even try that. If such a tool is to be widely used by developers, I think it should be available more easily.

 

[kevinfirth]

I'll ask Darren if he's ok making it available through FSDeveloper

 

[arno]

I did also read on other forums that people report it has some bugs and that the merge sometimes fails. Maybe those issues have been fixed by now.

It would be interesting to know if MergES uses sbp2xml and the simpropcompiler or does it differently.

 

[kevinfirth]

ES have apparently updated their autogen definition files to include the following developers...so this looks to be the start of a set of global definitions?
https://earthsimulations.com/groups/earth-sims/forum/topic/updated-autogen-compatibility-files-now-available/

1: Earth Simulations Ltd Sceneries
2: Orbx Sceneries
3: VFR Germany
4: France VFR – FSX Sceneries
5: Justflight RevX Scenery
6: Flylogic Scenery
7: French Free Unified Scenery
8: Occitania Scenery (revision 7.0+)
9: Fly Tampa – FSX Scenery
10: 29Palms – MykonosX/SkiathosX
11: Sim720 – FSX scenery
12: 3D Automation – FSX Scenery
13: Fly Tampa – FSX products
14: Simulation Data – FSX Scenery
15: AutogenFactory – FSX Scenery

 

[kevinfirth]

I did also read on other forums that people report it has some bugs and that the merge sometimes fails. Maybe those issues have been fixed by now.

It would be interesting to know if MergES uses sbp2xml and the simpropcompiler or does it differently.

Afraid I don't know the answer to that q Seems to have worked for me in my experience though, either that or I've just not been able to notice any problems..

 

[arno]

Hi,

But I don't think the global definitions is a good idea. I think it will create confusing and trouble. When people try to use them without having the right libraries and textures there will be trouble.

A good merge tool to insert the custom definitions during install, without replacing existing file is much better in my opinion.

Or is the general opinion of all developers that we should strive for a global set?

 

[GHD]

Hi,

I doubt that all payware developers are willing to give their custom definitions to others. That sometimes also shows how they achieve certain things.

Besides that if everybody has all definitions it might also introduce problems. People can use autogen objects that they have the definitions of, but they will lack the textures and models that belong to it. That can give all kind of issues in FS.

I think it would be better to have good tool to merge and underage custom definitions. I envision a tool that would be supplied a small XML with your custom code and that would be included in the existing one (or removed again on install).

But I find it hard to believe that nothing like that exists. Are all developers now just replacing the definitions on install? That's really messy.

I thought I heard Aerosoft has something for this in their installers, but I'm not sure.

I'll do some more researching.

If one set of global definitions is what all developers want, of course I would also be willing to support that as fsdeveloper. We could indeed host some kind of repository for it, so that new additions to it can be made easily. But like I said I don't think it's the perfect solution.

Hi,

But I don't think the global definitions is a good idea. I think it will create confusing and trouble. When people try to use them without having the right libraries and textures there will be trouble.

A good merge tool to insert the custom definitions during install, without replacing existing file is much better in my opinion.

Or is the general opinion of all developers that we should strive for a global set?

Surely a merge would be the better opion. The user should have the requisite libraries for his current system, any new libraries can be supplied.

 

[Darren]

Hi Arno

It would be interesting to know if MergES uses sbp2xml and the simpropcompiler

Yes it does. I've had a look myself but couldn't see why it had stopped working. So I'm trying to get Lars ( who made it ) to have another look, but he is very busy just lately. If he can't find time I'll be happy to send you the source code, but had better see if Lars can help first though. It's in c#

Or is the general opinion of all developers that we should strive for a global set?

Definitely not! We've only made the compatibility files because MergES stopped working. MergES is a much better solution. It's described HERE if you want to see how it works ( or did work should I say )

PS: ..Like your new forum.

 

[arno]

Hi Darren,

Yes, I had found the MergES manual already. Looks like a nice tool, exactly what we need.

Let me know if I can help debugging. Would be happy to help. Much better to get this tool working again then making another one.