Cap stability changes with capless modules

[blitzmann]

All V skills.

1. Open Gila
2. Add web II. Cap stability should be at 96.2%
3. Add missile launcher, cap stability drops to 96.1%

This seems to affect any fit where you have cap and capless modules (another example would be hurricane with web, and adding an autocannon)

The total cap / cap usage stats do not seem to change, only the percentage.

[blitzmann]

[Scimitar, SS Scimi Muninn]

Power Diagnostic System II
Power Diagnostic System II
Power Diagnostic System II
Capacitor Power Relay II

Adaptive Invulnerability Field II
Large Shield Extender II
Experimental 10MN Microwarpdrive I
Cap Recharger II
Conjunctive Ladar ECCM Scanning Array I

Large S95a Remote Shield Booster
Large S95a Remote Shield Booster
Large S95a Remote Shield Booster
200mm AutoCannon II

Medium Capacitor Control Circuit I
Medium Capacitor Control Circuit II

Friend reports that offlining / onlining autocannon changes stability from 36.4 to 38.1, which is a bigger change than what was previously noted on Gila above. Look into if this can affect marginally cap stable fits.

Also, loading the autocannon with ammo bumps stability from 36.4 to 36.5. =/

Whether or not this is fixed really depends on if there is a use case where a fit is stable but the simulator bugs out and says it's not, or vise versa

[blitzmann]

Took a quick look at this since I had 5 minutes to kill. There is something wrong with the cap sim calculation, but I don't know the mechanics of it well enough and don't really have time to delve into the maths of it.

However, I do have a quick fix that more or less avoids the problem rather than fixing it, with the end result essentially being the same (commented portion is the actual fix, commentary below):

for mod in self.modules:
    if mod.state >= State.ACTIVE:
        #if mod.getModifiedItemAttr("capacitorNeed") > 0:
            cycleTime = mod.rawCycleTime or 0
            reactivationTime = mod.getModifiedItemAttr("moduleReactivationDelay") or 0
            fullCycleTime = cycleTime + reactivationTime
            if fullCycleTime > 0:
                capNeed = mod.capUse
                if capNeed > 0:
                    capUsed += capNeed
                else:
                    capAdded -= capNeed

                drains.append((int(fullCycleTime), mod.getModifiedItemAttr("capacitorNeed") or 0, mod.numShots or 0))

Pyfa basically takes all active modules and adds them to a cap drain list. When appending, this bit mod.getModifiedItemAttr("capacitorNeed") or 0 ensures that we stick cap-less modules in the list but with a drain of 0. This should be handled correctly in the cap sim but apparently it isn't -- maybe it has to do with calculations with the clip size, etc. Since it's not handled correctly, capless modules interfere with the end result.

Now, to my knowledge, there is no reason to add cap-less modules to the list. That's where my commented fix comes in, and seems to work as expected. I'll commit this after discussing possible unforeseen side effects with Kadesh

In case we want to go into further diagnostics at any time, the deepest I delved into the cap sim was confirming that cap_stable_high was the attribute that seems to cause the problem.

[blitzmann]

Changed comparison from > 0 to != 0 per suggestion from Kadesh.