Overload/heat implementation

[DarkFenX]

Theory is here: https://forums.eveonline.com/default.aspx?g=posts&t=32225

Going to back-up it here too:

Heat gain law:
H(t) = heatCapacity / 100 - e ^ (-t * heatGenerationMultiplier * sum(heatAbsorbtionRateModifier)), where:
t - time in seconds (or we can call it 'tick', as TD will make actual server seconds slower) since you started overheating your mods, at which rack temperature should be 0
H(t) - temperature of rack (absolute) at time t
heatCapacity - value of attribute ['heatCapacityHi' | 'heatCapacityMed' | 'heatCapacityLow'] of your ship
heatGenerationMultiplier - value of attribute 'heatGenerationMultiplier' of your ship
sum(heatAbsorbtionRateModifier) - sum of values of 'heatAbsorbtionRateModifier' attributes of all modules you're overheating in given rack

Heat dissipation law:
H(t) = H(0) * e ^ (-t * heatDissipationRate), where:
t - time in ticks since you started observation
H(t) - temperature of rack (absolute) at time t
H(0) - temperature of rack (absolute) when you started observation
heatDissipationRate - value of attribute ['heatDissipationRateHi' | 'heatDissipationRateMed' | 'heatDissipationRateLow'] of your ship

Notes:
Heat gain/dissipation in any given rack is completely isolated. You can overload your MWD while having high slot rack being cooled.
Rack heat dissipation stops when you overload any module in given rack.

Heat damage
The easiest stuff: when module is overloaded, it damages itself and other mods by the value of its 'heatDamage' attribute (modified by your skills, ship and any other possible modification sources).

Chance to damage
When you overload any module, it has chances to damage any module from its rack
P = Fh * Fs * Fa, where:
P - chance to damage given module (absolute)
Fh - heat factor, described in details below
Fs - slot factor, described in details below
Fa - attenuation factor, described in details below

Fh = H, where:
H - heat of given rack (absolute) by the end of overheated module cycle

Fs = (Ho + Mo + Lo) / (Hs + Ms + Ls + Rs), where:
Ho - number of online+ modules in high rack
Mo - number of online+ modules in medium rack
Lo - number of online+ modules in low rack
Hs - total number of slots in high rack
Ms - total number of slots in medium rack
Ls - total number of slots in low rack
Rs - total number of rig slots
'online+' term includes all online, active and overloaded modules. That is, offlined modules act as empty slot here.

Fa = heatAttenuation ^ distance, where
heatAttenuation - value of attribute ['heatAttenuationHi' | 'heatAttenuationMed' | 'heatAttenuationLow'] of your ship
distance - distance of given module from overloaded module (that is, overloaded module itself has distance 0), rack isn't looped - so first and last modules are not adjacent

Notes:
Module is assigned to some rack and position within this rack based on its real position, visual rearrangement many players do in space has no effect on this
If overloaded module is killed mid-cycle by other overloaded module, it instantly goes offline - stops affecting ship, and doesn't damage other mods (both at the moment of death and at the expected end of cycle)

Speculations:
Reliance on 'heatCapacity' series of attributes: i wasn't able to check it, as all of the ships have it at 100. It may be possible that its other value doesn't affect anything at all - could be hardcoded
Reliance on 'heatDissipationRate' series of attributes: i wasn't able to check it, as all of the ships have it at 0.01. It may be possible that its other value doesn't affect anything at all - could be hardcoded

[DarkFenX]

Chat discussion (mostly for back-up purposes too):

@Ebag333
Heat is hard because of RNG
@DarkFenX
and it's way more important for end users
well
u can use probability theory and give not exact number
@Ebag333
The min/max get further apart the longer it runs
@DarkFenX
but mean number +/- scatter for 95% confidence interval
it's the same with amarr t2 charges
@Ebag333
?
@DarkFenX
you can't predict how much shots will they make
because it's RNG
@Ebag333
Hmm
They have a number
In attributes
@DarkFenX
you can use negative binomial formula, provide values and get range for the confidence interval you need
they have hp, damage per cycle, and probability of damaging cycle
faction have 100% chance to run 4000 cycles
t2 are 1000 average but this is not reliable
and i suppose that you run multiple simulations to provide the numbers, or use some weird stuff from probability theory to figure it out
im bad at it (has been slacking in university during probability classes), so had to figure the stuff about confidence intervals much later when i dealt with t2 crystals
probably someone more educated will figure how to handle it w/o multiple simulations
https://en.wikipedia.org/wiki/Negative_binomial_distribution - this is what i used for t2 charges
@DarkFenX
g2g c u
@DarkFenX
To find out NB distribution, you provide amount of hits (or misses) to end an experiment and probability of hit or miss. The distribution you have is amount of trials it will take to end the experiment. Distribution itself provides mean value of trials. You can apply confidence interval onto it. As a result, you will get range of trial amounts it will take to end the experiment. For t2 charges, the numbers are 100 hits, 10% chance of hit, approximately 1000 mean number (although i remember it being lower for some reason). With 95% confidence interval applied, you get range of 456-1708 (numbers are arbitrary here). Confidence interval here means that there's 95% chance that amount of cycles sustained by this crystal will be within this interval.
Heat in its regular mode is very similar to t2 crystals. There're just multiple NBDs stacked onto each other, due to module having a chance to damage nearby modules. However, there're two things which need tackling:

1. heat buildup. Chances of hit/miss are growing with rack temperature with each trial. 2) burnt out modules do not generate heat, do not damage themselves or nearby modules
   @DarkFenX
   If we find solutions for these two points (even approximate solutions will do), we have analytical solution for the heat problem
   If we don't, we have to oversimplify it or write sim which does thousands of runs to find mean values
   Think i am gonna create ticket for that, to not let this data get lost. Someone interested enough may pick it up
   @DarkFenX
   Maybe there's some NBD-alike distribution for non-bernoulli trials
   http://stattrek.com/m/online-calculator/negative-binomial.aspx yeah expected value is below 1k
   For t2 crystals
   Not mean but the most probable value

[DarkFenX]

So, my proposal, regarding how to find time it takes to 'kill' module within a given slot of ship:

Glossary:

• target - module for which we're calculating time-to-die
• source - heat source. Any module being heated in the same rack. Target can be a source too.

General approach is:

1. Get all the sources
2. Compose one NBD for each source affecting target
3. Combine distributions and pull all the needed values out of it

Composing NBD:
We cannot compose NBD for heat damage for any given source because trials are not bernoulli: https://en.wikipedia.org/wiki/Bernoulli_trial Bernoulli trials have static success rate by definition, but in our case success rate changes over time due to heat buildup. I suggest to manipulate rack heat function to change it.

Here's example of how it looks: http://www.wolframalpha.com/input/?i=100+%2F+100+-+e+%5E+(-t+*+1+*+0.04) (t in the range [0, infinity) on this graph)
What we need to do is to 'transform' it into function y = 1 to make sure our trials are bernoulli ones.

1. One of the ways to do it - is to take 'cut-off' point (when function's value is at 0.99 or 0.999, for example). Assume that everything to the right is y = 1. Everything to the left should be replaced with rectangle. Rectangle should have height of 1. Rectangle's area should be equal to the area between t axis and original function to the left of cutoff point (i.e. definite integral of our function, from 0 to cutoff point). The difference in lengths between function segment we're replacing and rectangle should be memorized.

Equality of the function segment area and rectangle area make sure that average damage done to the target will be the same. Area of function segment stands for heat damage done to target during heat buildup time. Area of rectangle stands for damage done to target with rack being at 100% temperature. I am not sure if i am explaining it in a clear way, so i will repeat in another words: instead of using target for a long time, while rack temperature is building up, we use it for a shorter time with the assumption that rack temperature is always 100%, even in the beginning.

2. More accurate way would be roughly the same, just do not introduce any cutoff points. Find value of integral of function e ^ (-t * heatGenerationMultiplier * sum(heatAbsorbtionRateModifier)) in the range from 0 to infinity (it's area between heat buildup function and function y = 1). This area would have equal value to the time we have to delay 100% heat target launch compared to 0% heat launch.

Example:
1 - e ^ (-0.04 * t) (t1 mwd being heated on retribution)
indefinite integral of its e ^ (-0.04 * t) part is -25 * e ^ (-0.04 * t)
definite integral on range [0, infinity) would be 25 (t = 0 - value -25, t = infinity - value 0)
then we would have to delay target launch by 25 time units (seconds in our case) at 100% rack temperature, compared to target launch at initial 0% rack temperature. Targets are expected to burn out at the same time in these cases (which is approximation, because burn damage is received at discrete time marks).

3. More advanced way which uses non-bernoulli trials: https://en.wikipedia.org/wiki/Experiment_(probability_theory)#Mathematical_description
   I am bad even at probability theory basics, let alone a bit more advanced stuff. If someone could help us to get distributions with non-bernoulli trials (with custom mapping of events to probabilities), we might try to follow this path.

Combining distributions
No idea how to do it. Have to do research and some reading. This might be of some help: http://ibrarian.net/navon/paper/Aggregating_Probability_Distributions.pdf?paperid=8542030
Maybe some libs like scipy provide APIs to do this too, have to check them.

Burnt out modules
Yet another issue is how do we take into consideration that module which burnt out stop producing heat in all our equations? I honestly have no idea.

[DarkFenX]

Posted by @Ebag333

This is good info.

We can ask CCP Larrikan or maybe CCP Fozzie to take a look at this and see if it makes sense. Both have worked with us in the past on figuring out functionality. For something like this they're probably not going to give away the actual secret formula, but they might comment whether it looks accurate or not.

Burnt out modules
Yet another issue is how do we take into consideration that module which burnt out stop producing heat in all our equations? I honestly have no idea.

What a lot of people have been requesting is not only a way to see how many cycles a module will last (which is difficult enough....) but a way of plugging in various variables and getting a 1 cycle chance back. In many ways this is easier than trying to calculate it out to infinity.

Urgh. This is giving me a headache thinking of all the variables we need to pass in.

Also, keep in mind that CCP has been tinkering with heat lately. For example, offline modules to act as a heat sink isn't a thing anymore, empty slots act the same (or so I understand). So things may have changed since you wrote up that information originally.

[DarkFenX]

Also, keep in mind that CCP has been tinkering with heat lately. For example, offline modules to act as a heat sink isn't a thing anymore, empty slots act the same (or so I understand). So things may have changed since you wrote up that information originally.

Well, this is sad. We will have to redo at least some of the tests from scratch.

[DarkFenX]

Posted by @blitzmann

Also, keep in mind that CCP has been tinkering with heat lately. For example, offline modules to act as a heat sink isn't a thing anymore, empty slots act the same (or so I understand). So things may have changed since you wrote up that information originally.

Do you have a source? I'm out of the loop when it comes to balancing changes, but I always thought that heat was one of the things they would always leave alone.

[DarkFenX]

Posted by @Ebag333

Do you have a source? I'm out of the loop when it comes to balancing changes, but I always thought that heat was one of the things they would always leave alone.

Nothing concrete, no, but you know how that goes. That's why I recommended reaching out to CCP and seeing what they feel comfortable with sharing on this.

There's been a number of very detailed discussions on heat (including simulating it) in #fits on tweetfleet Slack. CCP changed (almost) all the tiericided modules heat, for example, so their whole model of "this group has better heat that that group, etc" went out the window and now it's pretty much T1/Meta/Faction VS T2 (and only one small difference between those two).

It makes how heat is handled much easier for the end user at least.

[DarkFenX]

It has always been t1 vs t2, according to my knowledge (i didn't see any exceptions, although there might be a few). t1 modules heat rack at a slower pace compared to t2 - but all of them had the same damage per cycle and HP. Are there any exceptions to this rule?

Changing a few attributes is not the same as changing mechanics of heat which works with these attributes. I am going to test it (offline modules counting as no-module) today or tomorrow. I don't see why CCP would want to change it, so i really doubt it changed.