These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Ships & Modules

 
  • Topic is locked indefinitely.
 

Overload Explained

Author
Kadesh Priestess
New Order Outreach Division
CODE.
#1 - 2011-11-10 18:43:31 UTC  |  Edited by: Kadesh Priestess
Here i'm going to talk about some technical stuff (interesting to some pr0-pvpers or nerds, lol), so if you're looking for some exciting read, this one likely isn't for you.

Heat fromulae

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
Kadesh Priestess
New Order Outreach Division
CODE.
#2 - 2011-11-10 18:44:54 UTC  |  Edited by: Kadesh Priestess
Experiments backing formulae

You want to read this only if you think any formula is wrong, and want to figure why; useless otherwise

Some time ago i placed some bounty on this forum and eve-ru forum. Unfortunately, not much feedback here, but i've got few ideas from eve-ru buddies. Recently got some time to test this stuff on sisi.

Things i already knew:
Damage inflicted is always equal to heatDamage of overheated modules (even when it damages rack neighbours)
Chance to damage depends somehow on rack temperature
Chance to damage depends on number of filled with online modules slots (friend of mine years ago noticed that slasher with just MWD can burn more than 2k km with MWD overloaded, while tightly fitted slasher flies barely 200-300 km)
Temperature gain depends on number of overheated modules
All modules from the rack can be damaged by overloaded module
All math in EVE likes linear dependencies and multiplicatives

Everything else (except for a few small things i didn't bother to list) was a dark matter to me.

First, i got a link to the (stolen?) goonwiki which transcribed Tuxford's heat math presentation, with broken link to video. Few seconds of search, and i found it at tentonhammer, and used this material to check all my assumptions and experiments. All i can say beforehand, data i've got there saved me some time, but it wasn't 100% accurate.

As first experiment, i double-checked almost-fact - dependence of chance to damage module on the number of online+ mods. Just in case, i also checked cloaks, which are known to apply penalty even when offline. Used retribution as ship, varied its setup w/o adding speedmods, making it possible to measure flight distance (off the station) instead counting time or mwd cycles. Results:

Quote:
Experiment 1:
T1 mwd + 5 t2 Adaptive Nano Platings (onlined): 280 180 208 216
T1 mwd + 5 t2 Adaptive Nano Platings (offlined): 910 1829 1247
T1 mwd + 2 t1 kinetic hardeners (onlined) + 2 t1 kinetic hardeners (overloaded) + t2 co-proc: 280 245 250
T1 mwd + 5 t1 prototype cloaks (offlined): 2200 900 635

Ok, more or less confirmed: empty hi/med/low slots and any offlined mods in these slots reduce chance to damage overheated module. What's about rigs, if i install these to empty ship - will it affect overheat sustainability? I've too rifter, used current clone (the only speed mod is zor hyper-link), used the same approach as in previous experiment - measured distance between station undock and point at which my overheated module breaks. Difference was expected to be in 4-6x order, thus minor measurement errors didn't matter here.

Quote:
Experiment 2:
MWD: 2745 1143 2184 954 1323 1827 1800 2384 953 1360 (1667 avg)
MWD + 3 x t1 core field extender rigs: 1408 1093 1047 1320 1040 1230 1220 580 1970 860 (1176 avg)
MWD + 3 x t2 200mms ACs: 312 576 309 487 345 (405.8 avg)

Huge influence of random on small amount of observations introduces huge error, but as expected difference of 4 times was observed for ACs but wasn't for rigs, i figured that installing these isn't counted as module.

Then i decided to take a 'break' and check minor thing in heat gain/dissipation. Based on the assumptions that heat gain depends linearly on number of overloaded modules of same type, i fitted retribution with 4 t1 armor kin hardeners and measured time it takes to raise low rack temperature to 95%.

Quote:
Experiment 3:
4 hardeners overloaded: ~35 seconds
1 hardener overloaded: ~144 seconds

Linear dependency points at two things: heat dissipation stops once you overload any module of the rack (otherwise difference would be in more than 4 magnitude) and time to 'heat' the rack is likely to linealy depend on number of overloaded modules.

Ater it i switched back to chance testing. 'What if empty rig slots help to avoid heat damage?' i thought. To test it, we need to have all of known factors being close to 1: attenuation (test only module self-damage), rack temperature, slot ratio. For testing purposes, got Hookbill with 5 t1 photon scattering hardeners, 3 t2 rocket launchers, 2 t2 cpus, rig slots are empty. Hardeners were activated and overheated one-by-one, with some minor overlapping (to not let heat dissipate), measurements started once rack temperature reaches 95% in EVE UI, cycles adjacent to hardener-to-hardener overlapped switches were ignored.

Quote:
Experiment 4:
Run 1: 0 0 - - - - 0 0 - - 0 - 0 0 - - - 0 0 - -; 0: 8, -: 12
Run 2: - - - - - 0 - 0 - 0 0 0 0 - 0 0 0 - - 0 - - - -; 0: 10, -: 14
Run 3: - - - - - - - 0 - - - - - 0 - 0 - -; 0: 3, -: 15
Seeing the outcome, i decided to mix rigs into experiment - added t1 missile rof rig and 2 t2 field extenders to fill rig slots and calibration up to 100%
Run 4: - - - - - 0 - - - - 0 - - - - 0 - - 0 - 0 0 - - - -; 0: 6, -: 20
Run 5: - - - - 0 0 0 - - - -; 0: 3, -: 8
Legend: '0' - overheated module isn't damaged, '-' - overheated module is damaged

To process the data easier, we can assume that rack temperature is 0.97 on average. As final results, we have 30 cases when modules didn't damage self out of 99 observations, roughly 30%. Even remotely doesn't look like 3%, wtf? The most probable candidate is slot ratio, which was considered to be (3 + 5 + 2) / (3 + 5 + 2) = 1. Assuming that rig slots are taken as empty slots: (3 + 5 + 2) / (3 + 5 + 2 + 3) = 0.77. Taking into consideration average rack temperature of 97, we can convert it to the chance of not inflicting damage to module: 1 - 0.77 * 0.97 = 25.3%, closer to our results. To check this assumption, I've taken other edge-case: module with no rig slots, welcome the Reaper - fitted with 2 t2 280mm arty, cap rech t2 and t2 MAPC. With such amount of slots it's barely possible to raise rack temperature up to 95% and leave enough time for measurement cycles, so i started from 90%.
Kadesh Priestess
New Order Outreach Division
CODE.
#3 - 2011-11-10 18:47:01 UTC  |  Edited by: Kadesh Priestess
Quote:
Experiment 5:
Run 1: - - - - - - - - - - - - - - - - - - - 0 - - - - - - -; 0: 1, -: 26
Run 2: - - - - - - - - - - - - - - - - - - - -; 0: 0, -: 20
Legend: '0' - overheated module isn't damaged, '-' - overheated module is damaged

1 out of 47, or approximately 2%, i thought that it's enough to prove that numbers are not pure luck and stopped experiment. This proves that rigslots act as heatsink, regardless of their state - you can install rigs there or keep them empty. But what about subsystems?

First off, testing if installed subsystems act as modules, i.e. increase chance of modules to be damaged. Taking 2 ships with the same sum of hi-med-low-rig slots: cynabal and tengu (CPU, CapReg, Amplif, Covert, Null) and other related parameters (heat generation multiplier is the same for both), fitting mwd on both and checking how much cycles it will runt before finishing 5th damaged cycle (on tengu 5th cycle doesn't break mwd due to hull bonus).

Quote:
Experiment 6:
Cynabal + MWD: 64 49 76 110 101 (80 avg)
Tengu + MWD: 146 59 67 64 131 (93.4 avg)
Cynabal + MWD + 5 t1 small nosferatus: 17 11 17 (15 avg)
Tengu + MWD + 5 t1 small nosferatus: 15 12 12 (13 avg)

As we can see, subsysytems are not taken into account as online modules. Cynabal's slot ratio is 1/18, tengu's could be either 1/18 or 1/23 or 6/23. 3rd isn't even remotely close to the results we got (otherwise tengu with just mwd suurvived ~5 times less mwd cycle than Cynabal), so we need to check first two. This will be done the same way we checked rigs (experiment 4 and 5), with more reliance on statistics (because there's no ship with susbsystems, but no rig slots). Got Tengu (Dissolution, Coolant, Amplif, Ejection Bay, Fuel Cat), fit it up to the roof (5 small t2 nosferatus, 6 t2 invuls, 5 t2 cap relays, 2 t2 ccc, 1 t1 ccc. Measurements start after temperature reaches 95% per EVE UI. As experiment is long, most of its time temperature is almost at 100, so we can purely ignore this factor, considering it as equal to one.

Quote:
Experiment 7:
Run 1: - - - - - - - - - - - - - - 0 - - - - 0 - - - - - 0 - - - - - - - - - - - - - - - - 0 0 - - - 0 -; 0: 6, -: 41
Run 2: - - - - - - - - - - - - - - 0 - - - - - - - - - 0 - - 0 0 0 0 - 0 - - - - - - - - - - - - 0 - - - - - 0 0 - - - - - - -; 0: 10, -: 50
Run 3: - - - - - - - - - 0 0 - - - - - - - - - 0 - - 0 - - - - 0 - - - - 0 - - - - - - - 0 0 - - - - - - - - -; 0: 8, -: 44
Legend: '0' - overheated module isn't damaged, '-' - overheated module is damaged

As result, we see 24 non-damaged cycles out of 159 total, or 15%. Doesn't look like 1 - (5 + 6 + 5) / (5 + 6 + 5 + 3 + 5) (33%), ye? Let's suppose subsystems and subsystem slots are completely ignored - 1 - (5 + 6 + 5) / (5 + 6 + 5 + 3) = 15.79%. Obvoiusly hit, subsystems are not taken into account.

Now, back to the heat gain/dissipation. As i already had formulae from Tuxford's video (+graphs), goonwiki and minorly modified version by mr_depth @ eve-ru, with added references to actual item attributes instead of some stupid 'constants'. First, double-checked if heat gain depends linearly on number of overloaded modules. Tengu (Dissolution, Coolant, Amplif, Ejection Bay, Fuel Cat), 6 t2 photon scattering fields, overloading 1-2-3-4-5-6 of them until rack temperature hits 99% according to EVE UI, writing down time it takes to.

Quote:
Experiment 8:
1: 279.793050051 (base)
2: 140.444602966 (1.99 ratio)
3: 93.8117558956 (2.98 ratio)
4: 69.827504158 (4 ratio)
5: 55.2678010464 (5.06 ratio)
6: 46.3448960781 (6.03 ratio)

Awesome, so dependence is linear. Now, let's check what affects temperature gain on per-module basis. We have just one candidate - it's heatAbsorbtionRateModifier (other heat-related attribute is already used). Heating rack up to 90%, on tengu (Dissolution, Coolant, Amplif, Ejection Bay, Fuel Cat), writing down time.

Quote:
Experiment 9:
tech1 10MN MWD (0.04, 10 sec cycle): 75.4861559868
tech2 invul (0.02, 10 sec cycle): 150.156818867
tech1 invul (0.01, 10 sec cycle): 301.53029108
т2 MSB + 2 6% cap implants to keep cap alive long enough (0.02, 3 sec cycle, 2.55 sec overloaded): 150.825686932

According to heat indicator and experiment results we conclude that it doesn't depend on cycle length (so it's not discrete, per-cycle process), just on heatAbsorbtionRateModifier value, linearly. Also, ships have heatGenerationMultiplier attribute, which reduces as ship gets bigger - does it affect heat gain? Taking t1 invul, applying it (overheated) to different ship classes.
Kadesh Priestess
New Order Outreach Division
CODE.
#4 - 2011-11-10 18:47:50 UTC  |  Edited by: Kadesh Priestess
Quote:
Experiment 10:
Tengu from experiment 9 (0.75): 301.53029108
Merlin (1.0) 226.738855124

As we can see from its name and results, it's plain multiplier. Now, let's check which heat-related attributes are not involved yet. These are heatCapacityHi/Med/Low, which are always equal to 100. Final heat formula is:

H(t)=heatCapacity/100-e^(-t*heatGenerationMultiplier*sum(heatAbsorbtionRateModifier))

Checking it against already conducted experiments.

Quote:
Experiment 11:
Experiment 10, merlin: 100÷100−e^(−226.738855124×1.0×0.01) = 0.8964 (were heating up to 90)
Experiment 9, tengu with t2 invul: 100÷100−e^(−150.156818867×0.75×0.02) = 0.8948 (were heating up to 90)
Experiment 9, tengu with MWD: 100÷100−e^(−75.4861559868×0.75×0.04) = 0.8961 (were heating up to 90)
Experiment 8, 6 photons: 100÷100−e^(−46.3448960781×0.75×0.02×6) = 0.9845 (were heating up to 99)

Values are lower as EVE UI rounds floats to integers, formula itself is absolutely fine. Now, heat dissipation formula:

H(t) = H(0)*e^(-t*heatDissipationRate)

Measuring how long it will take for heat to drop from 90 to 20 on different ship classes, to see if it depends from some ship attributes besides heatDissipationRate:

Quote:
Experiment 12:
Merlin: 150.6175639629364; 0.9×e^(−150.6175639629364×0.01) = 0.1996 чек
Tengu: 150.68784713745117; 0.9×e^(−150.68784713745117×0.01) = 0.1994 чек

As we can see, formula works here just fine.

Now, several additional tests. getting a ship which excludes the most factors - reaper witth 2 x ts 125mm ACs, catalyzed MWD and t2 MAPC. Measuring mwd damaged status up to the 5th cycle or up to its death.

Quote:
Experiment 13:
1: 0 0 0 - -
2: 0 0 0 - -
3: - - -
4: 0 - - -
5: 0 0 - - -
6: 0 - - 0 -
7: - - 0 0 -
8: 0 0 - 0 -
9: - - -
10: 0 0 - 0 -
11: 0 - 0 - 0
12: 0 - - -
13: 0 - - -
14: 0 - - -
15: - 0 - -
16: - 0 - 0 -
17: 0 0 0 0 -
18: 0 - - -
19: - 0 - -
20: - - -
21: - 0 0 - -
22: 0 0 - - -
23: - - -
24: 0 - - -
25: 0 - - -
Legend: '0' - overheated module isn't damaged, '-' - overheated module is damaged

Total: 1st cycle - 9/25 = 36%, 2nd 14/25 = 56%, 3rd 19/25 = 76%, 4th 15/21 = 71%, 5th 11/12 = 91%. According to heat gain formula mentioned above we're getting 33%, 55%, 70%, 80%, 86% chance of damage infliction accordingly. Some values are not close, but i'm pretty sure in this part, so won't conduct additional runs to reduce statistical error.

Now, checking how modules damage their rack neighbours. Remaining attribute, which can deal with it is heatAttenuationHi/Med/Low, so let's base off it, rather than nu,ber of slots. Also let's take non-typical ship - legion with 6 high slots (its heatAttenuationHi corresponds to 5 slots), fitted with dissolution, core multiplier, augmented plating, liquid crystals, chassis optimization + 6 gatling pulses, 4 track computers, 6 heat sinks and energy aerator (all t2). gatling are ideal for their lack of reload, rapid fire rate (1 volley is roughly one observation, when heat is up, which slims potential error), and small damage steps (to avoid 'overkill' when it comes to final blow, so i can go afk :P ). Shooting some fat celestial with leftmost laser until it burns out, then writing down damage state (percents) of whole top rack.

Quote:
Experiment 14:
1: 100 63.78 52.65 38.48 25.31 17.21
2: 100 76.95 51.64 33.41 24.3 22.3
3: 100 62.78 52.65 32.4 24.3 15.19
4: 100 74.93 49.61 34.43 20.25 19.24
5: 100 74.93 45.56 41.51 22.28 16.2
Avg: 100 70.67 50.42 36.05 23.29 18.03

Theoretical values - 0.71 (heatAttenuationHi) ^ distance are: 100 71 50.41 35.8 25.41 18.04. Headshot. Also this proves, that it depends on heatAttenuation, not on number of slots (on a side-note, looking at heatAttenuation of t3s we can say how much slots in each rack CCP saw when designed them).

Last experiment is to prove that damage infliction to other rack modules depends on slot ratio to the same extent, as damage infliction to self (which has already been proven). Taking off all mids, lows and rigs from legion, putting 5 lasers offline (except for the leftmost) and doing the same thing. Now i can AKF for a long time, yea.
Hungry Eyes
Imperial Academy
Amarr Empire
#5 - 2011-11-10 18:48:33 UTC
u serious?
Kadesh Priestess
New Order Outreach Division
CODE.
#6 - 2011-11-10 18:48:40 UTC  |  Edited by: Kadesh Priestess
Quote:
Experiment 15:
1: 100 76.95 59.74 32.4 28.35 20.25
2: 100 85.05 54.68 38.48 22.28 14.18
3: 100 65.81 37.46 32.4 21.26 15.19
Avg: 100 75.94 50.63 34.43 23.94 16.54

Close to previous experiment numbers. If damage infliction to neighbours wouldn't depend on slot ratio, they'd burn faster than overheated module, thus such assumption is not valid.

This wall of text was written so that anyone could check any step and fix any aspect of formula. Also it shows some potentially weak spots in deriving process (primarily due to lack of proper amount of test runs), though i don't think these weak spots may be proven wrong as amount of gathered data increases.

Hungry Eyes wrote:
u serious?
Yes, dude. I've been looking for exact data regarding heat for 2 years, think someone else would like to have it too. Obviously, it's not you.
Kahz Niverrah
Viziam
Amarr Empire
#7 - 2011-11-10 19:18:44 UTC
You have too much time.

I don't always post on the forums, but when I do, I post with my main.

laffbot
Sebiestor Tribe
Minmatar Republic
#8 - 2011-11-10 19:49:51 UTC
great work but,

china wants its wall back
Emily Poast
The Whipping Post
#9 - 2011-11-11 04:28:53 UTC
You should post this on the wiki. You are only going to get trolled here.

Its damn fine work. I always thought that the 'damage to its neighbors' thing was some wives tale. I guess it isnt. ;)
Goodgodyourface
Republic Military School
Minmatar Republic
#10 - 2011-11-11 04:37:38 UTC
Overloading makes sense?

... Nah, I'll just stick with "It's magic"
Roosterton
Sebiestor Tribe
Minmatar Republic
#11 - 2011-11-11 05:19:10 UTC
I just click the glowing green buttons and turn them off when the red circle gets large.
Goodgodyourface
Republic Military School
Minmatar Republic
#12 - 2011-11-11 05:27:30 UTC
Roosterton wrote:
I just click the glowing green buttons and turn them off when the red circle gets large.


Indeed.
Kadesh Priestess
New Order Outreach Division
CODE.
#13 - 2011-11-11 08:57:46 UTC
Emily Poast wrote:
You should post this on the wiki. You are only going to get trolled here.
Expected as much, i understand that target audience is just 0.1% of EVE players, if not less. As for the wiki - bad place for experiments backlog, so i decided to post it here. If nobody makes any corrections next few days - i'll move post with formulae to the wiki.
Elistea
BLUE Regiment.
#14 - 2011-11-11 10:03:38 UTC
Holy **** i feel like way back at math lesson. Lots of letters pretending to be numbers and nothing i understand.

Ill be blunt and i just say that some mods are overheating way too fast.
DarkAegix
Acetech Systems
#15 - 2011-11-11 10:52:42 UTC
I didn't read any of it, but I liked your posts for effort.
Stick this on the wiki.
ChromeStriker
Out of Focus
Odin's Call
#16 - 2011-11-11 10:57:46 UTC
Holy brain fart batman i think shes got it!!!

the magic that is overheat.... i have read your, essay, and it makes sense to me. im looking through it but as of now it runs true :D

No Worries

Naso Gomez
#17 - 2011-11-11 11:36:55 UTC  |  Edited by: Naso Gomez
Good job, it makes sense to me, although I will most likely never remember this on the fly. I will just end up overloading my racks until the modals are burnt out.

Guessing you will be using the heat damage formulas for the Eos engine, pretty sweet.