Skip to content
cccskills
FreePublished on GitHub

find-CCSPlayerPawn_SnapEyeAngles

Find and identify the CCSPlayerPawn_SnapEyeAngles function in CS2 server binary using IDA Pro MCP. Use this skill when reverse engineering CS2 server.dll or libserver.so to locate the non-virtual SnapEyeAngles method. It is the one caller of the shared apply helper (CCSPlayerPawn_ApplyEyeAngleNetworkChange) that is NOT CCSPlayerPawn_SnapViewAngles. Emits a unique IDA-style byte signature and a func YAML. Mirrors the find-CCSPlayerPawn_SnapEyeAngles.py preprocessor (xref_funcs apply-helper, exclude_funcs SnapViewAngles). Trigger: CCSPlayerPawn_SnapEyeAngles, SnapEyeAngles

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md6.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Find CCSPlayerPawn_SnapEyeAngles

Locate CCSPlayerPawn_SnapEyeAngles in CS2 server.dll or libserver.so using IDA Pro MCP tools.

This is a non-virtual, direct-call member function (no vtable slot — emit a byte sig, not an offset). It is the structural twin of CCSPlayerPawn_SnapViewAngles: same normalize helper, same apply helper, same network-change fields — but it does NOT cache the angle+previous into the pawn, and sets a different internal state byte.

Primary resolution = the apply-helper caller chain (matches the preprocessor script): the shared apply helper CCSPlayerPawn_ApplyEyeAngleNetworkChange has exactly two callers — SnapViewAngles and SnapEyeAngles. Take the caller that is not SnapViewAngles.

Method

1. Reuse previous signature (fast path)

If a prior CCSPlayerPawn_SnapEyeAngles.{platform}.yaml exists, try its func_sig via mcp__ida-pro-mcp__find_bytes. Single match → resolve to function start, skip to Step 5. Else continue.

2. Load CCSPlayerPawn_SnapViewAngles (the anchor)

ALWAYS use SKILL /get-func-from-yaml with func_name=CCSPlayerPawn_SnapViewAngles.

If it errors (not yet found), run SKILL /find-CCSPlayerPawn_SnapViewAngles first, then retry. Extract func_va of CCSPlayerPawn_SnapViewAngles.

3. Identify the apply helper inside SnapViewAngles

mcp__ida-pro-mcp__callees addrs="<SnapViewAngles_func_va>"
mcp__ida-pro-mcp__decompile addr="<SnapViewAngles_func_va>" include_addresses=false

The apply helper (CCSPlayerPawn_ApplyEyeAngleNetworkChange) is the call made late in SnapViewAngles (just before the memfree tail), taking (pawn, local); it applies the m_angEyeAngles network-state change (touches the pawn's networkvar change-component). Record apply_helper_addr. Optionally rename it to CCSPlayerPawn_ApplyEyeAngleNetworkChange.

4. Apply-helper caller minus SnapViewAngles → SnapEyeAngles

mcp__ida-pro-mcp__xrefs_to addrs="<apply_helper_addr>"

The apply helper has exactly two code callers: SnapViewAngles and SnapEyeAngles (plus data/vtable refs). SnapEyeAngles = the code caller that is not SnapViewAngles. This is the interactive form of the preprocessor's xref_funcs=[ApplyEyeAngleNetworkChange] + exclude_funcs=[SnapViewAngles]. If a third code caller ever appears, fall back to the structural confirmation below.

Decompile the candidate and confirm ALL:

  1. Calls the same apply helper as SnapViewAngles.
  2. Writes the same network-change fields, guarded by the same entity-handle validity check.
  3. Does NOT perform the angle+previous cache stores into the pawn (no consecutive member stores at the SnapViewAngles cache offsets). ← key disambiguator.
  4. Internal state byte set to the eye value (2), vs view's value.
  5. (Confirmation) its only caller is the eyeangle console command handler (no string of its own; reached via a command-dispatch table).

Adjacency hint (linux often, not guaranteed on windows): SnapEyeAngles frequently sits immediately before SnapViewAngles in address order. Use only as a hint — always confirm structurally.

Record func_addr. Optionally rename to CCSPlayerPawn_SnapEyeAngles.

5. Generate signature

ALWAYS use SKILL /generate-signature-for-function with addr=<func_addr>. Emit IDA style verbatim (space hex, ? wildcards) — do NOT convert to CSS \x2A unless a gamedata.json entry is explicitly requested.

Reference sigs (build 14165 — sanity check only, regenerate per binary):

  • linux: 55 48 89 E5 41 57 41 56 41 55 41 54 53 48 89 FB 48 89 F7 48 81 EC ? ? ? ? E8 ? ? ? ? 8B 8B
  • windows: 48 89 5C 24 ? 48 89 74 24 ? 55 48 8D 6C 24 ? 48 81 EC ? ? ? ? 48 8B DA

6. Write func YAML

ALWAYS use SKILL /write-func-as-yaml:

  • func_name: CCSPlayerPawn_SnapEyeAngles
  • func_addr: <func_addr>
  • func_sig: validated sig from step 5

Function Characteristics

  • Linkage: non-virtual, direct-call (no vtable entry)
  • Binary: server.dll / libserver.so
  • Parameters: (pawn, QAngle* angles) (+ float on linux ABI)
  • Caller: the eyeangle console-command handler
  • Distinguishing trait: structural twin of SnapViewAngles WITHOUT the prediction cache; state byte = 2; same normalize + apply helpers; networks m_angEyeAngles

Discovery Strategy (why this is stable across updates)

  1. SnapViewAngles is the durable anchor (found via the setang usage string → handler → its non-teleport branch call).
  2. The apply helper CCSPlayerPawn_ApplyEyeAngleNetworkChange is pinned inside SnapViewAngles, and has exactly two callers; SnapEyeAngles is the non-view caller — deterministic, not address-based.
  3. The final byte sig is regenerated per binary, so it self-heals each game update once the functions are re-resolved.

Preprocessor pipeline equivalent

This skill is the interactive twin of the unattended chain in ida_preprocessor_scripts/:

find-Setang_CommandHandler                    [xref_strings "setang pitch yaw"]
 -> find-CCSPlayerPawn_SnapViewAngles          [LLM_DECOMPILE off handler, non-teleport call]
 -> find-CCSPlayerPawn_ApplyEyeAngleNetworkChange [LLM_DECOMPILE off SnapViewAngles, apply call]
 -> find-CCSPlayerPawn_SnapEyeAngles           [xref_funcs apply-helper, exclude_funcs SnapViewAngles]

Reference YAMLs live in references/server/{Setang_CommandHandler,CCSPlayerPawn_SnapViewAngles}.{platform}.yaml.

Output YAML Format

  • server.dll -> CCSPlayerPawn_SnapEyeAngles.windows.yaml
  • libserver.so -> CCSPlayerPawn_SnapEyeAngles.linux.yaml

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Clean up the local workspace after a dev branch has been merged into main. Verifies the current dev branch is fully merged into origin/main, then switches to main, pulls the latest, deletes the local dev branch, and deletes the remote dev branch if it still exists. STOPS and warns the user if the current branch is not yet merged. Triggers: cleanup workspace, cleanup branch, delete merged branch, finish dev branch, post-merge cleanup

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

Convert an existing find-XXXX SKILL.md into a preprocessor Python script, updating configs/<GAMEVER>.yaml and removing the old SKILL.md. Covers xref-string-based and LLM_DECOMPILE-based discovery patterns.

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

Create an Agent SKILL.md fallback for an existing find-XXXX finder that relies on a fragile discovery foundation — above all LLM_DECOMPILE (patterns C/D/E), which matches the decompiled shape of a predecessor function against a stored reference and breaks when a symbol is inlined or de-inlined in a way the reference does not cover. The generated fallback coexists with the preprocessor and runs only when it returns failure, recovering every target robustly by decompiling the predecessor and following the inline/de-inline boundary with semantic anchors. Use when a finder broke on a game update, or you want to durably backstop one before it does. The recipe generalizes to any finder foundation. Triggers: create agent skill fallback, add SKILL.md fallback, robust fallback for finder, backstop LLM_DECOMPILE finder, final guarantee skill

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

Create a new cpp_tests entry for validating a C++ interface vtable layout against binary reference YAMLs. Creates the .cpp test file in cpp_tests/ and appends a configs/<GAMEVER>.yaml entry under cpp_tests:. Use when a user asks to add vtable layout validation for a new hl2sdk_cs2 interface class.

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

Create a GitHub pull request from staged task changes or an already-committed current branch. Deliver source/config/ reference changes together with their computed source-owned `bin_artifacts` closure. PR validation routing is owned by the default-branch trusted workflow; snapshots, gamedata, and manifests are Release-derived only.

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

Create a new find-XXXX preprocessor Python script from scratch (no existing SKILL.md), add configs/<GAMEVER>.yaml skill and symbol entries. Covers xref-string-based and LLM_DECOMPILE-based discovery patterns. Use when a GitHub issue or user instruction specifies a new function to find.

The English summary is being prepared. Showing the original description.

mrc4tt/CS2_VibeSignatures3Updated Oct 20, 2026

See all skills by mrc4tt

Report a problem with this skill