Master doc on offsets in osu!

offsets.md

Last updated: 2021-07-27

How offsets and latency work

This is the pictorial representation that I'll use to explain how a player's timings could come about:

            hitobject     track latency    beat (track)
               vvv             vvv             vvv
Track: ---------H---T---------H---T---------H---T---------H---T-------------
User:  -------------K---S---------K---S---------K---S---------K---S---------
                   ^^^             ^^^             ^^^
                key press   hitsound latency     hitsound  

The hitsound latency is non-adjustable. It represents some latency that is incurred by your system. In a perfect world, this latency would be so low that you'll hear the hitsound in the same instant that you press the key. In practice this is not always the case but it is typically consistent.
We'll also say that the key press timing is non-adjustable. It typically isn't because it's dependent on the other variables which we'll get to. So the entire "User" timeline in the graph is non adjustable.

The track latency however is adjustable. It's a combination of both latency incurred by your system (causing it to skew positive, or further to the right in the timeline), and your universal offset. How you respond to this situation is dependent on you as a person - you want to achieve a balance of all variables that works for you.

Let's go over a few examples. Note that these may not encompass all users nor be the final solution for all your gaming problems - it's intended to help you understand how offsets should be used.

1. If you're dependent on only the track and hitsounds to maintain rhythm/timing, then you'll tend to hit further hitobjects EARLIER.

Assume a track latency of 0, and imagine how someone might shift their timing as dictated by the hitsound latency. The timing sequence will look something like this:

Track: ---------HT---------HT---------HT---------HT---------HT-------
User:  ----------K---S--K---S------K---S------K---S------K---S------

So the user hit the first hitobject perfectly, noticed that their timing was off (audibly), and shifted their keypresses earlier such that the hitsounds match the track (low T-S latency). This results in a negative hit error.

To compensate, this user may want to adjust the track latency positively (positive-UO), so that the track is delayed a bit and their keypresses better match the hitobject timings, but not so much that the track is completely off from the beatmap:

Track: ---------H--T---------H--T---------H--T---------H--T---------H--T-------
User: -------------K---S----K---S--------K---S--------K---S--------K---S------

While they incurred a bit of H-K latency at the start, the overall H-K latency is now quite low and their hitsounds are still perfectly timed.

2. If you're dependent on mostly visuals, then you'll tend to hit further hitobjects LATER.

This one's a little harder to explain. Assume a track latency of 0, and imagine how someone might shift their timing if they first want to physically see the approach circle touch the hitobject.

Track: ---------HT---------HT---------HT---------HT---------HT---------HT-------
User:  ---------K---S--------K---S---------K---S----K---S------K---S------K---S-------

There are two effects going on here:

1. As a human being, there's some latency beween seeing something and pressing the key. This latency heightens as you become more dependent on this effect, and due to cascading reasons outside of the scope of this document.
2. In my experience, people aren't 100% dependent on visuals. When they hear hitsounds being so off, it's instinctual to want to press earlier as per (1) even if it isn't the primary timing mechanism.

To compensate, this user may want to adjust the track latency negatively (negative-UO), so that an increase in T-S latency has a greater impact on their gameplay:

Track: -----T---H------T---H------T---H------T---H------T---H------T---H--------
User:  ---------K---S----K---S--------K---S----K---S--------K---S-----K---S-------

They will still be quite erratic, but the idea is to reach a balance where both T-S and H-K latencies are low and correspond in some way to each other (for example, even if T-S latency is high, maybe H-S latency is low to compensate even though it's a weaker interaction).

"Universal offset" vs "local offset"

"Universal offset" (UO) is opposite to "local offset" (LO).

Universal offset can be thought of as acting upon the track itself - a positive-UO pushes beats in the song later. Local offset can be thought of as acting upon the hitobjects - a positive-LO pushes hitobjects in the song later. In effect, these are the negatives of the other.

If you notice that your hit error is -30ms - +10ms you have two ways to adjust this:

1. If this sort of offset is consistent then you may have PC timing issues. A UO of +10ms can be used to fix this. The general formula for this is: (earlyMs - lateMs) / 2 = adjustMs.
   • Example: (30 - 10) / 2 = +10.
2. If this offset is caused by other factors (such as described above), a LO of -10ms can be used to fix this. The general formula for this is (lateMs - earlyMs) / 2 = adjustMs.
   • Example: (10 - 30) / 2 = -10.

For completeness, I'll also mention the existence of a hidden value known as the "online offset". This is used specifically when the beatmap is timed incorrectly, and can only be set by admins/NAT. It works in the same way as the local offset.