The Electronic Hardening Charge used in Information Command Bursts does not affect projected tracking disruption.

[davidyrgilbert]

Submit a bug report bug report or feature request

---

Bug Report

Projecting e.g. a Curse with a Tracking Disruptor fitted onto a turret based ship decreases the tracking and/or range of the turrets. The Electronic Hardening Charge of Information Command Bursts is supposed to lower the effect of Tracking (and Guidance) Disruptors. However, this is not the case.

Expected behavior:

Adding an Information Command Burst with the Electronic Hardening Script should decrease the effects of Tracking Disruptors.

Actual behavior:

The Electronic hardening Script currently only increases the Sensor Str. It has no effect on projected TDs.

Detailed steps to reproduce:

Fit 250mm Rails to a Vulture. Fit an Information Command Burst to it. Fit a Tracking Disruptor to a Curse. Project the Curse onto the Vulture - the Turret stats go down. Activate the Command Burst with the Electronic Hardening Charge - the Turret stats should go up again, but they stay exactly the same.

Fits involved in EFT format (Edit > To Clipboard > EFT):

Release or development git branch? Please note the release version or commit hash:

pyfa 1.28.1

Operating system and version (eg: Windows 10, OS X 10.9, OS X 10.11, Ubuntu 16.10):

Windows 10

Other relevant information:

[blitzmann]

Thanks for the report, will definitely look into this when I get home tonight.

Without having the data at hand at the moment, this sounds like the EWAR resistance stuff that was never implemented. I have a branch that has it working halfway from when CCP started using it a few months back, but never got around to finishing it. If that is the case, I'll take a look at what's involved to finish it up in time for the next release on the 9th.

EDIT: lol yep. #597 Apparently had it working, never got around to releasing it. Hopefully i have the branch floating around somewhere. if this is the cause of the bug, will let you know what happens here. :)

[blitzmann]

I took a look at this a couple days ago. Indeed, the ewar resist code is included in the codebase - I was thinking about the remote reps impedance stuff that is yet to be implemented. From what I can tell, the calculations are usually applied correctly, just not in this particular case due to the following:

Most ewar modules have a remoteResistanceID attribute in order to identify which resist attribute to check against. For example, a Stasis Web has a remoteResistanceID of 2115, which tells the calculations to use the destination's stasisWebifierResistance attribute to modify the incoming bonus. However, it seems that Tracking Disruptors don't have a remoteResistanceID assigned to them. I've reached out to CCP to see if this is indeed a bug on their end, and if not then how to proceed with this case. Will update when I get more info.

Additionally, there is an issue in which we're looking at the wrong source when it checks the fit to see if it has the remote resist ID. Will look into this and submit fix, however this doesn't address the above issue directly.

[blitzmann]

Thanks to @ccplarrikin for clearing up whats going on. So, apparently, tracking disrupter doesn't have the resistance attribute because it's somewhat of a deprecated thing. The resistance ID is now stored on the effect itself instead of as an attribute on the item. After a few tweaks I got it working, so it should be available with the upcoming stable release :)

Thanks for the bug report :D

[blitzmann]

And after running a quick query, it seems that CCP is using two different versions of the remote resist stuff - one that works off the attribute of an item, and one that works on the effect. I assume they simply haven't moved them all over yet to the effect way. In the meantime, we'll have to support both situations. fun. >.<

[blitzmann]

@NamelessNewbie should be fixed in 1.29.0, let me know if you have any other issues with this. :)