Loadout implementation issue

Additionally, Shane would likely make with the blunt instruments were I to decide at this stage that I need mountpoint subsims on every ship.

If you need it done, I'll do it. No problem.

I have to admit this conversation is a little over my head... would it help to know that every system on every ship has a null placed on the model where the system goes? Even systems such as life support, autorepair, etc. And that each null is named with an original name which does not appear anywhere else upon the model? For instance, right_upper_magazine, left_lower_magazine, and the like? The name of the null is now self-explanitory (the old system was giving me fits).

Hope this helps in some way.

No confusion; just wrong or right ... Only Solutions

I've probably broken my installation, or maybe I'm plain looking at the wrong ini file, but my (well, GrandpaTrout's, this being the Epic test start-game script) ini:/sims/ships/player/fast_attack_prefitted has subsims in an order bearing no resemblance to its template[] entries (this is before I've done anything peculiar to it). If ships started out with their subsims in the right order, I'd just rely on that and bind their numbers as early as possible, but if it's not consistently the case, I'm not sure the strip-and-rebuild approach can be avoided. I'm not ecstatic about requiring an initialisation call immediately after ship creation (particularly since it requires all sorts of faffing about with undocking and redocking to prevent the game getting upset about me destroying dock ports when they're in use), but I don't see how else to guarantee the accurate mapping of subsims to template numbers.

I'd suggest doing more thourough testing on the subject to make sure, but I'm fairly certain that when a sim is created, subsim numbers line up with template[] numbers. If this were not true, my loadout code would not work as that's how it finds out what null the mountpoints go with. I've flawlessly settup my loadout code with every ship I've tries so far including flitter, tug, and frog miner. I have not had any trouble, and I can't believe the numbers all worked out by a freak coincidence.

or are you saying that mountpoints appear in template[] order, but other subsims don't?

Now that's something I had never thought of before. All of my testing was to make sure my mountpoints were where they were supposed to be. I'm not sure if I've ever tested with other subsims. I don't think this is the case, but it might be worth checking into.

On the ammo count issue, what I reckon we want to do is store the inventory count as number of rounds, rather than number of pods, and add a special case to the pod/inventory conversion that equates a pod to 40 (or whatever) rounds in inventory (and just refuses to make a pod if you can't fill it). I think that should work best from the point of view of a loadout system that allows ammo-based weapons to carry arbitrary numbers of rounds limited by cargo space, but I don't object if anyone's dead set on some alternative.

That would probably be the best method, and it shouldn't be too hard to implement.

GrandpaTrout: on a vaguely related note, I think we need an iMultiplay.LinkShipWeapons() somewhere in the Epic final setup routine -- the two PBCs are selecting as separate weapons for me until I call it.

That function has always left me with questions concerning weapon linking. It's in the iMultiplay package, so I assume it was only written with the intention of multiplayer quick linking. How does the single player game go about linking the weapons? Is there something you manually do to subsims?

originally posted by Shane
would it help to know that every system on every ship has a null placed on the model where the system goes?

If the null name were visible as a string property, this'd help with the problem at hand, but, as far as I know, it ain't. I do think having one null per subsim or hardpoint is a good thing, though, since it means we can easily move subsims about without worrying about unexpected side-effects (as in Hotfoot's recent post about multiple template[] entries apparently loading to the same null[], rather than 0,0,0, if null[] entries are omitted).

originally posted by EricMan64
I'd suggest doing more thourough testing on the subject to make sure

Done. I've run DebugBarfSim() on various ships, including your hangar code tug and a couple of the unmodded player ships; as far as I can see, the matching of Sim.NthSubsim() to template[] indexing isn't exactly coincidental, but it is a side-effect of the fact these sims have almost exclusively icMountPoint subsims, whose order the engine doesn't meddle with. It's fairly probable the unmodded game's loadout code also relies on the resulting correspondence, since it appears to apply to the mount points on the unmodded player ships.

Prefitted ships, unfortunately, don't preserve order at all. The order in which their subsims end up from Sim.NthSubsim()'s point of view does look consistent, but has somewhere between little and nothing to do with the template[] order. It seems to match the order in the ENG screen (Autorepair's always first, then reactor, etc). We could try to reconstruct the rules governing the ordering, reproduce it in prefitted sim files, and then be able to rely on Sim.NthSubsim() matching template[]. That'd involve a lot of incredibly tedious testing, though, and the end result would be extremely vulnerable to a single error in a sim ini, so for it to be reliable we'd have to write and debug a script to do the ordering for us. Since the strip-and-rebuild approach appears to be working so far, I think I'll stick with it at least for the prototype -- I don't like it much, but trying to deduce the rules for prefitted subsim ordering would probably be even more painful.

How does the single player game go about linking the weapons? Is there something you manually do to subsims?

Still need to look into this further, but observations and assumptions so far: iMultiplay.LinkShipWeapons() has to be called for identical weapons to be recognised as such. I think it relies on the weapons' 'name' property for this, but it could be something else -- obviously, since identical weapons come from the same ini file, all their properties match. I've never tried breaking it by deliberately using different classes or property settings with the same name, so I don't know how it'd respond to that.

What it actually does is create an icWeaponLink subsim for each linkable weapon, with the same name as the parent real weapon. There must be some link between the icWeaponLink subsim and it's parent, but it looks to be buried where pog can't see it -- apart from making Sim.FindSubsimByName() potentially unreliable for weapons, I don't think these extra subsims do anything as far as pog's concerned.

Just doing iMultiplay.LinkShipWeapons() leaves matched weapons in chain fire mode. Switching to salvo mode requires that you have the appropriate hardware; I still don't know exactly how this is checked, but I have a strong suspicion it's just an inventory check, which the unmodded game can get away with because there's only ever one player ship. If this is correct, we'd have to (a) make salvo fire always available to all ships (easy), or (b) hack together our own solution with a new CPU program in an unused slot, and flip the inventory count for CT_WeaponLinkHardware to 0 or 1 depending on whether the program's loaded.

That's interesting... I put four comms lasers onto a puffin tug, and it fires them all at once, without any prompting. I also put four rapid-fire cannons onto one, and they all fired as one.

I can send you the file if you like.

No confusion; just wrong or right ... Only Solutions

<sigh> Why can't even one thing be simple? Correction to the above: I've just done some quick tests of the hypothesis that CT_WeaponLinkHardware only needs to be in inventory to be usable, and it looks to be wrong -- it may be that its presence is recognised only after the player has been back to base (which wouldn't be helpful for the no-base-at-all scenario), or that some other default game script that isn't running in Epic needs to be there for it to be recognised. Will report back if I find anything more.

originally posted by Shane
I put four comms lasers onto a puffin tug, and it fires them all at once, without any prompting. I also put four rapid-fire cannons onto one, and they all fired as one

Is this from a heavily-modded new or reloaded single-player game, or from the current Epic 'new game' test, and is iShip.CreatePlayerShip() involved at any point?

I know weapon association 'just works' in a single player game or a free-form saved game, but I've been under the impression the current Epic test setup isn't initialising whatever makes this happen. Most of the default scripts (apart from the 'start new game' one) are still being called, AFAICT, so I'd been thinking it's probably tied somehow to the base or iLoadout functions.

If you have sims that are doing linking without help after a 'Start New Game' into the current Epic packages, I'd definitely like a look at one to see if I can make out a reason.

Ah. That explains it. It was the savegame test point I use for the Sandbox, and it was taken from a save in free-form mode (so I would have access to all player systems during testing). Only Sandbox mod and your Damage Interface mod running (with multimod and lazy utilities to support).

The ships are created by the Sandbox through: iShip.Cast (Sim.Create ( Global.String ( "g_Sandbox_Type_Of_Ship" ) , "" ) )

No confusion; just wrong or right ... Only Solutions