Guide CS2 Internal Bhop — Post-Animgraph Update Base

[byte_corvus]

Valve keeps trying to mess with the movement engine, but the logic remains the same.

Got my hands on a clean internal bhop base that handles the latest Animgraph changes. If you have been having issues with the jump state since the last update, this snippet shows how to snapshot the raw input correctly before the engine or other hooks mess with it. It uses the latest move signature logic, avoiding the typical flickering seen in older pastes.

Technical Implementation Core:

1. Captures the jump bitmask (0x10001) directly from the client base.
2. Uses prediction flags (FL_ONGROUND) to determine the exact tick for the jump command.
3. Compatible with prediction systems to ensure smooth movement even on high-latency servers.

Spoiler: Internal Logic Snippet

#pragma once
#include <Windows.h>
#include <cstdint>
#include "game.h"
#include "offsets.h"
#include "sdk/offsets.hpp"
#include "sdk/buttons.hpp"
#include "prediction.h"
 
namespace Bhop
{
    struct BhopConfig
    {
        bool enabled = false;
    };
 
    inline BhopConfig config;
 
    // Raw jump button state captured at the top of CreateMove,
    // BEFORE any writes — reflects the player's actual space key input.
    inline uint32_t savedJumpInput = 0;
 
    inline void CaptureInput()
    {
        if (!Game::clientBase) return;
        savedJumpInput = Game::Read<uint32_t>(
            Game::clientBase + cs2_dumper::buttons::jump);
    }
 
    inline void Tick(uintptr_t localPawn)
    {
        if (!config.enabled) return;
        if (!localPawn || !Game::clientBase) return;
 
        // Player wants to jump when the engine's button state has the
        // held (bit 16) or pressed-edge (bit 0) bits set.
        // Read from the snapshot taken before any hook writes.
        bool wantsJump = (savedJumpInput & 0x10001) != 0;
        if (!wantsJump) return;
 
        int health = Game::Read<int32_t>(localPawn + Offsets::m_iHealth);
        if (health <= 0) return;
 
        uint32_t flags = Prediction::IsActive()
            ? Prediction::GetPredictedFlags()
            : Prediction::GetFlags(localPawn);
 
        uintptr_t jumpAddr = Game::clientBase + cs2_dumper::buttons::jump;
        bool onGround = (flags & 1) != 0; // FL_ONGROUND
 
#ifdef _DEBUG
        {
            static bool s_wasGround = true;
            if (onGround != s_wasGround)
            {
                printf("[Bhop] %s | flags=0x%X pred=%d btn=0x%X\n",
                    onGround ? "LANDED" : "JUMPED (airborne)",
                    flags, Prediction::IsActive() ? 1 : 0, savedJumpInput);
                s_wasGround = onGround;
            }
        }
#endif
 
        if (onGround)
            Game::Write<uint32_t>(jumpAddr, ButtonState::PRESS);
        else
            Game::Write<uint32_t>(jumpAddr, ButtonState::RELEASE);
    }
}

Animgraph Handling and Timing
The core of the fix here is capturing the savedJumpInput at the very start of your CreateMove or Tick cycle. By reading the state before you write to it, you avoid conflict with how the engine now processes movement bytes. It relies on the latest cs2_dumper button offsets, so make sure your header files are synced with the current build.

Security and Risk
Writing directly to the button address in CS2 is generally functional for internal cheats, but keep in mind that server-side movement checks are getting more aggressive. If you are hitting every single frame perfectly without a single miss, the server-side metrics might flag your account for low trust. Modifying the logic to occasionally miss a jump or adding a tick delay could make this look more human on Premier ladders.

Anyone tested how this feels on the latest subtick adjustments?