Grenade trajectories in CS2 are collision solutions with energy loss. Walls are not smooth planes but steps made of collision boxes. Version updates often change these invisible edges, not gravity. Learn to read surfaces instead of memorizing lines.
Introduction
Many players practice grenades by memorizing a line: stand here, aim here, jumpthrow. That line works in the current version, but in the next it might be "half a grid off." The problem isn't your memory—it's that you're remembering results, not geometry. A grenade trajectory is essentially a collision solve with energy loss. Walls aren't flat; they're steps, edges, and collision box seams. When a version changes, what shifts first is often not gravity but these "invisible edges."
1. Invisible Edges of Collision Boxes: Why Bounce Points Are More Sensitive Than Release Points
First, a fact: CS2 grenade collision detection uses simplified collision geometry, not the textured surface you see. Brick seams, reliefs, and decorative lines on textures don't participate in collision; the baked collision boxes do. These boxes are simplified for performance, so walls in the physics world aren't smooth—they're "steps" pieced together from planes.
The boundaries between these steps are the invisible edges. When a grenade grazes an edge, the calculation of incidence and reflection angles instantly switches to a different reference plane. What you see is "it bounced," but physically it's a sudden change in normal direction. A half-grid difference in release point changes where you hit the edge, and the post-bounce landing point can differ by two or three body widths. That's why the same default grenade line feels "still usable" to some and "completely off" to others after an update—they stand in different spots and hit different edges.
More subtle is the bounce coefficient. Different materials have different energy loss parameters in the engine—wood, metal, and concrete decay at different rates after a bounce. If an update adjusts physical parameters for a surface type or rebakes a map's collision boxes, your memorized "one bounce into the smoke" becomes "one bounce into the wall." This isn't mysticism; it's parameter migration.
2. Three Layers of Dependency in Default Grenade Lines: Release, Edges, Landing
A default grenade line seems to depend only on the release point, but actually has at least three layers.
The first layer is release point and view angle. Foot position, crouch state, and mouse pitch determine the direction and magnitude of the initial velocity vector. Jumpthrows add vertical velocity, which isn't continuous under tick sampling, so the same jumpthrow varies slightly with network conditions.
The second layer is the edges along the collision path. From release to landing, the grenade may bounce once or multiple times. Each bounce is information loss: you know it will bounce roughly, but not which edge it will graze. The value of a default line is that it compresses this path into a reproducible action—but reproducibility assumes the edges haven't changed.
The third layer is landing judgment. Smoke expansion is a volume, flash detonation is a timer, fire spread is a set of flame cells. A half-grid landing difference can mean smoke misses a gap or flash pops a fraction early. These differences are invisible in practice maps but in real matches decide whether you see the smoke edge first or get flashed first.
Among the three, release point is easiest to remember, landing easiest to verify, and the middle edges easiest to ignore. Yet version updates most often affect that middle layer.
3. Relearning by Version: Not Overthrowing Memory, but Rebuilding Indexes
Hearing "relearn by version," many think of scrapping all lines. Unnecessary and unrealistic. A better approach is rebuilding indexes: rewrite linear memory of "position—aim—landing" into structured memory of "release point—expected bounce count—key edges—landing tolerance."
How? Step one: in practice, split each default line into two segments—release to first bounce, first bounce to landing. Record tolerances for each. If the first segment has small tolerance and the second large, the line is edge-sensitive and should be re-verified first after updates.
Step two: annotate each line with "alternative landings." A smoke often has two or three paths; if one fails after an update, another may still work. Practicing alternatives into muscle memory is more reliable than finding new lines on the fly.
Step three: build a version re-verification checklist. After major updates, run edge-sensitive lines first, then high-tolerance lines. Don't rely on "seems to work"; let landing judgment speak: does smoke have gaps, does flash blind, does fire cover fully.
4. Transferable Throwing Intuition: From Memorizing Lines to Reading Surfaces
What survives versions isn't a line but the ability to read surfaces. Seeing a wall, you can roughly judge its collision face orientation, edge positions, and post-bounce speed decay direction. This intuition comes from repeated "deliberate misses": in practice, intentionally graze edges, observe reflection angle changes, and record bounce distances for different materials.
With surface-reading ability, updates are no longer "my line is dead" but "this wall's edges changed, I'll graze differently." Default lines still need practice, but the goal isn't memorizing answers—it's building geometric intuition that migrates with versions. Walls aren't flat; they're steps. Lines aren't spells; they're paths. Paths change; geometry doesn't lie.