Question CS:Source — Hooking set_cycle for Inspect Animations (Networking Issues)

[byte_corvus]

The classic Source Engine trap: testing logic on a local listen server and thinking it's production-ready. I’ve seen this a dozen times with weapon inspect implementations in CSS. Everything looks smooth in your own vacuum, but the moment latency and server-side prediction enter the chat, the animation resets or refuses to play.

The Technical Bottleneck
On a listen server, your client and server states are essentially one. On a networked server, the prediction system is constantly reconciling your local state with what the server dictates. If you're manually driving the animation cycle via set_cycle without accounting for netvar synchronization, the engine is going to snap your viewmodel back to the 'official' sequence state every few ticks.

bool inspect_active = false;
float inspect_start_time = 0.0f; 
int last_sequence = -1;

void __fastcall hooks::set_cycle::hook(void* player, float cycle)
{
    if (!config_manager->get_current_config()->inspect.enable)
        return original(player, cycle);

    auto local = (entity_t*)player;
    float cur_time = interfaces::global_vars->cur_time;
    int current_sequence = local->m_nSequence();

    if (GetAsyncKeyState(config_manager->get_current_config()->inspect.key) & 1)
    {
        if (current_sequence == 0)
        {
            inspect_active = true;
            inspect_start_time = cur_time;
            last_sequence = current_sequence;
        }
    }

    if (inspect_active)
    {
        if (current_sequence != last_sequence)
        {
            inspect_active = false;
            original(player, cycle);
            return;
        }

        float elapsed = cur_time - inspect_start_time;
        if (elapsed < 7.5f)
        {
            float progress = elapsed / 7.5f;
            float targetCycle = 0.404f + (1.0f - 0.404f) * progress;
            original(player, targetCycle);
        }
        else
        {
            inspect_active = false;
            original(player, cycle);
        }
        last_sequence = current_sequence;
    }
    else
    {
        original(player, cycle);
    }
}

Why it breaks on public servers:

1. Detailed prediction: The engine expects the viewmodel to follow a specific sequence logic. When you hijack the cycle, the interpolation system detects a mismatch.
2. m_nSequence resets: If the server sends a sequence update or if your local prediction thinks you've switched weapons/states, inspect_active gets killed.
3. CurTime vs TickCount: Relying purely on cur_time without checking if you're in the middle of a prediction frame can lead to jitter.

Spoiler: Technical Suggestions

You likely need to hook into the prediction system or find where the viewmodel sequence is updated to prevent the server from overwriting your manual cycle. Some people find success by modifying the netvars directly or bypassing the C_BaseViewModel::OnDataChanged checks for specific sequences.

Using GetAsyncKeyState in a hook like this is a bit of a 'paste' move—better to handle the input in your CreateMove and pass a flag. If anyone has managed to get a stable client-side inspect working without it twitching during high-ping spikes, post your logic below.