CS2 Demo Ticks: Tick to Time, and demo_gototick

Someone sends you a tick. It is a number like 61440, the demo it belongs to runs forty minutes, and on its own the number does not tell you where in those forty minutes to look.

The arithmetic is one division. Everything that wastes time sits either side of it.

The division, and the number you have to bring to it

A tick is a server simulation step, so the time it represents is the tick divided by how many of those steps happen per second.

seconds = tick / tickrate

Tick 6400 on a 64-tick demo is 100 seconds, which is 1:40 into the file. The same tick on a 128-tick demo is 50 seconds. Nothing in the number itself tells you which.

That is the whole reason a bare tick is a poor thing to paste into a chat window. It is precise and it is incomplete, and the missing half is the one people assume.

The tick rate belongs to the demo, not to the game

Valve's official matchmaking and Premier servers run at 64 tick, so most demos downloaded from the game itself are 64. CS:GO-era demos and a number of third-party and league servers are 128. Both kinds are still sitting in people's folders and still being linked in threads.

This is why demo parsers do not hardcode it. demoinfocs reads the tick rate out of the CSVCMsg_ServerInfo message and only falls back to the demo header when that is unavailable.² The rate is a fact about the recording, recovered from the recording.

If you are working from a file rather than a forum post, read it rather than guess. If you are working from a forum post, ask which it was. The tick calculator makes tick rate a visible input for exactly this reason: there is no correct default, only a common one.

A tick and a frame are not the same counter

This is the trap worth knowing about, because both numbers are large, both are called ticks in casual use, and neither looks wrong.

The server tick is the simulation step the match ran on. It is what demo_gototick takes and what event data is stamped with.

The frame is the index of a recorded frame inside the demo file. Parser documentation calls it the "demo-tick", and demoinfocs spells out why the distinction exists: the frame counter is separate precisely because demos often have a different tick rate than the game.²

So a number lifted out of a parser is only useful once you know which of the two it is. In the CS2 demo format the server tick is exposed as net_tick, surfaced by parsers as a per-tick game_time field.³ If the number came from a frame index instead, converting it with the server tick rate produces a timestamp that is confidently wrong, and wrong by a different amount in every demo.

demo_gototick, and the argument nobody expects

Open the console while a demo is playing and the jump is one line:

demo_gototick 6400

Valve documents the full form as demo_gototick <tick> [relative] [pause].¹ The relative argument, set to 1, makes the number an offset from where you already are. The pause argument, set to 1, stops playback the moment it arrives.

The catch is positional. To jump to an absolute tick and pause, you cannot skip the middle argument:

demo_gototick 6400 0 1

That 0 is not decoration. It is the relative flag being explicitly turned off so the pause flag lands in the third slot rather than the second. Write demo_gototick 6400 1 expecting a pause and you have instead asked for a jump 6400 ticks forward from the current position, which in a long demo is a plausible-looking result somewhere else entirely.

The same page documents demo_timescale <scale> for playback speed, which pairs well with pausing on arrival: land stopped, then run at a fraction of speed through the part you care about.¹

Jump early on purpose

The tick attached to an event is the tick the event resolved on. Arrive exactly there and you are watching the aftermath: the kill has happened, the player is already dead, and whatever you wanted to understand about the approach is behind you.

So subtract first. Five seconds is usually enough to see the rotation, the utility and the duel that produced the number. At 64 tick that is 320 ticks; at 128 it is 640. The lead-in is the second place where the tick rate matters, and a wrong one is harder to catch here, because a jump that lands five seconds off still lands somewhere plausible.

One edge worth handling: subtracting a lead-in from a tick near the start of the demo can produce a negative number. There is no tick before zero, so clamp it there rather than pasting a negative into the console.

Round-relative time is the number worth writing down

Absolute ticks are fine for a machine and poor for a person. "Tick 61,440" survives being read back by nobody. "Nine seconds into round 14" survives being read back by everyone, including you, in a week.

CS2 demos carry what you need for the conversion: parsers expose a round start time alongside the round events, surfaced from m_fRoundStartTime.³ Subtract the round's start tick from your target tick, divide by the tick rate, and the result is a position inside the round rather than inside the file.

Keep both. The absolute tick is what you paste into the console; the round-relative time is what you write in the note. The calculator prints the second one as soon as you give it a round start tick, for the same reason.

The shape of it

Three numbers and one command, and only one of them is arithmetic.

1. Establish the tick rate from the demo, not from habit.
2. Confirm the tick is a server tick and not a frame index.
3. Subtract a lead-in, clamped at zero.
4. demo_gototick <tick> 0 1, with the zero.

Once that is a habit, demo review stops involving the scrub bar. If you are reviewing comms as well as positioning, the voice comms calculator covers the other half of the setup, and the FACEIT demo guide covers which demos carry voice at all.