Booster not being applied properly (possibly)

[ghost]

1. When I have a squad booster applied onto a logi ship, the bonuses are applied to that ship and I see the shield reps improve.
2. When I project the logi fit onto another ship, the improved repping power of the ship is applied.
3. If I add the squad booster onto the ship that the logi's reps are being applied to, nothing changes when I expect the repping power to increase due to increased resists. Is this working as intended? Try messing around adding/removing the booster to the logi and other ship and see if it makes sense.

Here's the fits that I'm using:

I have this Scythe fit:

[Scythe, sites]

Damage Control II
Beta Reactor Control: Capacitor Power Relay I
Beta Reactor Control: Capacitor Power Relay I
Beta Reactor Control: Capacitor Power Relay I
Beta Reactor Control: Capacitor Power Relay I

10MN Afterburner II
EM Ward Amplifier II
Adaptive Invulnerability Field II
Large C5-L Emergency Shield Overload I
Shield Boost Amplifier II

Medium S95a Remote Shield Booster
Medium S95a Remote Shield Booster
Medium S95a Remote Shield Booster

Medium Processor Overclocking Unit I
Medium Processor Overclocking Unit I
Medium Capacitor Control Circuit I


Light Shield Maintenance Bot I x1
Medium Shield Maintenance Bot I x4

projected to this Oracle fit:

[Oracle, sites]

Damage Control II
Heat Sink II
Heat Sink II
Heat Sink II
Tracking Enhancer II
Capacitor Power Relay II

Adaptive Invulnerability Field II
Adaptive Invulnerability Field II
Large Shield Extender II

Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L
Tachyon Modulated Energy Beam I, Imperial Navy Multifrequency L

Medium Anti-EM Screen Reinforcer I
Medium Core Defense Field Extender I
Medium Core Defense Field Extender I

with this Sleipnir as booster on the Scythe:

[Sleipnir, Booster]

[Empty Low slot]
[Empty Low slot]
[Empty Low slot]
[Empty Low slot]
[Empty Low slot]

Command Processor I
Command Processor I
[Empty Med slot]
[Empty Med slot]
[Empty Med slot]

Siege Warfare Link - Active Shielding II
Siege Warfare Link - Shield Efficiency II
Siege Warfare Link - Shield Harmonizing II
Skirmish Warfare Link - Rapid Deployment II
Skirmish Warfare Link - Interdiction Maneuvers II
[Empty High slot]
[Empty High slot]

[Empty Rig slot]
[Empty Rig slot]

[blitzmann]

On v1.1.22, there does seem to be a bug.

Using those fits with All V and your method above:

• I applied Sleipnir to Scythe, raising the repping power of each Remote Shield Booster 62.4/s => 78.7/s
• I projected logi onto Oracle, which gave repping power of 606 HP/s
• I added booster to Oracle, which increases logi boosts 606 HP/s => 673.4 HP/s

So your method did not show anything strange.

However, you state that the improved repping power is applied when projecting the boosted logi fit onto the Oracle. Can you confirm this? Because from what I can see, the bug lies in the fact that the projected fit does not take into account possible boosts on the projected fit.

Projecting an unboosted Scythe tot he fit gives me 606 HP/s - the same as a boosted Scythe.

Can you please confirm...

[blitzmann]

I just tried again, and now the improved shield reps are being applied... Definitely something going on here, and it's causing a headache even trying to think about it.

I'll look into it more deeply in the coming weeks (have some things coming up next few days), but this is probably just one of those broken things with projected effects @DarkFenX is always warning about and might not see a fix due to the complexity. =/

[ghost]

Yeah I knew that something was wrong but I could not figure out exactly
what is happening. There is a situation that occurs where if you remove the
boosts from the Oracle, no stats change. It's weird. The order that you
project and add boosts seems to matter.

[blitzmann]

Okay, dug a little more, apparently I did it wrong the first time somehow. Here are my test cases:

Open all fits in tabs, and filter ship browser to show them (I named them all ISSUE63)

• Adding boosted logi to the Oracle gave 673, then adding booster to Oracle did nothing.
  1. Removing booster from Oracle dropped it to 606, then adding it again raise it to 673
  2. Remove booster from Oracle again (should be 606), then remove logi.
  3. Add logi again: it's 606 and we expect 673 (as per our original starting point). However, switching to the logi tab, then back to Oracle shows renewed 673
• Adding unboosted logi to Oracle gave 606, then adding booster to Oracle bumped it to 673

The code behind this is old and hacked together from what I've read. It does okay with projected and fleet boosting, however I don't think projecting a boosted ship while boosting was considered and tested. From the data gathered, it seems like it keeps missing a step, not applying one or the other. Hopefully it's a simply case of forgetting to calculate new states in a particular spot in the code - question is, where is that spot? Is this even salvageable with the current codebase without significant changes?

As stated, I'll look into it, but can't promise anything.

tl;dr: it's fucked

[blitzmann]

Had some time today to sit down and brood over this. Did some more tests, and I believe I've been able to narrow down where the issue may lie.

When the Scythe was boosted and projected onto the Oracle, I noticed that the shield resistances of the Oracle was being raised even when the Oracle was not boosted. I also checked Raw HP (to get the pesky calculations of effective HP out of the way) and performed two tests on an unboosted Oracle: Scythe projection with and without Scythe boosting.

The unboosted Scythe shows 62.4 HP/s for each repper, totaling 187.2 HP/s. Indeed, this is what is shown on the Oracle.

However, the boosted Scythe shows 78.7 HP/s. You expect the Oracle to show 236.1 HP/s, however it shows 187.2.

This, coupled with the fact that the Oracle is receiving resistance boosting when the boosted Scythe is projected, tells me that the Scythe's booster is ignoring the Scythe fit and projecting directly onto the Oracle. Since the projected Scythe is not getting it's boosts, it doesn't project the boosted rep amount.

Will continue to look into this. Hopefully this isn't as frustrating of a fix as it looks on first glance. =)

[blitzmann]

Continuing with the investigation, there are actually three four problems that I have identified:

1. In eos.saveddata.fit.calculateModifiedAttributes(), boosts are being applied to targetFit rather than self. When doing calculations on a projected ship's boosts, target fit is not the projected fit, but rather the projectee. This is why, in the previous scenario, the Oracle was getting the Scythes boosts. This is easy to fix.

2. After fixing this, I noticed that while the standalone calculations of the boosted Scythe was correct, but the projected calculation was not working (Oracle was receiving unboosted reps). This is because that the modules of the projected fit are calculated and applied to the projected fit as well as the target fit, and then the gangboosts are applied. Since the gangboost effects are applied to the modules after they are projected onto target fit, the target fit never sees them boosted. This is also easily fixed by moving the gangboost code above the module code.

3. The withBoosters parameter was not being passed to the projected fits. This caused them to be set to False which would restrict them from calculating boosts (as to why this parameter exists in the first place, I have no idea. This, and the purpose of dirtyStorage continue to elude me)

4. I noticed that, after starting Pyfa and immediately loading the Oracle, it seems that the Scythe does not load it's .fleet attribute, and thus does not load it's boosts. When you load the Scythe itself and then go back to the Oracle, it shows the correct stats (from what I can tell). I suspect it's because when you explicitly load a fit, the service.fit.getFit() is called which manually loads the fleet for that fit. However, when you talk about projected fits, those are loaded via a DB relation, and thus getFit() isn't called for each projected fit and .fleet isn't loaded. I do not currently know how to handle this at this time - I could load the fleet service in fit.calculateModifiedAttributes() and check each projected fit, however I think it's best to avoid mixing services and EOS.

[blitzmann]

Mde a branch with the four fixes, last commit being: blitzmann@b783f06

I fixed 4 to iterate through projected fits in getFit() and load fleet data. These will conflict with currently pending pull requests #78 and #85 - I will wait on decision for those and submit pull request for these. In the meantime, I plan to extensively test these fixes.