I know, hence my question. Because whatever the rate has changed to needs to somewhat align with the (assumed) internal update rate. So 2.57, instead of e.g. 2.6, really only makes sense, if the update rate higher than 10 Hz.
But I do not think that there is something such as 4.5 ticks, so it cannot work this way.
Edit: But other than that it makes sense.
Taking this as example: If it’s 2.57s then it’s 7.71 ticks, so 5/7.71 = 0.6485 hp/tick
In this case you would get 0.6485 for 7 tics and then 0.4605 in the 8th tick.
That is what I meant with alignment: The leech rate needs to align with tick rate.
So the rate of 2.57 is rather 2.66 (8 * 1/3) assuming a tick rate of 3 HZ.
It would alternate in that case. So the first second has 3 ticks the half second has 1 or 2 ticks. If it’s 1 it’s 4 total, if it’s 2 it’s 5 total.
5/4 = 1.25
5/5 = 1
Add them together 2.25 health per tick
But since it’s one or the other you take the average and divide by two: 1.125 health per tick.
Which is very close to 1.111 for 4.5 ticks 0.014 off is well within a margin of error for napkin math.
The leech rate doesn’t need to align perfectly because you’re simply calculating how much health per tick the player receives. Again, if the leech rate is 2.57s, that’s 6 full ticks, +1 tick for sure (3 * 0.57 = 1.71) so now we have the 0.71 to deal with. We either get the tick or we don’t depending on how it lines up. So 7 ticks or 8 ticks depending on timing.
5/7 = 0.71 hp/tick
5/8 = 0.63 hp/tick
1.34/2 = 0.67 hp/tick *3 = 2.01 hp/s
Edit: which again is very close to my napkin math from my first post.
Edit 2: thinking about the margin of error. It’s because it’s not a perfect 50/50 split of “you get it, or you don’t” but it all averages out. There’s a 71% chance you get the 8th tick, and a 29% chance you don’t. I could calculate all of that, but the results wouldn’t change that much considering how small the numbers we’re talking about actually are.
In a weird twist of how this works out though, you actually WANT less ticks. Because the heals are larger per tick. So I believe the 1.945 from my first post is more accurate if you take the chances of getting the 8th tick into account.
I was busily editing my post so probably did not see that.
Because my solution would have been 7 ticks á 0.6485 and the missing 0.4605 in the 8th tick.
But all this is guesswork, right? Or do you have any sources?
Just some ideas how one could run an experiment to gather data that might answer your questions.
Set your health regen to 0 with one of the uniques.
Drain your hp pool with “missing health as ward items” where the training dummies are.
Start video recording.
Unequip the “missing health as ward item”.
Smack the dummy.
Change gear and passives to change parameters like lifeleech amount and rate.
Repeat.
Gather samples with various %values and leech rate.
Watch the capture frame by frame and write down how many frames go by until you see a change in your HP, and how high the HP went up. Write down the damage of the hit that triggered the leech and the appropriate stats.
Does the leech rate affect the number of frames between ticks? Or does it just let it tick higher in fewer total ticks?
Dunno, last time I did something with video capturing was in - what can be considered almost stone age - 2007 or so. I used Fraps back then.
My old rig certainly can’t run LE and some video capturing software.
But analysing video footage might not reveal how the maths works on the server, since it is also dependent on the UI actualisation. Multiple server-side ticks might be merged into one visual update …
HPS meter would probably not give you the fine granuality you need to find out what you are looking for, since it always averages over a certain timeframe.
It’s mostly guesswork based on how similar systems work in other games. You could “lose” dot/hot ticks if the timings didn’t match up right. So the best way to calculate an effective dps/hps was to take the raw value over the number of ticks in the duration, and then multiply that value by the number of ticks per second to get a rough value. (i.e. 3 ticks per second, 5 health over 2.57 seconds = 5 health over 7.71 ticks = 0.6485 health per tick at 3 ticks per second = 1.946 hps. It’s a “close enough” value. Even if you can’t realistically have 0.71 ticks. You could even cut out the middle man of “health per tick” (unless you wanted to calculate different durations) and just divide the raw health over the duration.)
It’s not an exact science because it’s all behind the scenes values and “close enough” is usually “good enough”.
Without the developers staring the exact line of code for how leech is calculated it’s effectively impossible to calculate an exact value.