Check to see if reactivation delay is included in cap calculatations

[blitzmann]

See #1387 for discussion. It looks like there is code that checks for this, but I am unsure if it's properly applied. Need to double check, and if it isn't, come up with a solution to incorporate module reactivation delay in the cap calculations

[blitzmann]

It seems that reactivation delays used to be included, but were regressed with a change aimed to make the code more readable (and improve functionality for things like MJD). Will take a look more in-depth this week, I don't think it's too difficult, especially considering we have a list of all reactivation modules and can test them one by one without too much trouble.

[blitzmann]

The linked issue also has some more information about this

[Neugeniko]

The cap calculation takes into account the reload of the aar in this case but doesn't calculate the proper sustained hp/sec due to reload. With a asb the cap doesnt matter and the sustained hp/sec is just determined by 'duty cycle' of asb, currently the asbs are bugged and show reinforced=sustained hp/sec.

[Neugeniko]

Reactivation delay and Reload of tank mods is a different mechanic. And I think coding may be different enough to warrant separate issues?

[blitzmann]

Reactivation delay and Reload of tank mods is a different mechanic.

When it comes to cap, I believe they are the same for pyfa, see comments here:

Pyfa/eos/saveddata/module.py

Line 716 in fa3cf90

if numShots > 1:

However, I will re-open the other issue until it can be thoroughly looked at, was just thinking (or hoping) they were the same. Cap stuff always gives me a headache @_@

[blitzmann]

I believe it was b3c727 that regresses reactivation delay in a few instances (at least with new items that have been released). Would need to look into the current code and the code it replaced (which was tested as taking reactivation into account properly) to see how best to merge the two, taking into consideration all available use cases. Can use the same query from the referred issue to determine which modules use cap as well as have an activation delay:

select * from invtypes t
JOIN dgmtypeattribs ta ON ta.typeid = t.typeid
join dgmattribs a ON a.attributeid = ta.attributeid
where a.attributeName = 'moduleReactivationDelay' and ta.value != 0.0
and t.typeid in (
	select t.typeid from invtypes t
	JOIN dgmtypeattribs ta ON ta.typeid = t.typeid
	join dgmattribs a ON a.attributeid = ta.attributeid
	where a.attributeName = 'capacitorNeed' and ta.value != 0.0
)

I think it could be as easy as making another case statement, but I haven't dived into it.

[DarkFenX]

It is included. Example: MJD on paladin. Cap use 786, cycle time 9, reactivation delay 54.

Cap use shown in UI: 786÷63 = 12.476190476 (12.5 shown in cap column and in cap stat column). Cap sim graph shows it too:

This data used by graph is also used by sim to calculate stability issue, so yes it is all considered.