update readme

README.md

@@ -59,6 +59,193 @@ Follow `-latest` to adopt updates as they land, or pin a buildid tag to adopt th
 
 ---
 
+## What can you build with this?
+
+The artifacts answer four different questions, and most useful work joins two or more of them:
+
+- **`gamedata-<game>.json` — where the code is.** Every entry is a hook point or a call target: a byte signature or an RTTI vtable slot, tiered and, for `core`/`high_confidence`, checked against a running server.
+- **`netvars-<game>.json` — what the state is.** Field offsets and types for every SchemaSystem class, plus the base graph, the enum tables and per-type sizes. This is the half that needs no hooking at all: a great deal of gameplay is readable and writable as plain memory.
+- **`abi-<game>.json` — whether it is safe to call.** A declared prototype joined to the register footprint measured in *this* build, with a verdict per function. `verified` and `lower-bound` are callable; `mismatch` says the prototype in circulation is wrong for this binary.
+- **`bindings-<game>.json` — what the binary declares about itself.** Console commands with flags and handler addresses, entity inputs and outputs, map classname → C++ class, and the typed Pulse registry.
+
+One thing to internalise before reading further, because it shapes every capability below: **there are no ConVars in these artifacts, in either game.** The command surface is 784 ConCommands on CS2 and 855 on Dota, and not one `sv_airaccelerate`, `mp_freezetime`, `bot_quota` or `dota_gold_per_tick` appears anywhere. This is a *function-and-layout* release, not a configuration release. A plugin built on it changes behaviour by detouring code and writing fields — never by setting a cvar.
+
+Tiers stay visible throughout. `core` and `high_confidence` are buildable today; the `experimental` band is fenced off at the end and is a different kind of thing entirely.
+
+---
+
+### CS2
+
+#### Movement and player physics
+
+The whole per-tick movement chain is individually hookable — `PhysicsSimulate` → `ProcessMovement` → `MoveInit` → `CheckParameters` → `PlayerMove` → `FullWalkMove` → `{Friction, AirMove/AirAccelerate, CategorizePosition, CheckVelocity, StartGravity, CheckFalling}` → `PostPlayerMove`. Every stage is `core` with a validated signature, and 22 ABI entries declare the `CMoveData*` they hand you. `AirAccelerate` resolves as `void(CCSPlayer_MovementServices*, CMoveData*, Vector&, float, float)`, `verified`, with a measured footprint of three integer and two float registers — so a surf/KZ/bhop server that rewrites air acceleration in flight is a detour and two float writes, not a reverse-engineering project. Watch two edges: `PreWalkMove`'s prototype is `unverified`, and `GroundAccelerate` has a validated signature but no declared prototype at all (footprint only).
+
+Jumping splits into two independently hookable implementations — `CheckJumpButtonModern(CCSPlayerModernJump*, CMoveData*)` and `CheckJumpButtonLegacy(CCSPlayerLegacyJump*, CMoveData*)`, both `verified` — and both jump objects are fully laid out, down to sub-tick press and landing fractions. That plus `m_flAccumulatedJumpError` and `m_bHasWalkMovedSinceLastJump` is enough for either a legitimising autohop or a bhop-script detector built on press-phase distribution.
+
+Surf detection does not need heuristics: `CCSPlayer_MovementServices::m_flTicksSinceLastSurfingDetected` is the engine's own signal, sitting next to the ground normal, surface friction and the surface-property token. Per-player speed control is `CCSPlayerPawn::GetPlayerMaxSpeed` (`verified`) plus `m_flMaxspeed`, `m_flStamina` and `m_flVelocityModifier`. Crouch work has a real predicate to hook — `CanUnduck` is `bool(CCSPlayer_MovementServices*, CMoveData*)`, so returning false pins a player crouched with full engine consistency rather than by poking a netvar. And the input side is intercepted at `CPlayer_MovementServices::RunCommand`, with `m_nButtons`, the fully enumerated 64-bit `InputBitMask_t`, the `uint32[64]` per-button last-press command numbers, and the four sub-tick move fractions all readable.
+
+What you do not get: `TryPlayerMove`, `WalkMove`, `Accelerate` and `TracePlayerBBox` are all `unresolved` (`sig-drifted`) this build, and `CMoveData` itself is not a schema class — you get a correctly-typed pointer and no field offsets.
+
+#### Combat, damage and tracing
+
+`CBaseEntity::TakeDamage` is the funnel and `CCSPlayerPawn::OnTakeDamage_Alive` the player-specific override, but the interesting part is that you do not need a constructor to build a damage packet: `CTakeDamageInfo` is laid out completely — 22 fields over 280 bytes — and `CTakeDamageResult` (15 fields) tells you what the engine actually did, including `m_flPreModifiedDamage` beside `m_flDamageDealt` and a `m_bWasDamageSuppressed` flag. `DamageTypes_t`, `HitGroup_t` and the 21-flag `TakeDamageFlags_t` (`DFLAG_PREVENT_DEATH`, `DFLAG_IGNORE_ARMOR`, …) give you the switchboard. Two ABI notes worth respecting: `CBaseEntity::DispatchTraceAttack` and `CBaseEntity::Event_Killed` are `verified` — and `Event_Killed` measures as the CS2-shaped `(CCSPlayerPawn*, CTakeDamageResult*)`, not the Source-1 `CTakeDamageInfo const&` everyone assumes — while `abi:CBaseEntity::TakeDamage` is tier `core` but verdict **`unverified`**: the declaration was never checked against this build. Build the struct by offsets and prefer the verified entry points.
+
+Weapon rebalancing is entirely schema work. `CCSWeaponBaseVData` is 84 fields over 2,216 bytes: damage, headshot multiplier, armour ratio, penetration, range falloff, cycle time, seven per-stance inaccuracy terms, four recoil terms, the spray-recovery transition bullets, price, kill award — and `m_nRecoilSeed`/`m_nSpreadSeed`, the per-weapon RNG seeds that generate CS2's deterministic spray patterns. Reach it with `FindWeaponVDataByName` (`verified`); there is no member offset from a weapon entity to its VData.
+
+Tracing has one fully `verified`, params-complete entry point — `TraceShape(const void*, const Ray_t&, const Vector&, const Vector&, const CTraceFilter*, trace_t*)` — corroborated by two independent declarations. The catch is structural and worth planning for: `Ray_t`, `trace_t`, `CGameTrace` and `CTraceFilter` are not schema types, so you get the call shape and must supply the struct definitions. If you would rather not, `CPulseServerFuncs::GetTraceHit` is a fully typed ray cast with six named return values, and `DealDamage`/`DealRadiusDamage` sit beside it — a complete custom hitscan weapon with no native code.
+
+For inventory and loadout rules, eight `CCSPlayer_WeaponServices` entry points carry `verified`, params-complete prototypes including `this` (`EquipWeapon`, `DropWeapon`, `SwitchWeapon`, `GetWeaponBySlot`, and the `CanEquip`/`CanSwitch`/`CanUse` predicates), and `CCSPlayer_ItemServices::CanAcquire` is a verified buy gate. Skins and StatTrak are pure offsets: the `CEconEntity` fallback block, `CAttributeContainer::m_Item` → a fully laid-out `CEconItemView`, and `CAttributeList::SetOrAddAttributeValueByName` (`verified`) to write.
+
+Two things this domain is unusually clean about. The entire combat pipeline lands in `core` and `high_confidence` — the experimental band contributes nothing to it. And `CCSScript_EntityScript` comes out as a contiguous named vtable run with a three-stage damage pipeline — `OnBeforePlayerDamage`, `OnModifyPlayerDamage`, `OnPlayerDamage` (veto / scale / observe) — which is exactly the shape a perk or RPG mod wants, though none of those slots has a typed prototype, only a measured register count.
+
+#### Bots and the nav mesh
+
+`CCSPlayerPawn::m_pBot` is a typed `CCSBot*` on the pawn, and `CCSBot` is 140 typed fields over 24,088 bytes: current enemy, visible parts, goal position, path index, heard noise, panic and hurry timers, stuck state with a velocity ring buffer, radio timestamps, and the whole aim model (`m_lookPitch`/`m_lookYaw` with velocities, `m_aimError`, `m_aimFocus`, the reaction-queue indices). Every `CountdownTimer` is itself a schema class, so timers are readable *and* writable. A live bot-brain inspector, a custom difficulty curve, or an anti-stuck watchdog all need zero hooking.
+
+The aim and behaviour functions — `UpdateLookAngles`, `UpdateReactionQueue`, `BendLineOfSight`, `FindMostDangerousThreat`, plus the direct verbs `SetBotEnemy`, `SetState`, `Panic`, `Blind`, `Retreat` — are `core` or `high_confidence` byte signatures, but **none has a declared prototype**: `abi-cs2.json` has no entry for any `CCSBot::` method. You get an address and a register count.
+
+Be precise about the state machine, because it is easy to oversell. All 16 behaviour states appear as `core` entries and a `OnEnter=0 / OnUpdate=1 / OnExit=2 / GetName=3` slot convention is visible across them. But those offset-form entries carry no class binding — `IdleState::OnEnter`, `HideState::OnEnter` and `PickupHostageState::OnEnter` are all bare "slot 0" — so resolving a specific state's vtable needs a class pointer the artifacts do not supply. Eleven of the state methods (including `CCSBot::SetState` and eight `OnUpdate` slots) ship as byte signatures instead, and those you can resolve directly.
+
+Nav work is better served from the sides than the middle. `CPulseServerFuncs::GetEntityNavMeshPosition` and `GetEntityHeightAboveNavMesh` are typed with no signature dependency at all; `CCSBot::m_playerTravelDistance` is a `float32[64]` of nav travel distance from that bot to every player slot, maintained by the engine every tick — real walk distances for free. Runtime map flow is `CFuncNavBlocker` with `m_nBlockedTeamNumber` (per-team blocking) driven by `BlockNav`/`UnblockNav`, whose handlers are `verified` and params-complete. The 44 `nav_*` editor commands survive in the dedicated server with verified `void(CCommandContext*, CCommand*)` handlers, including `nav_check_connectivity` — but nearly all of them carry the `cheat` flag, so a CI map-validation harness runs with `sv_cheats` on, not on a public server. There is no `CNavArea` or `CNavMesh` schema class: area-level data means calling engine functions with pointers you obtained from other engine functions.
+
+#### Entities, spawning and map mechanics
+
+The runtime-spawn chain is `core` and `verified` end to end: `CreateEntityByName` → `CEntityKeyValues::FindOrCreateKeyValues`/`SetString` → `CEntityKeyValues::AddConnectionDesc` → `CGameEntitySystem::DispatchSpawn`. `AddConnectionDesc`'s nine-parameter prototype maps field-for-field onto the schema struct `EntityIOConnectionData_t`, and its `targetType` argument is enumerated by `EntityIOTargetType_t` — prototype, struct layout and legal constants derived separately and agreeing. The 474-entry classname table (`prop_dynamic` → `CDynamicProp`, and the alias forms Valve registers separately) tells you what to pass. One hole: nothing here tells you how to *allocate* the `CEntityKeyValues` object.
+
+Entity I/O is where one hook shape covers an enormous surface. 715 CS2 inputs are enumerated with class, handler symbol and address, 673 have a live signature, and the overwhelming majority carry the same `verified` prototype `void(CEntityInstance*, InputData_t&)` — so a single trampoline plus a dispatch table keyed by address is an IO firewall for community maps. Do check before assuming universality: about fifteen handlers declare something else (`CBaseFilter::InputTestActivator` takes a `CBaseEntity*`; `CGamePlayerEquip::InputTriggerForActivatedPlayer` takes an `InputData_t*`; the `CMathCounter` arithmetic inputs declare only `inputdata_t&`), and thirteen are verdict `unverified`. To fire rather than intercept, `CGameEntitySystem::AddEntityIOEvent` is `verified` with a full 10-parameter prototype including the delay float. The limit: `InputData_t` and `Variant_t` have no schema layout, so you get the hook point and not a payload decoder.
+
+Trigger volumes have a single global arbiter — `CBaseTrigger::PassesTriggerFilters` is `verified` `bool(CBaseEntity*)` at vtable 270 — and a passive reader: `m_hTouchingEntities` is a live handle vector at a fixed offset. Collision surgery is netvar-only and complete: `VPhysicsCollisionAttribute_t` exposes `m_nInteractsAs`/`m_nInteractsWith`/`m_nInteractsExclude` as three `uint64` masks, which is exactly the knob a no-block plugin flips.
+
+`func_mover` is worth flagging as a discovery: it has zero entity inputs and zero entity outputs, so anyone auditing the IO graph would conclude it is inert. Its entire runtime surface is 44 typed `CFuncMoverAPI` Pulse methods plus 98 netvar fields. CS2's spline-mover system lives outside the classic IO graph.
+
+#### Game rules, teams and economy
+
+`CCSGameRules` is 189 fields over 70,720 bytes, reached by finding `cs_gamerules` and reading `CCSGameRulesProxy::m_pGameRules` — the bare `GameRulesPointer` signature is `unresolved` this build, so use the entity route. From there `RestartRound` and `GoToIntermission` are `verified`, `TerminateRound` is `lower-bound` with a delay/reason/reward-vector prototype, and warmup, phase and reset drivers are validated addresses with **no** declared prototype — a real gap in an otherwise strong domain. The round-end presentation block (winner, reason, message string, fun-fact token, mute flags) is all writable, and `m_iMatchStats_RoundResults[30]` with the two per-round alive-count arrays means a full competitive match history is readable from one pointer with no event subscription.
+
+Money is a plain `int32`: `m_pInGameMoneyServices` → `m_iAccount`, with start/spent/next-round fields beside it and the whole team loss-bonus model on the rules object. Note there is **no per-player money function at any tier** — no `AddAccount`, no `GiveMoney` anywhere in the search — so an economy mod writes the ledger and replicates with `NetworkStateChanged` (`verified`; its sibling `StateChanged` is verdict `mismatch`, so use the right one).
+
+Team moves have three independent paths — `CBaseEntity::ChangeTeam` at vtable 102, `CBasePlayerController::SwitchSteam` (`verified`), and the command path — gated by `CCSGameRules::WillTeamHaveRoomForPlayer` (`verified`). Two of the alternatives are weaker than they look: `CCSPlayerController::SwitchTeam` and `HandleCommandJoinTeam` are `unverified`, and `abi:CCSPlayerController::ChangeTeam` is `return-only` (no parameter list). Respawn waves are two arrays on the rules object (`m_TeamRespawnWaveTimes`, `m_flNextRespawnWave`), and spawn-point pools with round-robin cursors sit beside them — though the engine's *choice* of spawn point is not exposed as a hookable function. One defect to verify before shipping: `CCSPlayerController::Respawn` and `CCSPlayerController::RoundRespawn` are both reported at vtable 272 while the base-class `RoundRespawn` is at 270; two names cannot share one slot.
+
+Stats need no events at all. `CSMatchStats_t` derives from `CSPerRoundStats_t` and already tracks `m_i1v1Count`/`m_i1v1Wins`, `m_i1v2*`, `m_iEntryCount`/`m_iEntryWins`, `m_iEnemy5Ks` through `m_iEnemy2Ks`, and shots fired vs shots on target — the clutch and entry numbers most stats plugins recompute from kill events.
+
+#### Effects, sound and networking
+
+The lowest-risk half of this domain needs no signatures: `env_shake`, `env_fade`, `env_beam`, `env_instructor_hint`, `env_fog_controller`, `env_tonemap_controller` and the render/glow block on `CBaseModelEntity` are all datadesc-sourced inputs plus exact schema offsets, with their enums (`ShakeCommand_t`, `ViewFadeMode_t`, `BeamType_t`, `RenderFx_t`) fully enumerated. `CParticleSystem` networks 64 entity-attached control points *and* 64 control-point names, so a beam tracking two moving players is state, not a call.
+
+`UTIL_DispatchEffect`/`UTIL_DispatchEffectFilter` are `core`, `verified`, params-complete, and their one non-trivial argument — `CEffectData` — is fully mapped (20 fields, 112 bytes, SysV `memory`). That pairing is the ideal case these artifacts exist to produce.
+
+Be honest about recipient filters, because several attractive claims depend on them. The filtered dispatchers (`UTIL_DispatchParticleEffectFilter_Position`/`_Attachment`, `UTIL_SayTextFilter`, `UTIL_SayText2Filter`, `SoundOpGameSystem::StartSoundEventString`) are real and verified — but the *only* recipient-filter symbol anywhere in `gamedata-cs2.json` is `CRecipientFilter::AddAllPlayers`, whose ABI entry is `unverified` with an empty parameter list. There is no `AddRecipient`, no per-team filter, no single-user filter. You get "dispatch to everyone" and a filter-shaped hole you must fill from your own framework. The genuinely per-client route that *is* covered is the `point_soundevent` entity: `StartSoundOnSingleClient` targets one player index and fires an `m_onSoundFinished` output when the sound ends.
+
+The sound-operator system itself is unusually complete — start-by-string, the 11-argument raw start, set-param-string, and stop-with-filter are all `core` with `verified`, params-complete prototypes from a single provenance. The exception is flagged loudly: `SoundOpGameSystem::StopSoundEvent` is verdict `mismatch` (measured footprint exceeds declared), so use `StopSoundEventFilter`.
+
+Both game-event stacks ship: the legacy `CGameEventManager` with fixed vtable getters, and the modern `CGameEventSystem` as a contiguous `verified` run (`PostEventAbstract` at 15, `PostEntityEventAbstract` at 17, register/unregister at 12/13). Bind to the concrete classes — the `IGameEventManager2::`/`IGameEventSystem::` interface aliases are all `unresolved`. Transport for custom messages is there (`CServerSideClient::SendNetMessage` is `core`/`verified`; the broadcast, channel and registry entries are `high_confidence`, several of them AI-derived names that passed live validation), but **no protobuf field layouts exist anywhere** — you get the pipe and the message id, never the payload shape.
+
+Voice routing splits cleanly: `CServerSideClient::IsHearingClient` (`verified`, vtable 21) is the per-listener decision hook and `CLCMsg_VoiceData` (vtable 39) the inbound handler — both `core`. Everything that would let you touch the raw voice *stream* (`IsProximityHearingClient`, `SendVoiceData`, `ProcessVoiceData`) is experimental, i.e. a guess.
+
+#### Performance, profiling and integrity
+
+A real tick profiler is buildable because both halves are present: `IGameSystem::LoopPostInitAllSystems->pEventDispatcher` is the `core` anchor, and the payloads it delivers are schema-laid-out — `EventAdvanceTick_t::m_nTotalTicksThisFrame` tells you the server ran N ticks in one frame, `EventSetTime_t::m_flRenderFrameTimeUnbounded` is the pre-clamp cost that reveals a hitch. Bring your own monotonic clock: there is no `Plat_FloatTime` in the artifacts.
+
+Per-entity think attribution is pure schema. `CBaseEntity::m_aThinkFunctions` is a `CUtlVector<thinkfunc_t>` and `thinkfunc_t` exposes the raw `m_think` function pointer, the `CUtlStringToken` naming the context, and next/last think ticks — so you can walk every entity, see which contexts are due this tick, and wrap only those. The same `m_think` pointer doubles as an integrity signal: it must land inside `libserver`'s text range.
+
+That is one leg of a defensive integrity monitor for the server process an operator owns. The others: 628 `core` and 1,401 `high_confidence` signatures have a wildcard-free first eight bytes, which is exactly where an inline detour lands, so prologue snapshots detect another module hooking the engine underneath you; and 705 ABI entries carry an explicit vtable index, so named slots can be snapshotted and diffed. Every locator names its owning library, so "is this pointer still in the module that owns it" is answerable per key.
+
+The console surface is the most mechanically reliable thing in the release. 755 of CS2's 784 registered commands carry a hookable `ConCommand::<name>` locator with a `verified` prototype — that is *all* commands, not a diagnostics subset, though the diagnostics family within it is broad (`stats_print`, `sv_packstats` with its `clear` argument, the `vprof_*` family, `mem_dump`, `net_stats_json`, `status_json`, `lrucache_stats`, `check_nofilefd`). Hooking is the reliable direction: the artifacts give you the callback address, not the `CCommand` layout needed to synthesize a call. `logaddress_add_http` ships log fan-out to an arbitrary URI with no sidecar, and tier0 carries a complete scripted-test harness (`Test_StartScript`, `Test_LoopForNumSeconds`, `Test_Checkpoint`, `Test_ExitProcess` with a chosen exit code) that is a CI rig Valve already wrote.
+
+Because command flags are decoded, the client-reachable attack surface is exactly enumerable rather than folklore: **30 CS2 commands carry `client_can_execute`**, including `ent_setpos` and `ent_setang` — which move *arbitrary entities* — alongside `give`, `god`, `noclip`, `kill`, `explode`, `setpos_player`, `callvote` and `replay_start`. Exactly two carry `server_can_execute` (`echo`, `play`), which answers a question plugin authors argue about: the server cannot push arbitrary console commands to clients through the normal path. That static audit is solid. Detecting a *runtime* change to those flags is not — every cvar-registry accessor (`CCvar::GetConVarFlags`, `CCvar::FindCommand`, `CCvar::RegisterConCommand`) is experimental with a guessed name.
+
+---
+
+### Dota 2
+
+Dota's surface is materially larger, and the difference is structural rather than incidental: **3,528 registered entity classnames against CS2's 474**, and 2,958 schema classes / 17,668 fields against 1,899 / 12,330. The reason is that in Dota every ability and every item is a networked entity with its own class — 2,155 `CDOTA_Ability*` classnames (795 of them `special_bonus_*` talents, 1,360 regular abilities), 660 `CDOTA_Item*`, 231 unit types, 130 heroes. What that buys is identification: given any script name a mod author types, you get the exact C++ class. What it does not buy is per-ability hooking — only a minority of those classes carry fields or functions of their own; the shared bases (`CDOTABaseAbility` 54 fields, `CDOTA_Item` 63, `CDOTA_BaseNPC` 269) are where the data lives.
+
+The shape of Dota's coverage is also different from CS2's. Its `core` tier is bigger but narrower: 919 `CModifierFactory<…>` entries and several hundred game-system factories account for most of it. The classic gameplay verbs a Dota modder expects — cast, apply damage, issue an order, add a modifier — are **not in it**. Dota's strength here is observation and schema; CS2's is invocation.
+
+#### Custom game rules
+
+`CDOTABaseGameMode` is 110 networked fields at exact offsets, and it is recognisably the Lua `GameRules:GetGameModeEntity():SetXxx()` API re-expressed as memory: fog of war, custom XP curves (`m_nCustomXPRequiredToReachNextLevel` is a networked int vector — replace the whole curve), respawn scaling, buyback rules, the attribute-to-stat coefficients (`m_flStrengthHP`, `m_flAgilityArmor`, `m_flIntelligenceSpellAmpPercent`), per-rune-type toggles as a `bool[10]` indexed by `DOTA_RUNES`, custom shops, ability-upgrade whitelists, HUD visibility bits, camera distance and min/max attack speed. Reach it via `CGameSystemReallocatingFactory<CGameRulesGameSystem,…>::GetStaticGameSystem` → `CDOTAGamerulesProxy::m_pGameRules` → `m_hGameModeEntity`. Four of these knobs also have typed Pulse setters that avoid raw writes.
+
+`CDOTAGameRules` itself is 326 fields and reads like a design document: the Roshan respawn *phase machine* is explicit (`ERoshanSpawnPhase` = ALIVE / BASE_TIMER / VARIABLE_TIMER — the variable window is a modelled state), pause has per-player budgets, and there are three distinct kinds of night with separate timers and a `HeroID_t` attributing which hero caused it.
+
+#### Modifiers, and the catalogue nobody else has
+
+919 `CModifierFactory<…>` entries sit in `core` with live-validated byte signatures — 812 `::Create`, 71 `::Destroy`, 36 `::IsSameType`, covering 826 distinct modifier classes including the Lua-backed ones (`CDOTA_Modifier_Lua`, the three motion variants, `CDOTA_Modifier_ScriptedMotionController`). The class name is not inferred; it is the template argument of a symbol Valve shipped. That gives you a complete, name-accurate index of every shipped modifier implementation plus a per-class hook point. `Create` is nullary, so hook the *return*, not the arguments.
+
+The vocabulary is complete too: `modifierfunction` has all 409 `MODIFIER_PROPERTY_*`/`MODIFIER_EVENT_*` values, `modifierstate` all 65 states, and `CDOTA_BaseNPC::m_nUnitState64` is a `uint64` — one read decodes stunned/silenced/rooted/hexed/disarmed/magic-immune for any unit. `CDOTA_Buff` is 38 fields including `m_hScriptScope`, the handle back into the Lua object.
+
+The wall: there is no `AddNewModifier` or `RemoveModifierByName` at any tier, and `CDOTA_ModifierManager` exposes only 7 of its 904 bytes — no vector of active buffs. You can hook creation and read a buff you hold; you cannot enumerate a unit's modifiers or apply one, except through the debug command `dota_modifier_test <entityindex> <modifiername> <duration>`, whose handler is `verified`.
+
+#### Match telemetry
+
+`DataTeamPlayer_t` is 96 fields and splits gold 23 ways — hero kill, creep, neutral, summon, bounty, Roshan, building, courier, ward kill, ability, deny, comeback, income, shared — matching the 23-value `EDOTA_ModifyGold_Reason` enum one for one, with the four spending buckets and `m_iGoldLostToDeath` beside them. `CDOTA_PlayerResource` adds `m_playerAbilityUpgradeOrder` as `AbilityID_t[25][24]` and `m_playerAbilityUpgradeTimes` alongside it — the complete skill build for every slot *with timestamps* — plus a 24×24 hero-damage matrix and a 24×24 assist matrix. This is replay-parser-grade data available live from schema offsets.
+
+The engine also publishes things people normally reconstruct from replays: `m_fCreepDistanceSafe`/`Mid`/`Off` are per-team lane-equilibrium floats refreshed on their own timer, `m_flAvailableLaneGold` is a lane gold pool, and `CDOTAGameRules::m_hEnemyCreepsInBase` is literally a handle vector of creeps in your base. `CDOTA_NeutralSpawner` records `m_iStackingCreditPlayerID` and a per-team `m_bSeenClearedByTeam`, so camp analytics needs no heuristics. Every creep death carries `m_flTimeOfDeath`, `m_vWsKillOrigin` and `m_vWsKillDirection`.
+
+Reading is the strong direction. There is **no gold or XP mutator** at any usable tier (the only match is `CDOTATurboGameMode::FilterModifyGold`, experimental), so a plugin writes the ledger or tunes the passive knobs.
+
+#### Map, encounters and scripting
+
+`CDOTA_ScriptedSpawner` has a 22-method Pulse API — `SpawnNPC`, `SetNPCType`, `SetCustomNPCName`, `SetHealth`, `SetInvulnerable`, `SetNPCWaypoint`, `UseAbility`, `SetAutomaticallyRespawn` — backed by an 18-field entity with three IO outputs (`m_OnAllUnitsKilled`, `m_OnUnitKilled`, `m_OnHealthLow`). Around it: `CDOTA_MapTree_API` cuts and regrows individual trees, `CDOTA_SimpleObstruction_API` toggles blockers whose schema separately controls FoW-blocking versus nav-blocking, `CDOTA_BaseNPC_API` issues movement orders and speech bubbles, `CDOTA_BaseNPC_Building_API` pushes invulnerability refcounts. That is a fairly complete undocumented encounter-scripting system, and the whole map's tree state is one `uint64[256]` bitfield — 16,384 trees in 2 KB.
+
+The Pulse registry is self-documenting: all 500 Dota bindings are typed with parameter names and, for many, Valve's own English description read out of the binary. Note the tier is per-game, though — Dota's Pulse *runtime* entry points (`CPulseSystem::CreateInstance`, `CPulseGraphInstance::Unserialize`, `CPulseTypeManager::FindTypeByName`) are all experimental, where CS2 has `core` equivalents. The same trap applies to `CGameEntitySystem::AddEntityIOEvent`: `core` in CS2, experimental in Dota. Any sentence that says "core" about a shared engine symbol without naming the game is unsafe.
+
+`CLuaVM` comes out as a near-complete `IScriptVM` map — vtable slots 0 through 63, with `RegisterFunction`, `SetValue`, `CreateScope`, `LookupFunction`, `ExecuteFunction` and `RegisterScriptClass` all `verified` — so a native plugin can compile and run Lua into a live custom game, register C++ functions into the addon namespace, and redirect script output. Several slots carry an honest `mismatch` verdict (`GetRootTable`, `CreateTable`, `RegisterInstance`, `CScriptManager::CreateVM`): the slot index is good, the declaration is not. And `CBaseEntity_SharedAPI` exposes `RunScriptCode`, `CallScriptFunction` and `CallGlobalScriptFunction` as Pulse methods, so the two scripting systems bridge in both directions.
+
+For test rigs, all 107 `dota_*` commands share one `verified` prototype and a validated handler address, so a single ~20-line detour shim covers the whole rules console surface. 67 Dota commands carry `client_can_execute` with no cheat bit — including `dota_create_unit`, `dota_create_item`, `dota_spawn_creeps`, `dota_spawn_neutrals` and `dota_treerespawn` — which is simultaneously a modding shortcut and a server-hardening checklist.
+
+---
+
+### What the schema and prototypes add
+
+A flat offset dump cannot do any of the following, and each one is a real failure mode without it.
+
+**`bases` makes inherited fields reachable at all.** `CCSPlayerPawn` declares 104 fields and *none* of them is health, team, life state or move type. Walking the base chain to `CEntityInstance` flattens it to 297 and puts `m_iHealth` at 1456, `m_iTeamNum` at 1572, `m_lifeState` at 1464. The same walk turns a map classname into a field table: `trigger_multiple` goes from 1 own field to 158 flattened.
+
+**`bases` is also the only place multiple inheritance is expressed.** Treating a `CEconEntity` as `IHasAttributes` requires adding 3,136 bytes; for `CChicken` it is 3,728. In Dota, 16 ability classes carry a second base at +2144 — `CDOTA_Ability_Morphling_Waveform` and friends inherit `CHorizontalMotionController` there, `CDOTA_Ability_DataDriven` inherits `CDOTA_ActionRunner`. A naive `(Base*)ptr` cast at any of these sites corrupts memory silently.
+
+**`enums` recovers field width, not just readability.** 812 CS2 fields report `size: 0`; the enum's own size is what makes them decodable. `CBaseEntity::m_MoveType`, `m_nPreviouslySetMoveType` and `m_nActualMoveType` sit at 1491/1492/1493 and are only three consecutive `u8`s because `MoveType_t` is one byte wide. Beyond that, 555 CS2 enums / 743 Dota give you the legal-value tables — damage-type bitmasks, hit groups, observer modes, and on Dota the entire gameplay vocabulary.
+
+**`types` gives size and SysV class.** Size turns every generated accessor into a bounds check (12,330/12,330 CS2 fields pass). SysV class is what stops a struct-return call from corrupting the stack: a 12-byte `Vector` comes back in XMM registers (`sse`), a 48-byte `matrix3x4_t` through a hidden pointer (`memory`). That is what makes `CBaseEntity::GetEyePosition` callable correctly.
+
+**A field's `name_hash` is stable across builds *and* across games.** 10,363 `Class::field` pairs exist in both artifacts; all 10,363 have identical hashes, and 2,589 of them sit at different offsets. So ship one hash-keyed table of the fields your plugin touches and bind offsets per build and per game at load. A hash that vanishes means a rename; a hash that moves means a rebind.
+
+**A checked prototype is worth more than a declared one, and the verdict is the product.** `verified` (2,054 CS2 / 3,633 Dota) means declared arity matches the footprint measured in this build. `lower-bound` (82/99) means the declaration passes registers the callee never reads — compatible, but not the same claim. **`mismatch` (55/44) is arguably the most valuable output in the file**: it names community-circulated prototypes that are wrong for this binary and will load the wrong registers. `ambiguous` lists the surviving overloads for you to separate; `return-only` gives a return type and no arity claim; `unverified` means nothing checked it.
+
+Two structural cross-checks worth knowing about because they cost you nothing: all **226 CS2 entity outputs agree exactly with netvars** on class, member and byte offset, independently derived; and for all 759 CS2 commands present in both files, the dispatch form in `bindings` agrees with the prototype in `abi` — 674 `direct`, 81 `member` (extra leading `this`), 4 `interface`, zero disagreements. Hooking a member-form command with the free-function signature shifts every argument by one, and nothing in the command's name tells you which it is.
+
+---
+
+### The experimental band — read this before using any of it
+
+`experimental` is 4,374 entries on CS2 and 5,947 on Dota, and it is a different kind of artifact from everything above.
+
+**Resolvable locator. Unverified name. Never live-validated.** Every entry has `validated: null`, `corroboration: bare` (one source, nothing independently agreed) and `self_named: false`. What is real is the *locator* — an RTTI class plus vtable slot, or a byte signature — and the *measured register footprint*, which every entry carries. What is a guess is the label. 270 CS2 / 357 Dota entries carry `collision: true` (another guessed name resolved to the same target) and 42 / 150 carry `dead_weight: true` (the target is a stub).
+
+The two games' bands are not the same product. CS2's is 3,230 vtable locators across 914 RTTI classes plus 1,144 byte signatures across 21 libraries — and **zero in `libserver`**. It is engine infrastructure: `CPhysicsBody`, `CVPhys2World`, `CEngineServer`, `CServerSideClient`, `CNetChan`, `CCvar`, `CSchemaSystem`. If the names are right, that is a whole telemetry, physics and cvar surface — `CNetChan::GetAvgLatency` at slot 11 measures `{int:1, ret=float}`, which is at least the shape of a `float GetX() const`. If they are wrong, you have called a numbered slot with the wrong idea of what it does. Anyone hunting there for an unnamed `CCSPlayerPawn` method will not find it.
+
+Dota's band *does* reach gameplay: 1,402 byte signatures in `libserver`, roughly 350 of them DOTA-named — `CDOTAGameRules::KillCreeps`, `CDOTATurboGameMode::FilterModifyGold`, `CDOTA_Ability_*::OnSpellStart`. If those names are right it is a gold mine for custom-game work. Treat every one as a hypothesis.
+
+One sub-band is genuinely self-checking and worth calling out: the `CNetMessagePB<id, MessageType, (SignonGroup_t)g, …>` template instantiations bake a wire id, a protobuf class name, a signon group and a reliability flag into the mangled name. Unlike a bare `CFoo::Bar` guess, that is structured data you can falsify against live traffic in one command (`net_listallmessages`, `net_messageinfo`). Note that for Dota the *authoritative* message-id source is not this band at all — it is the schema enums `EDotaUserMessages`, `EBaseUserMessages` and `EDotaClientMessages`, which are deterministic. Use those for ids and the templates as corroboration.
+
+The only defensible workflow for anything in this band: pick a candidate, check the measured footprint matches the semantics you expect, then confirm behaviour in-engine yourself before shipping.
+
+---
+
+### What is not covered
+
+- **No ConVars, in either game.** Commands only. No `sv_*`/`mp_*`/`dota_*` tunables, no defaults, no flags, no ranges.
+- **No protobuf field layouts.** You get message ids and class names; you must supply the `.proto` definitions.
+- **No game-event name tables.** The event *system* is there (post, register, the legacy bridge); the names (`player_death`, `dota_player_gained_level`) are not. On CS2 the practical substitutes are function-level equivalents and `logic_gameevent_listener`, which needs only a string.
+- **No content names.** No `.vpcf` particle systems, no sound events, no model paths, no Dota KeyValues gameplay data (no ability special values, no hero base stats, no item costs).
+- **Server-side only.** Neither game's artifacts contain a `client` library. No Panorama, no client prediction, no client-side anticheat surface.
+- **Linux x86-64 only.** Every signature object carries exactly `{library, linux}`.
+- **Some struct types are named but not laid out** — `CMoveData`, `CUserCmd`, `Ray_t`, `trace_t`, `InputData_t`, `Variant_t`, `EmitSound_t`, `SpawnGroup_t`. They appear in verified prototypes; you can pass pointers through them and cannot construct or inspect them from these files.
+- **Bitfield netvars are unusable.** 52 CS2 / 122 Dota fields typed `bitfield:N` all report offset 0 and size 0 — the name is there, the location is not.
+- **Nothing marks a field as networked.** A field entry is `{offset, type, kind, size, name_hash}`; there is no replicated/server-only distinction, so send-table-aware tooling is out of scope.
+
+---
+
 ## How it works
 
 Six stages: **read → derive → locate → measure → validate → emit.** The organising distinction, which everything else hangs off: