Difference between revisions of "Talk:Server tick"
(Created page with "==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 ex...") |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | ==Issue== | + | == Issue == |
"For example, a 1.2-second locking time will be rounded up to a 2 server ticks, thus 2 seconds." | "For example, a 1.2-second locking time will be rounded up to a 2 server ticks, thus 2 seconds." | ||
| Line 5: | Line 5: | ||
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. | 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?== | + | === 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. | 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?== | + | === 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. | 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):== | + | === 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. | 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:== | + | === Suggestion: === |
| − | Rather than explain any of that a better example should be used to covey the point without instilling a misconception; | + | 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. |
[[User:Solidware|Solidware]] ([[User talk:Solidware|talk]]) 17:37, 5 April 2023 (UTC) | [[User:Solidware|Solidware]] ([[User talk:Solidware|talk]]) 17:37, 5 April 2023 (UTC) | ||
Latest revision as of 19:23, 5 April 2023
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.
