Difference between revisions of "Server tick"

From EVE University Wiki
Jump to: navigation, search
(categorization)
m (Link maintenance. Remove external links, the only link went dead.)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Introduction ==
+
"'''Server tick'''" is a term used to describe the rate at which the EVE Online client and server communicate. The goal of the server is for a tick to run exactly once per second, or at 1 hertz. This relatively slow tick rate creates sub-second gaps between the player's orders to the client and order activations on the server.
  
Server tick is a term used to describe the 1 Hertz client to server functionality in EVE Online. The goal of the server is for a server tick to run exactly once per second. Thus creating little sub-second gaps between the player's order to the client and the server activation.
+
Almost every action is restricted by server ticks. The timings of many mechanics in EVE are rounded up to the full second. For example, a 1.2-second locking time will be rounded up to a 2 server ticks, thus 2 seconds.  
 
 
It also creates a rounded up mechanics to full second activation. For example, a 1.2s locking time will be rounded up to a 2 server ticks, thus 2 seconds.
 
 
 
Almost every action is under the restriction of this mechanic.
 
  
 
== Mechanics ==
 
== Mechanics ==
 +
The server tick has some unique limitations: it can’t do anything that would require directly talking to most of the database servers, since those can have long lags. A typical server node handles hundreds of systems, so even though there's a tick every second for each grid, it might only have one hundredth of a second or less to do all the work for the tick for a single grid. That's not enough time to talk to a database!
  
The server tick has some unique limitations to it: It can’t do anything that would require directly talking to most of the database servers, since those can have long lags. (A typical server node handles hundreds of systems, so even though there's a tick every second for each grid, it might only have 1/100th of a second or less to do all the work for the tick for a single grid. That's not enough time to talk to a database!)
+
Most heavy lifting in the code is therefore done by queuing some work to be done on other threads; when that work is finished, the results are reported at the next tick.
 
 
So most heavy lifting in the code is done by queuing some work to be done on other threads; when that task is finished, the results are reported at the next tick.
 
  
Although, the client will usually process the commands immediately, showing the player the action is currently taking place, but won't be actually effective towards the server itself until the next tick.
+
However, the client will usually process commands immediately, showing the player the action is currently taking place. Actions won't be actually effective at the server itself until the next tick.
  
Some tasks are completely disassociated from the server tick and can happen at any time, they are subject only to the latency between the client and the server.  
+
Some tasks are completely disassociated from the server tick and can happen at any time, being subject only to the latency between the client and the server.  
  
=== Examples ===
+
== Examples ==
 +
* If you’re trying to jump through gate, EVE will mark you as "jumping through the gate" the instant that it receives the message, and will send back an acknowledgement right away that you’re jumping. However, everyone else on the grid won’t know that you’ve started jumping until the next server tick.
 +
* If you activate a turret module, it’ll immediately calculate the damage, and immediately apply it to the target. It’ll send back a packet right away, telling you, "I activated this module for you."  However, you won’t receive information about how much damage was dealt until the next tick—and neither will the target. This means you can be dead for up to a second (or up to 10 seconds, in the case of severe [[time dilation]]) and not know it yet! This is also how EVE handles weapons that can fire more than once per tick: it simulates them properly, and then both shots appear on the next tick.
 +
* If you activate a warp scrambler, it’ll immediately tackle the target. But the "X has warp scrambled Y" global notification won’t appear until the next tick.
 +
* [https://web.archive.org/web/20210111174108/http://eve.501gu.de/misc/travelceptor_vs_instalocker.png This example] shows the two outcomes of a confrontation between an interceptor fitted for fast alignment and entry to warp ("Travelceptor") and a ship fitted to lock up and tackle targets rapidly ("Instalocker"), one of the most frequently encountered examples of server ticks interacting perceptibly with gameplay.
  
* If you’re trying to jump through gate, it will mark you as “jumping through the gate” the instant that it receives the message, and will send back an acknowledgement right away that you’re jumping. However, everyone else on the grid won’t know that you’ve started jumping until the next server tick.
+
== See also ==
* If you activate a turret module, it’ll immediately calculate the damage, and immediately apply it to the target. It’ll send back a packet right away, telling you, “I activated this module for you.”  However, you won’t receive information about how much damage was dealt until the next tick -- and neither will the target. Yes, this means you can be dead for up to a second (or up to 10 seconds, in the case of severe [[Time_Dilation|TiDi]]) and not know it yet! This is also how Eve handles weapons that can fire more than once per tick; it simulates them properly, and then both shots appear on the next tick.
+
* [[Gatecamps]] for the mechanics around gatecamping, a highly tick-influenced activity.
* If you activate a warp scrambler, it’ll immediately tackle the target.  But the “X has warp scrambled Y” global notification won’t appear until the next tick.
+
* [[Time dilation]] for the mechanics that revolve around Time Dilation in highly populated systems.
* [http://eve.501gu.de/misc/travelceptor_vs_instalocker.png This example] shows the two outcomes of a confrontation between a Travelceptor and an Instalocker, one of the most subsequent examples on daily basis server tick limitations.
 
  
=== See also ===
 
* [[Gatecamps]] For the mechanics around Gatecamping, a highly influenced server tick feature.
 
* [[Time_Dilation|Time Dilation]] For the mechanics that revolve around Time Dilation on highly populated systems and combats.
 
* [https://www.themittani.com/features/understanding-eve-online-server-tick TMC Article] on the server tick.
 
  
 
[[Category:Game mechanics]]
 
[[Category:Game mechanics]]

Latest revision as of 11:15, 11 February 2024

"Server tick" is a term used to describe the rate at which the EVE Online client and server communicate. The goal of the server is for a tick to run exactly once per second, or at 1 hertz. This relatively slow tick rate creates sub-second gaps between the player's orders to the client and order activations on the server.

Almost every action is restricted by server ticks. The timings of many mechanics in EVE are rounded up to the full second. For example, a 1.2-second locking time will be rounded up to a 2 server ticks, thus 2 seconds.

Mechanics

The server tick has some unique limitations: it can’t do anything that would require directly talking to most of the database servers, since those can have long lags. A typical server node handles hundreds of systems, so even though there's a tick every second for each grid, it might only have one hundredth of a second or less to do all the work for the tick for a single grid. That's not enough time to talk to a database!

Most heavy lifting in the code is therefore done by queuing some work to be done on other threads; when that work is finished, the results are reported at the next tick.

However, the client will usually process commands immediately, showing the player the action is currently taking place. Actions won't be actually effective at the server itself until the next tick.

Some tasks are completely disassociated from the server tick and can happen at any time, being subject only to the latency between the client and the server.

Examples

  • If you’re trying to jump through gate, EVE will mark you as "jumping through the gate" the instant that it receives the message, and will send back an acknowledgement right away that you’re jumping. However, everyone else on the grid won’t know that you’ve started jumping until the next server tick.
  • If you activate a turret module, it’ll immediately calculate the damage, and immediately apply it to the target. It’ll send back a packet right away, telling you, "I activated this module for you." However, you won’t receive information about how much damage was dealt until the next tick—and neither will the target. This means you can be dead for up to a second (or up to 10 seconds, in the case of severe time dilation) and not know it yet! This is also how EVE handles weapons that can fire more than once per tick: it simulates them properly, and then both shots appear on the next tick.
  • If you activate a warp scrambler, it’ll immediately tackle the target. But the "X has warp scrambled Y" global notification won’t appear until the next tick.
  • This example shows the two outcomes of a confrontation between an interceptor fitted for fast alignment and entry to warp ("Travelceptor") and a ship fitted to lock up and tackle targets rapidly ("Instalocker"), one of the most frequently encountered examples of server ticks interacting perceptibly with gameplay.

See also

  • Gatecamps for the mechanics around gatecamping, a highly tick-influenced activity.
  • Time dilation for the mechanics that revolve around Time Dilation in highly populated systems.