In my testing i have found that even disabling entries in the tool (all of them in my large collection), still results in an added 1min24sec load time.. if remove those folders from my docs, i save the time..

That said.. i'm wanting to test moving all these into scenery.cfg (and test disabled here and the load times)..  the tool seems to support moving entries, but only one at a time.. is there some way of a mass move, or maybe in a future revision (or maybe via command line in general)?

 

Thanks in advance

Hi,

on the backup tab, there is the feature to create a temporary scenery.cfg that contains everything from the library, including the XMLs. Create that file, and while keeping the tool open make a copy of it. If you close the window, the scenery.cfg reverts back to the original. P4AO has a command line option for that too.

In your case I suggest that you run the P3D content error log too. If P3D has to process a lot of scenery errors, that takes time. And I trust that you went through non-scenery content as well - large collections of aircraft will degarde loading times even further.

Best regards

1 hour ago, Lorby_SI said:

Hi,

on the backup tab, there is the feature to create a temporary scenery.cfg that contains everything from the library, including the XMLs. Create that file, and while keeping the tool open make a copy of it. If you close the window, the scenery.cfg reverts back to the original. P4AO has a command line option for that too.

In your case I suggest that you run the P3D content error log too. If P3D has to process a lot of scenery errors, that takes time. And I trust that you went through non-scenery content as well - large collections of aircraft will degarde loading times even further.

Best regards

Thanks.. this worked well.. 

Results were interesting.. 3min29sec with all entries in scenery.cfg while with add-on.xmls (full enabled) it was 6min45sec..

Pretty sure i had gone through and tried to correct some of the scenery errors.. or at least i took out those entries that caused them and there was no change on load times.  I just think the parsing of the addon xml's slows it down in a large way, unsure.

The backup area export that did this export.. i guess it doesnt handle the "other addons" portions of all this.. ie: sound, texture, effects?

I suppose if i end up using scenery.cfg ill need to create at least one add-on.xml entry for those (which i'll merge into one set of folders, rather than keeping them per scenery like i think i have most right now).

 

 

32 minutes ago, theskyisthelimit said:

The backup area export that did this export.. i guess it doesnt handle the "other addons" portions of all this.. ie: sound, texture, effects?

These types of content are not part of the scenery.cfg, so no, it doesn't. You could add those paths to the proper .cfg file in ProgramData though, if there aren't too many of them.

If you are convinced that loading times are drastically longer with external XMLs, maybe you should let LM know in the Prepar3D forum.

Edit: are you always starting P3D twice in every scenario? The first time always seems to take longer to start than all subsequent attempts.

Best regards 

25 minutes ago, Lorby_SI said:

These types of content are not part of the scenery.cfg, so no, it doesn't. You could add those paths to the proper .cfg file in ProgramData though, if there aren't too many of them.

If you are convinced that loading times are drastically longer with external XMLs, maybe you should let LM know in the Prepar3D forum.

Edit: are you always starting P3D twice in every scenario? The first time always seems to take longer to start than all subsequent attempts.

Best regards 

Ah ok, ill look into that (if necessary)..

I put a thread up on their forums to see if anyone has any thoughts on the load time difference (of about 3min20sec).

Yeah each time i was testing (the default f22 loadup), i'd run it twice.. (empty cache on exit is checked off, or whatever the default is i believe as well, not sure that matters).. to rule out the indexing that occurs.. there was never a drastic difference though, oddly.