Reducing campaign layers = faster loading?

[JScones]

Originally Posted by GlobalExplorer

Now what I am suggestion is not as mod, but a program that you configure like:

Start: Month/Year
End: Month/Year
TOO: <area>

The program would the read all campaign files, discard all units outside the specs and write the reduced layer back into new files.

That would not be difficult, at least now with the kind of libraries I am using / developing.

But! I see lots of problems with loading of previous savegames. I have not done any testing of the implications and that's what I hope to find out through this thread:

a) Do the units in a campaign layer have to be in sequential order for SHIII to load?

b) If not, and if the index of a unit / group has changed in between save/load, will SHIII then crash because it cannot resolve the references?

c) will the reduction of the layers lead to a significant speedup of loading / that does justify such a program? (feedback so far indicates this might be the case)

Would anybody have an interest in such a program? I am not saying I will do it, but I can provide a c# library that does most of the work already (it makes parsing and writing the .mis files a breeze and is very fast).

GE

I must admit that I have written numerous tools for querying the mis files (have now got it where I can parse and perform calculations on 1,000,000 lines in mere seconds). I have always taken a "clean" approach and re-indexed to compensate for any removals that I have made.

Whether this is necessary, I have never tested. BUT, the ME does it so that's good enough for me. And many times I've removed one group or unit entry and caused no ill effect, although, I would guess if I had removed an entry that was referenced in the current mid-patrol save game, then well, it may be a different matter.

Thus I think if the programme simply removed the "out of scope" scripting everything *should* be OK. Save games seem to get more upset if units that are expected to be there at that time are not, so this means simply don't make changes mid-patrol.

Provided the programme makes no changes to the remaining entries, I can't see where there'd be problems. Just look at GWX Patch 1.02 - it made hundreds of mis file changes and most careers continued to work. The only careers that failed were those that had "pointers" to units or scripting that no longer existed at that time frame.

BBW or Rubini are prolly better placed to comment in this regard.

But my gut feeling is that it may cause more problems than it's worth (and this is assuming that removing entries creates no CTDs of its own) - to be blunt, some players have enough problems keeping up with JSGME and SH3Cmdr housekeeping. As the programme would need to maintain backups of the "pre-modified" mis files, there will be another set of backups (or at the least changes) for players to keep track of. All for what, one, two minute load gain? And what if a player dies and decides to load an earlier save? The reason behind the resulting CTDs may not be obvious to them at first (ie "D'oh, I forgot I was running x").

It's why I haven't released any of my SH3 tools to anyone other than a few people.

But just like JSGME and SH3Cmdr, if players still want such a tool taking this very likely risk into account, go for it - either way it's certainly an idea worth discussing.