Loadout implementation issue

Note: this is a ‘tedious implementation detail’ thread as opposed to another ‘what should loadout look like to the player’ — all are welcome, of course, but it’s unlikely to be of much interest except to the script bunnies among us. I’m putting it up here in the hope that EricMan64 or others who’ve worked with loadout code might have some useful insight.

To the point. I’ve been going round in circles, wrecking various bits of code along the way, trying to address the issue of loadout initialisation: specifically, any loadout code needs to be able to map subsim objects to their corresponding sim ini file template[] numbers.

This isn’t a problem for any sim I’ve already been meddling with: I just slap an int property on each subsim binding it to its template[] number.

The difficulty occurs when I first look at a sim that’s been created by Sim.Create() (or iShip.Create()) — this won’t have the int properties yet, so I need another way of identifying the correspondence. I can’t see any obvious relationship between the order in which the engine stores subsim objects (Sim.NthSubsim()) and their template[] numbers. This reduces me to messing around with name and/or class comparisons. It is possible to map subsims to template entries in cases where only one subsim of a given class exists, but if a ship has, say, two PBC subsims, I can’t pin down any way for the loadout code to tell which one corresponds to which of the two template[] entries that originally created them.

Can anyone see a way round this? I have two (1.5, really), but I’m not very keen on either of them.

The first option is to give up on retaining compatibility with Sim.Create() and iShip.Create() — if we require all Epic packages to get their ships initially from flm_lo.CreateShip(, ), I can attach the information I need when a ship is first created, which neatly removes the problem, but at the high cost of requiring all other packages to go through mine for ship creation.

The second option is not that dissimilar: I can strip all existing subsims from a sim, and replace them from its ini file, attaching the template[] references as I go — this is, of course, actually all the aforementioned iShip.Create() wrapper does in practice, anyway. The difference is that we wouldn’t require it to be done for all ships, but only ones that the loadout code is interested in.

The further problem here is that, in fact, the loadout code is interested in all ships, anyway: as well as allowing us to alter what subsims are loaded where, the loadout package exports SaveLoadout() and RestoreLoadout() functions for use by GrandpaTrout’s save-anywhere code — those functions store subsim state information (damage and operational status) that are also subject to the need for a template[] reference if they’re to be restored accurately. The strip-and-rebuild initialisation can’t be done at the last minute without potentially losing state information on the stripped subsims — so it has to be done as early as possible, and we end up back at the first option, with breaking iShip.Create() compatibility being the only way to guarantee the accuracy of the save/restore state functions.

I’d really prefer not to require all scripts to go through a wrapper like this, but I’ve run out of other ideas. I feel sure I’m missing something obvious. Help?