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

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

EVE General Discussion

 
  • Topic is locked indefinitely.
 

Rate of fire and server ticks [Solved]

Author
Xcom
Eclipse Strike Unit
Jump On Contact..
#1 - 2016-12-12 20:18:51 UTC  |  Edited by: Xcom
I am unsure what part of this forum it belongs to, please move it to the correct part if its in the wrong place.

How exactly does the DPS of weapons coincide with the server ticks? server tick is 1 second but some weapons have more accurate cycle timers. A weapon of 1.2 second from what rumours are floating around takes 2 seconds to cycle as everything needs to be rounded to the nearest second. Is this true? and if yes what exactly does this imply. Does the weapon have as much DPS as if the rate of fire was 2 seconds long? or it only impacts the off cycle when the weapon stops firing on a target.

Just to break the questions down.

1. Does weapon timers get rounded up to the nearest server tick? or how does it work?
2. How does the DPS get calculated. Does it get rounded to the nearest server tick? (weapon damage of 1.1 second is equal to 1.9 as both get rounded to 2 seconds)
3. Does the weapon timer start on a server tick or when you click the button? (i.e. the client sends the time of trigger to the server)
4. Does it matter to have 2.01 sec weapon timer or does it really matter to reduce to 1.99 sec with implants. When does it matter to have less then 2 seconds and why are people giving tips regarding this?
5. How is this influenced by tidi?
6. How is multiple cycle times calculated if a weapon cycle time is 1.5 seconds and it cycles 2 times. Does it count as 3 shoots, 1 per each second? Or the damage is calculated on the nearest server tick and applied on that tick? For example first damage is calculated to 2 seconds and the 2nd damage on the 3rd second.

If anyone understands the weapon calculations please link to some info or give some concrete proofs.
Brokk Witgenstein
Sebiestor Tribe
Minmatar Republic
#2 - 2016-12-12 20:20:02 UTC
Server ticks matter for missile flight time (yes, you Caracal) and reloading-- for normal firing rates, things works as you'd expect.
SurrenderMonkey
State Protectorate
Caldari State
#3 - 2016-12-12 20:20:36 UTC  |  Edited by: SurrenderMonkey
Client updates happen on the tick, but the actual shots happen in real time. Sub-second ROF will occasionally see two shots reported in a tick.

"Help, I'm bored with missions!"

http://swiftandbitter.com/eve/wtd/

Neuntausend
Republic Military School
Minmatar Republic
#4 - 2016-12-12 20:31:51 UTC
The server ticks only decide when your guns turn on or off, but once they are cycling, they are cycling. As far as I know, each tick the server checks if and how many shots have been fired, and applies damage accordingly. So, with a ROF of 1.4s for example, you'd get a hit on the first, second, third, fifth and seventh tick. With a ROF of 0.7s you'd get two hits on the fist, one on the second, two on the third, one on the fourth and so on. There's no need to align your ROF with the tick time.
Xcom
Eclipse Strike Unit
Jump On Contact..
#5 - 2016-12-12 20:32:07 UTC  |  Edited by: Xcom
Does that mean that the client/server is only synchronized ones every second? If so it means that its a huge factor to get weapons under the integer roundings. It sounds a bit crude to synch the client with huge ticks like that. Isn't it possible that the client is updated with the server info ones every second? Sort of get the end time of modules instead of boolean stop and start values.

Edit: Weapons have a forced cycle time. Does that mean weapons only stop firing as often as the server ticks?
Neuntausend
Republic Military School
Minmatar Republic
#6 - 2016-12-12 20:45:13 UTC
The server only calculates new movement vectors, positions, hit points, fleet boni and about everything else every second. The reason for this is, that it would take too much processing power to do the same every 50 miliseconds for 5000 players in a system. Case in point - this rate slows down to once every 10 seconds for larger battles. ;)

Therefore, the client also just gets updates every second, as there's nothing new inbetween anyway. The client then just interpolates and smoothes things out so it doesn't look choppy.

Let's say you turn on your weapon inbetween two ticks, then the command will get processed on the next tick - so worst case 999 miliseconds later. That's why interceptors with an align time below 2 seconds are technically uncatchable: The interceptor decloaks on the gate and starts aligning. You start locking it - one tick - you activate your disruptor - two ticks.

For the ROF it really doesn't matter (much), though, unless you constantly keep switching your weapons on and off.
SurrenderMonkey
State Protectorate
Caldari State
#7 - 2016-12-12 20:53:30 UTC  |  Edited by: SurrenderMonkey
Neuntausend wrote:
The server only calculates new movement vectors, positions, hit points, fleet boni and about everything else every second. The reason for this is, that it would take too much processing power to do the same every 50 miliseconds for 5000 players in a system. Case in point - this rate slows down to once every 10 seconds for larger battles. ;)

Therefore, the client also just gets updates every second, as there's nothing new inbetween anyway. The client then just interpolates and smoothes things out so it doesn't look choppy.

Let's say you turn on your weapon inbetween two ticks, then the command will get processed on the next tick - so worst case 999 miliseconds later. That's why interceptors with an align time below 2 seconds are technically uncatchable: The interceptor decloaks on the gate and starts aligning. You start locking it - one tick - you activate your disruptor - two ticks.

For the ROF it really doesn't matter (much), though, unless you constantly keep switching your weapons on and off.


IIRC, under-2-second-align is technically catchable. There have been some documents detailing why, but the TL;DR is basically that some-things-actually-happen-intratick while others happen at the tick. Locking really begins at commandissuetime+latency, locking completes at commandissuetime+latency+locktime, etc. Meanwhile, actual warp entry happens AT the tick.

It does require very high scan res, good reflexes/buttonmashing, and a very low ping.

"Help, I'm bored with missions!"

http://swiftandbitter.com/eve/wtd/

Xcom
Eclipse Strike Unit
Jump On Contact..
#8 - 2016-12-12 21:01:49 UTC  |  Edited by: Xcom
So in general. The weapon timer isn't updated on the client till the end of its cycle time + the additional nearest server tick delay. In general it means your better of with a weapon with 3.99 seconds rather then a weapon with 4.01 seconds cycle in that case. Or am I incorrect to assume this? Most PvE setups use single round attacks on most squishy targets and in pvp every millisecond counts when swapping targets. Or is it that weapons stop firing the exact time they are supposed to with proper server synchronizations? (exact weapon expiration sent to client the tick before)

I wish there were some proper detailing info regarding this cause in some instances it really does matter what type of implant or module you can swap out to get that little edge.
Neuntausend
Republic Military School
Minmatar Republic
#9 - 2016-12-12 21:06:09 UTC  |  Edited by: Neuntausend
Quote:
IIRC, under-2-second-align is technically catchable. There have been some documents detailing why, but the TL;DR is basically that some-things-actually-happen-intratick while others happen at the tick. Locking really begins at commandissuetime+latency, locking completes at commandissuetime+latency+locktime, etc. Meanwhile, actual warp entry happens AT the tick.
It does require very high scan res, good reflexes/buttonmashing, and a very low ping.


That would be news to me, but who knows? This should be easy to prove in TiDi, though. The higher the TiDi, the less latency and reflexes matter. If the lock really registers between ticks, then that should be well visible in a tidied system. Is there a permanently TiDied system on Sisi?
Soel Reit
The Scope
Gallente Federation
#10 - 2016-12-12 21:17:14 UTC
Brokk Witgenstein
Sebiestor Tribe
Minmatar Republic
#11 - 2016-12-12 21:21:57 UTC
I don't see how this matters. If it's an enemy you one-shot and it really bugs you to lose out on .5 sec, ungroup your guns. If you don't one-shot, then it doesn't matter at all.

In what situation would a weapon with a 3.9 cycle time be different than a 4.1 one?
SurrenderMonkey
State Protectorate
Caldari State
#12 - 2016-12-12 21:25:14 UTC  |  Edited by: SurrenderMonkey
Brokk Witgenstein wrote:
I don't see how this matters. If it's an enemy you one-shot and it really bugs you to lose out on .5 sec, ungroup your guns. If you don't one-shot, then it doesn't matter at all.

In what situation would a weapon with a 3.9 cycle time be different than a 4.1 one?


Mostly this.

It really doesn't matter. TBH, this is a pretty misguided min-maxing effort.

Eve is really NOT a milliseconds game.

"Help, I'm bored with missions!"

http://swiftandbitter.com/eve/wtd/

Neuntausend
Republic Military School
Minmatar Republic
#13 - 2016-12-12 21:29:44 UTC  |  Edited by: Neuntausend
Xcom wrote:
So in general. The weapon timer isn't updated on the client till the end of its cycle time + the additional nearest server tick delay. In general it means your better of with a weapon with 3.99 seconds rather then a weapon with 4.01 seconds cycle in that case. Or am I incorrect to assume this? Most PvE setups use single round attacks on most squishy targets and in pvp every millisecond counts when swapping targets. Or is it that weapons stop firing the exact time they are supposed to with proper server synchronizations? (exact weapon expiration sent to client the tick before)

Weapons turn off on the next tick after their red cycle has ended. So, if your last shot is inbetween two ticks, the shot will register on the next one and your weapon will turn off. That's why the cycle usually overshoots a bit when you redcycle a module.

To a degree, yes, the 4.01 ROF gun has it worse than the 3.99 ROF.

With a ROF of 3.99s you'd get your first shot in after 4 seconds, whereas with 4.01 it would take 5 seconds to register, from how I understand it. That's a difference of 10ms or 0.25% for the ROF 3.99, and 990ms or 24.68% for the 4.01 - quite harsh! But the longer it takes, the more this evens out:

Let's say you fire a ROF 3.99 Weapon and a ROF 4.01 Weapon for 5 cycles each. On the ROF 3.99 it would take 20 seconds when it should take 19.95, and with ROF 4.01 it would take 21 seconds when it should take 20.05. So, you "lose" 50 miliseconds or 0.25% on the ROF 3.99 and 950 miliseconds or 4.7% on the ROF 4.01. For 10 cycles it would take the ROF 3.99 40 seconds, and on the ROF 4.01 it would take 41 seconds, when it *should* take 39.9 seconds and 40.1 seconds respectively. That's 100ms or 0.25% for the ROF 3.99 and 2.24% for the ROF 4.01. The longer the fight goes, the less noticeable it becomes.
Xcom
Eclipse Strike Unit
Jump On Contact..
#14 - 2016-12-12 22:03:55 UTC

This was very interesting. Thank you!
Xcom
Eclipse Strike Unit
Jump On Contact..
#15 - 2016-12-12 22:48:36 UTC  |  Edited by: Xcom
According to the thread posted above it shows that dps is applied on the moment of server receiving the click event. It proves that an 3.99 rof turret and a 4.01 rof have no advantage when it comes to tick mechanics. They both start firing the second you send the server the command and based on your timing they will stop firing when the next server tick sends the update.

I just never got the part about gun cycle mechanic though. Why is it guns have to cycle off before you can change targets? Wish they behaved like drones where any target + attack command would just start attacking that target.
SurrenderMonkey
State Protectorate
Caldari State
#16 - 2016-12-12 23:26:58 UTC


Yeah, that's it. I was going to experiment with it when I got home, but singularity gives me the alpha login restriction no matter how many time I /omega. Roll

"Help, I'm bored with missions!"

http://swiftandbitter.com/eve/wtd/