Talk:Server tick

Issue

"For example, a 1.2-second locking time will be rounded up to a 2 server ticks, thus 2 seconds."

I understand this gets the point across, however locking as the example is misleading and perhaps a different example which fully obeys the tic rule is a better choice to avoid future misconception about locking.

Why?

While a lock does occur on tic, the client's request to lock is ms accurate and the lock is scheduled for the next valid tic. In the example a lock can be 1.2s through 2.0s not strictly rounded up.

Why does that matter?

Fitting sensor strength, unlike align time, does not hit 'break points' of rounded tics, but rather provides useful buffering for reaction time and latency.

How (for reference):

So if i can lock a specific target in 1.400s then if I attempt a lock any time between Tic 0 (T0) and T0+0.600s I will lock the target on T2. If I attempt a lock at T0+0.700s my lock will be on T3.

Suggestion:

Rather than explain any of that a better example should be used to covey the point without instilling a misconception; alignment perhaps? Who's activation and execution are on tic time and do follow the rules.

Solidware (talk) 17:37, 5 April 2023 (UTC)