bug: ancillary armor repairers are listed as having cap usage bonus when loaded with nanite

[msoltyspl]

All kinds - small, medium, large ones are affected.

[blitzmann]

AAR always use capacitor regardless of having nanite paste loaded. I believe you are thinking of ASB which do not use cap as long as you have cap boosters loaded.

If I misunderstood what you meant, please reopen the issue and elaborate. =)

[OISumeko]

This bug is occuring. The cap stability of a fit is affected by having nanite loaded in the AAR, see:

The cap usage and cycle time on the module is not changing, so it may be related to the clipsize when it is run through capsim. Taking a look at the moment.

[blitzmann]

Oh... that's the problem.

There are a couple open issues that are related regarding the cap simulator, specifically the stability percentage being affected when it really shouldn't. Usually it's affected by a small amount, and nothing that's too detrimental. IIRC, @OISumeko, you've looked into it before and helped fix some bugs, so feel free to dig in. The capsim is one area of pyfa that I haven't really looked at before and so don't know much about it.

[OISumeko]

So from taking a look, what I am seeing is this:

Firstly, this bug only occurs when an AAR and one or more additional reppers are fit, this doesn't happen when just the AAR is fit.

When the sample fit runs through the cap simulator with the AAR unloaded, what we receive in the reset call is two entries, one for the cap booster and one for the reppers, looking like this (humanified for ease of reading):

{name: "cap booster", duration: 12s, cap: -200, clipsize: 2, amount: 1}
{name: "armor repairer", duration: 4.5s, cap: 40, clipsize: 0, amount: 2}

The simulator then assumes we are going to alternate the reppers due to us having staggering enabled, so when it outputs this information into the run cycle, we get:

{name: "cap booster", start_time: 0, duration: 12s, cap: -200, clipsize: 2}
{name: "armor repairer", start_time: 0, duration: 2.25s, cap: 40, clipsize: 0}

With a single repper sent through, but cycling twice as quick giving the effect of two reppers running offset from each-other.

When we run with the AAR loaded however, what we get is this:

{name: "cap booster", duration: 12s, cap: -200, clipsize: 2, amount: 1}
{name: "armor repairer", duration: 4.5s, cap: 40, clipsize: 0, amount: 1}
{name: "armor repairer", duration: 4.5s, cap: 40, clipsize: 8, amount: 1}

which is sent to the run cycle as

{name: "cap booster", start_time: 0, duration: 12s, cap: -200, clipsize: 2}
{name: "armor repairer", start_time: 0, duration: 4.5s, cap: 40, clipsize: 0}
{name: "armor repairer", start_time: 0, duration: 4.5s, cap: 40, clipsize: 0}

Rather than simplifying the reppers to a single twice-the-cycle-speed repper, we have two that fire simultaneously.

This affects the cap simulation like so (bold times indicate a cap booster firing):

Time (s)	AAR Unloaded Cap Amount	AAR Loaded Cap Amount
0.00	100.0%	100.0%
2.25	92.6%	-
4.50	85.7%	85.1%
6.75	79.2%	-
9.00	73.3%	72.3%
11.25	67.6%	-
12.00	100.0%	100.0%
13.50	92.6%	85.1%
15.75	85.6%	-
18.00	79.2%	72.3%
20.25	73.3%	-
22.50	67.6%	61.1%
24.75	62.4%	-
27.00	57.4%	51.2%
29.25	52.7%	-
31.50	48.3%	42.3%
33.75	44.0%	-
34.00	81.6%	83.3 %

I can continue, but you get the idea. Firing two reppers at the same time rather than staggering them is worse for your cap as it is hitting it in bigger chunks and not letting it regen as much between activations.

What I need to do is detect the second case where an AAR is coming in as a second element rather than being bundled with the other repper(s) and deal with it like we do with the first case, which is stagger them by default, or alternatively, send them through with staggered start times.

As an aside, it would be neat to be able to visualize the cap usage in graphical form with staggering enabled/disabled. Possibly something to consider adding when graph stuff is back on the menu?

Also, we could probably consider sending cap boosters through with a delayed start rather than burning a charge immediately. Possibly an option that could be added to a graphing solution, letting people chose when to fire rather than just guessing.

[blitzmann]

Thanks for the fix!

I would love to have some kind of capsim graphing, something like EVEHQ does. I think it would give a bit of insight into some of the edge cases such as this.

Until that happens, perhaps we can have some options in the preferences on whether or not to stagger, and at what % of cap triggers a cap booster.

[msoltyspl]

For the record, the issue is still present in 1.16.0 - SAAR loaded with nanite shows smaller capacitor usage.

E.g. this fit (similar to the one I screenshoted above):

33468:33076;1:4405;1:2048;1:19015;1:5443;1:18692;1:3568;1:4027;1:11578;1:28758;1:31009;1:31051;2:2456;5:23707;5:2488;5:28668;137:32006;17::

Usage is -3.33 instead of -8.89

[OISumeko]

I am not seeing the same thing. Using a fresh install of 1.16.0 using your fit:

Are you absolutely sure you are using the latest version? Is it possible that you have accidentally launched an older version?

My Help > About screen is as follows:

Does yours match this?

[msoltyspl]

I double checked everything and I think the issue was on my side since the beginning - I had "factor in reload times" checked in in options, and with 1minute nanite reload time it lessens capacitor usage drastically. For the record - my readouts in this version and older one seems identical depending whether I have that checkbox enabled or not (and all seems correct).

Thus sorry for this report, though at least OISumeko found something more subtle - so not everything was in vain.