How to start Autogen Configuration Merger?

[arno]

Hi all,

I am wondering how to start the Autogen Configuration Merger tool. Initially I planned to add the tool to the exe.xml file, so that it starts automatically when FS is starting. That seemed to work fine, until I started to test with bigger configurations to merge. Then I noticed that merging takes to long and that FS has already loaded the old configurations before my tool finished. So this doesn't really work.

But what would be the best way to have the tool start? I have some ideas, but I would like to know from other developers what would work best with their scenery.

• Don't run it every time FS starts, but give the user the choice to manually run it
• Run the merge tool first, which will start FS afterwards
• Still run it automatically from exe.xml and accept that you might have to restart FS/reload the scenery in some cases to see the autogen right

 

[GaryGB]

Due to increasing concerns in the MSFS end user community over optimizing MSFS launch and load duration, run time performance, USERVA utilization by add-on content, OOMs etc., various procedures using batch files and/or 3rd party utilities are being implemented to pre-configure FS and its various files before it is launched.

Because it may be challenging to insert a launch of Autogen Configuration Merger Tool (aka "ACMT" ?) into various and constantly changing sequences of operations and directly-loaded saved flights etc. which some end users may run before FS itself is launched, IIUC, it may be necessary for ACMT to perform its task before FS is even running in memory.

I assume some check could be run to see if MSFS is running in memory before ACMT attempts to perform its tasks, and if MSFS is already running, a message could advise the ACMT user that they must exit MSFS before ACMT can complete its tasks.

IIUC, ACMT would next check the active user Scenery.Cfg file and utilize only the "custom" Autogen Descriptions info for layers which are set "active" within Scenery.Cfg (...to help minimize as much as possible, system resource use, MSFS load time etc.).

AFAIK, this method of starting ACMT would require end users to do so manually ...when MSFS is not running in memory.

I suppose this could also be done with ACMT running from exe.xml, so that it can be allowed / denied quickly when desired ...at the 'run permission' prompt dialog during MSFS start-up.

That way end users who want to enable / disable ACMT operation without the 'run permission' prompt dialog during MSFS start-up, can do so by manually editing exe.xml.

And when allowed to run via the 'run permission' prompt dialog during MSFS start-up, ACMT would exit FS and run its tasks before 'allowing' MSFS to re-load.

GaryGB

 

[arno]

Hi Gary,

Thanks for the input. Yes, I'm reading the scenery.cfg already and only processing active areas that contain custom autogen definitions.

Running the tool before FS sounds like a good idea, but it would require that the user runs it manually. To make sure the autogen configuration stays OK, I would prefer to run it automatically, that way a wrongly installed addon or so can't affect other addons anymore. But it might indeed be challenging to get it running automatically before FS loads the autogen configurations.

That's why I started this thread and would love to hear from other developers what they think would work best for their end users.

 

[GaryGB]

That's why I started this thread and would love to hear from other developers what they think would work best for their end users.

FYI: I accidentally 'stumbled across' this new sub-forum as I was scanning for new threads 1 step higher in the forum list.


I believe it would be a beneficial service to the FSDeveloper community and the feedback process for ACMT, to post a thread in:

Home Forums > Developers coffee house > General chat

...to announce that this new sub-forum is now open, and that feedback is welcomed for this (potentially revolutionary !) utility.

Oh, and I'd make that announcement "not open for replies" in that thread as a 'pro-active intervention'; IMHO some of those who frequent that forum need motivation to get back on focus with "hands-on" activities of FS development, and this might just help motivate them to get more involved again ...with something as new and full of potential as ACMT.

And posting a few "teaser screenies" or a short "teaser video" in this new ACMT sub-forum might stimulate more awareness and elicit more input as well.


Thanks again for making this available to the FS Development Community.

GaryGB

 

[arno]

Hi Gary,

Thanks for the tips, I should probably post in the autogen forum as well.

The teaser would be a bit boring, it's just a black command prompt window that flashes for 1 second or so at FS startup. No GUI or anything else (yet).

 

[Clutch Cargo]

Just discovered this new forum. Very interested in this as I will have some scenery with a few custom autogen items. I too would think the less the end-user needs to worry about or checking or starting concerning this tool the better. Hopefully it can do its thing and run silently in the background... inserting-checking-fixing. Don't have enough experience to really make any additional comments at this time.

 

[stonelance]

Super awesome to see this. Were you able to make use of my library?

Does your tool run in the background the entire time FS is running? What happens if the user changes the set of enabled sceneries while FS is running, or changes the ordering of the sceneries? I'm not familiar with whether that requires a restart of FS normally or not.

You could require that the user or other launcher program runs your tool first before running FS, but then still have your tool auto launch during FS startup and instead of doing the merging, just check if a merge has already been done and prompt the user with a warning saying that it wasn't run and some autogen may be incorrect.

Is there any way to slow down the startup of FS enough to allow your tool to finish before the startup is far enough along?

 

[arno]

Yes, your library is used and very helpful. Else I would had to make much more code to handle the spb files.

At the moment the tool runs at startup and then finishes (only takes a second or so). Good point about activating another scenery layer, but since it seems the autogen configuration is only loaded at startup that would require a restart anyway (even if the tool was still running). Layer priorities don't matter when merging I think, that would only matter if there are conflicting definitions.

I haven't found a way yet to delay loading fs. It might be easier to let the user run the merge tool and have the tool start FS afterwards.

 

[stonelance]

I can think of a couple ways to do it automatically, but they aren't pretty, and would probably depend on the program\version it is running on. The autogen descriptions are loaded during autogen init, which happens as part of terrain init. Terrain init is one of the last modules to start up, so you could potentially detour terrain.dll or one of the other dlls that is loaded earlier, and run your process from there and block until it is finished, or alternatively just embed your code in the detoured dll. In order to be compatible with the most versions you may want to pick one that exists in all FS\P3D\Steam FSX and is not modified. demo.dll maybe? Could also do it for an OS dll as well.

A couple other dirty possibilities:

Your tool could inject a thread into the FS process and that thread can block or pause the main thread from running until the merge is finished (I have a feeling this is possible, but not 100% sure how). My Flight tools do something similar for Flight integration.

Your tool could post a bunch of win32 messages to the FS process message queue. This may not work if FS doesn't process the message queue until after init.

 

[arno]

Thanks, some interesting idea there and some useful inside information.

At the moment my tool is just an EXE, so I would have to dive a bit into this DLL stuff, not something I have considered doing before.

 

[GaryGB]

Instant Scenery seems able to control and delay the "refresh" or re-initialization of a flight in progress when it starts, as it always checks the active Scenery.Cfg and updates its internal scenery library object list when first launched in each FS task session.

Amazingly, Instant Scenery seems able to do this with both FSX and FS9 (which I previously thought was impossible, as FS9 otherwise always requires one to exit and re-start a flight) ...to update a external database with info gleaned from analysis of added / removed / activated / de-activated scenery library Area layers in Scenery.Cfg.

Possibly a study of how this is being done might yield some additional ideas ?

GaryGB

 

[arno]

Yes, but the author of instant scenery knows a lot about how to integrate with FS. That's not so common knowledge. I'll see what I can do, it's not something I have looked into before.

 

[stonelance]

Not familiar with Instant Scenery, but I'm guessing the easiest way to add and remove objects at runtime is to just interface with the OPT\Mission system for placing objects, and then write out the objects into OBX xml after you save. This is one thing we did in Flight scenery tools.

Does Instant Scenery also allow adding new scenery bgls while FSX is running? Could be possible by forcing a fe_reset or changing the scenery ordering, but not sure.

 

[arno]

I have done some thinking and I think I'll go for the exe.xml approach and just show a message when changes have been made to warn the user he needs to restart. That should not happen often, only when some addon by accident removed some entries.

 

[GaryGB]

Not familiar with Instant Scenery, but I'm guessing the easiest way to add and remove objects at runtime is to just interface with the OPT\Mission system for placing objects, and then write out the objects into OBX xml after you save. This is one thing we did in Flight scenery tools.

Does Instant Scenery also allow adding new scenery bgls while FSX is running? Could be possible by forcing a fe_reset or changing the scenery ordering, but not sure.

FYI: IIRC, the Instant Scenery fully-functional demo works within 50 Miles of Seattle

http://www.flight1.com/products.asp?product=iscen3


Hope this might prove interesting !

GaryGB

 

[GaryGB]

I have done some thinking and I think I'll go for the exe.xml approach and just show a message when changes have been made to warn the user he needs to restart. That should not happen often, only when some addon by accident removed some entries.

That certainly seems practical.


IIRC, to date, there are no 3rd party add-on "scenery configurators" (other than Instant Scenery) which work without essentially forcing a re-start of FS.

And it may even be that Instant Scenery is simply saving the last shown FS screen as a background image for the task it is performing as it exits and re-scans / re-indexes content in active layers of Scenery.Cfg, then re-initializes the saved FS flight scenario via a 'direct load' of MSFS from a internally-generated *.FLT file (without showing the FS menu GUI).

GaryGB