{
  "ActionBase": "A user action: the HUD prompts shown when the player looks at something usable. Register one from `ItemBase.SetActions` with `AddAction`. Conditions run on both client and server — the client to show the prompt, the server to validate — so they must be side-effect free.",
  "ActionBase.ActionCondition": "Runs on both the client (to show the prompt) and the server (to validate), repeatedly while relevant — keep it fast and pure. `target` describes what the crosshair hit; it can be empty for self-targeted actions.",
  "ActionBase.CreateConditionComponents": "Declares the reach and visibility checks (`m_ConditionItem`, `m_ConditionTarget`) the engine evaluates before `ActionCondition` is even asked. `CCTObject`, `CCTSelf`, `CCTNone` and friends are the vocabulary.",
  "ActionBase.OnStartServer": "Server-side hook when the action begins. For a single-use action this is usually where the work goes; a continuous action does its real work in `OnFinishProgressServer` when the hold completes.",
  "ActionContinuousBase": "Hold-to-perform action (bandaging, drinking). Completion logic belongs in `OnFinishProgressServer`; per-tick behavior lives in the `ActionContinuousBaseCB` callback class the constructor names.",
  "ActionContinuousBase.OnFinishProgressServer": "The server-side payoff of a continuous action — runs only when the hold actually completed. Cancelled holds never reach it.",
  "ActionInteractBase": "Press-to-interact world action (open a door, flip a switch): no item required, no progress bar.",
  "ActionSingleUseBase": "One-press action with an animation (eating a pill, switching a light). The server-side effect usually goes in `OnStartServer`.",
  "ActionTarget": "What the player's cursor selected when the action ran: `GetObject()` is the entity, `GetCursorHitPos()` the world position. Can be empty for self-targeted actions.",
  "AnimalBase": "Deer, boars, wolves, bears. The AI brain is engine-side like the infected’s; script-side, `EEHitBy` and `EEKilled` are where damage tweaks and custom loot go.",
  "BaseBuildingBase": "Fences, watchtowers and their kin. Each build stage is a construction part defined in the item's config; the `Construction` component toggles parts server-side and syncs the visuals to clients.",
  "Building": "Script surface of the config `land_*` buildings (`HouseNoDestruct` descendants): door state is server-authoritative and driven by the config's `Doors` class. Two config pitfalls from the official wiki: `initOpened` is the chance a door starts open, and doors that swing outside the model's bounding sphere stop answering action raycasts and bullets unless a `bounding` memory selection widens it. To have CE persist a `HouseNoDestruct`, set `storageCategory = 1` (`SC_dynamic`), `scope = 2`, and a `types.xml` entry.",
  "CEApi": "The Central Economy's debug and export toolbox, reached with the global `GetCEApi()`. Script twin of the diag menu's Central Economy section: the `Loot*` visualisation and volume-editing toggles, `SpawnAnalyze`/`EconomyMap` spawn projections, and the `*Export*` calls that write mapgroupproto, mapgrouppos and cfgeventspawns XML into `storage/export`. Most of it is diag-executable only, in a single-player session with CE running.",
  "CGame": "The engine facade behind the global `GetGame()`. Almost everything a mod does starts here; in the actual game it is a `DayZGame`, already cast as the global `g_Game`.",
  "CGame.AdminLog": "Appends a line to the admin log — the `.ADM` file in the profiles folder, which only exists when the server runs with `-adminlog`. The vanilla lines come from `PluginAdminLog`; connect, chat and `#toadmin` report entries are written engine-side and cannot be modded.",
  "CGame.ConfigGetFloat": "Reads a float from config by space-separated path: `ConfigGetFloat(\"CfgVehicles MyItem weight\")`. Returns 0 for a missing entry — pair with `ConfigIsExisting` when 0 is a meaningful value.",
  "CGame.ConfigGetText": "Reads a config string by space-separated path into the out parameter and returns whether the entry existed: `GetGame().ConfigGetText(\"CfgVehicles \" + GetType() + \" displayName\", name)`.",
  "CGame.ConfigIsExisting": "Whether a config path exists, using the same space-separated path syntax as the other `Config*` calls. The cheap way to feature-test another mod's config from script.",
  "CGame.CreateObject": "Prefer `CreateObjectEx` with explicit `ECE_` flags — this boolean tail is a legacy shorthand for a few of them. `create_local = true` spawns the object only on the calling machine: no network sync, no persistence.",
  "CGame.CreateObjectEx": "Server-side spawning with explicit `ECE_` flags: `ECE_PLACE_ON_SURFACE` for ground loot, `ECE_LOCAL` for client-only props, `ECE_NOLIFETIME` and the `ECE_NOPERSISTENCY_` flags to control cleanup and saving.",
  "CGame.CreatePlayer": "Server-side: spawns a character entity for the identity at a position — the heart of custom spawn and respawn logic. Vanilla pairs it with `SelectPlayer` to hand the client its new body; `MissionServer.OnClientNewEvent` is where that happens.",
  "CGame.GetCallQueue": "`CALL_CATEGORY_SYSTEM` always runs, `CALL_CATEGORY_GUI` runs on clients, and `CALL_CATEGORY_GAMEPLAY` pauses while the in-game menu is open — schedule must-run logic on SYSTEM. See `ScriptCallQueue.CallLater` for the workhorse.",
  "CGame.GetCurrentCameraDirection": "The look vector of the active camera. Hipfire and free-look traces use this (`origin + GetCurrentCameraDirection() * range`); ADS traces the barrel instead — `konec hlavne` to `usti hlavne` via `Object.GetSelectionPositionMS`.",
  "CGame.GetMission": "The running mission — cast it to `MissionServer` or `MissionGameplay` depending on side. The usual bridge from anywhere in script to mission-level state and, on clients, the HUD.",
  "CGame.GetObjectsAtPosition": "Fills the out arrays with every object in a circle around a position. Expensive on a hot path — prefer a static list of what you care about, a trigger, or the `DayZPlayerUtils` scene/physics box queries when you only need nearby entities of a known kind. `GetObjectsAtPosition3D` is the sphere variant of the same call.",
  "CGame.GetPlayers": "Server-side: fills the array with every connected player character. Clients cannot enumerate other players — don't expect a full list there.",
  "CGame.GetTickTime": "Seconds since game start as a float — the finer-grained sibling of `GetTime()`, handy for profiling and frame-time math.",
  "CGame.GetTime": "Mission time in milliseconds, monotonic since mission start. Good for cooldowns and timing; unrelated to the in-game calendar clock.",
  "CGame.GetWaterDepth": "Depth below the water surface at a world position: positive means submerged, negative means clear of it — vanilla's boat and swimming code reads it that way. Prefer this over `SurfaceIsPond`/`SurfaceIsSea` when you only need to know whether a point is in water.",
  "CGame.GetWorkspace": "The root widget factory: `GetGame().GetWorkspace().CreateWidgets(...)` instantiates a layout file. Client-side only — a dedicated server has no UI workspace.",
  "CGame.IsClient": "True on a client connected to a multiplayer server. In offline single player both this and `IsMultiplayer()` are false, which is why client-side code is usually gated with `!GetGame().IsDedicatedServer()` instead.",
  "CGame.IsDedicatedServer": "True only in the dedicated server binary. The common client guard `!GetGame().IsDedicatedServer()` also covers offline play, where `IsClient()` would be false.",
  "CGame.IsMultiplayer": "Distinguishes a network session from offline single player. The classic guards: `IsServer() && IsMultiplayer()` for dedicated-server-only code, `IsClient()` for connected clients.",
  "CGame.IsServer": "True where the authoritative simulation runs: on dedicated servers and in offline single player alike. `IsServer() && IsMultiplayer()` is the test for a real dedicated server.",
  "CGame.ObjectDelete": "The safe way to remove an entity: queues the deletion instead of destroying mid-frame. Call it on the server for synchronized objects — clients drop their copies automatically.",
  "CGame.RPC": "Script-to-script networking: sent from a client it executes on the server; sent from the server it executes on clients — all of them unless `recipient` narrows it. Receive by overriding `OnRPC` on the target object (call `super.OnRPC` first). `rpcType` is any int you pick; stay clear of the built-in `ERPCs` values. Treat every client-sent payload as already exploited: check on the server that the action is allowed before you apply it.",
  "CGame.RPCSingleParam": "`RPC` for exactly one `Param`: `GetGame().RPCSingleParam(player, MY_RPC_ID, new Param1<float>(0.5), true, player.GetIdentity())`. Read it back with `ctx.Read(p)` inside `OnRPC` on the other side.",
  "CGame.SurfaceIsPond": "Whether that XZ lands in a pond. Undocumented and reported slow for per-frame or per-player checks — same for `SurfaceIsSea` and `SurfaceRoadY`. For a water test, use `GetWaterDepth(pos)` instead (positive = submerged).",
  "CGame.SurfaceY": "Terrain height only — roads, buildings and other objects are invisible to it. For the ground under a point including objects, raycast instead (`DayZPhysics.RaycastRV`).",
  "CarScript": "Every drivable vehicle. Fluids, engine state and part damage live here; the driving physics are engine-side and simulate on the server, which is why laggy vehicles rubber-band.",
  "CfgGameplayHandler": "Typed access to the `cfggameplay.json` server config. The file only applies when `enableCfgGameplayFile = 1` is set in `serverDZ.cfg`; every getter here mirrors one json field.",
  "CfgGameplayHandler.GetDisallowedTypesInUnderground": "The kit typenames blocked from construction underground by `disallowedTypesInUnderground` in `cfggameplay.json` — fence, territory-flag and watchtower kits by default. The check includes inherited config classes, so subclasses of a blocked kit are blocked too.",
  "CfgGameplayHandler.GetLightingConfig": "Night lighting preset: 0 bright, 1 dark, 2 Sakhal-specific. When `cfggameplay.json` is enabled this value wins over `lightingConfig` in `serverDZ.cfg` — edit the json, not the cfg.",
  "CfgPlayerRestrictedAreaHandler": "Loads the JSON volumes listed in `playerRestrictedAreaFiles` in `cfggameplay.json` (vanilla ships `pra/warheadstorage.json`): server-side areas players are kept out of, configurable without touching `init.c`. Each file is a `PlayerRestrictedAreaInstance`: the zone plus `safePositions2D`/`safePositions3D` teleport targets.",
  "ComponentEnergyManager": "The battery and power system behind flashlights, radios and base electricity: energy, plugs, and the switched-on state machine. Reach it with `GetCompEM()` on any entity whose config defines an `EnergyManager` class.",
  "Construction.BuildPartServer": "The authoritative build/dismantle entry point. Three of its server checks can be switched off from `cfggameplay.json` — `disablePerformRoofCheck`, `disableIsCollidingCheck`, `disableDistanceCheck` — handy for event maps, risky on live servers.",
  "Container_Base": "Backpacks, barrels, crates — items that exist to hold cargo. The cargo itself is ordinary `GameInventory`; subclasses mostly add open/close state and rules for what fits.",
  "ContaminatedArea_Static": "The static gas zones, read from `cfgEffectArea.json` in the mission folder and created at mission start. They are never persisted, so zones can be added or removed between restarts with no wipe; an empty `{}` file disables them entirely. Dynamic gas zones are CE dynamic events instead.",
  "ContaminatedTrigger": "The trigger a gas zone names in `TriggerType`. The `PlayerData` particles and camera tint from `cfgEffectArea.json` only run while a player is inside the trigger — a zone without one is visuals only.",
  "DayZGame": "The concrete `CGame` the game runs. `GetGame()` returns it, and the global `g_Game` is the same object already cast — no `DayZGame.Cast` needed.",
  "DayZGame.Event_OnRPC": "A `ScriptInvoker` fired for every RPC that reaches this machine — subscribe to listen without overriding anything: `GetDayZGame().Event_OnRPC.Insert(OnRPCReceived)`.",
  "DayZInfected": "The engine layer of the infected. Script logic lives on `ZombieBase`, the scripted subclass every infected actually is — `modded class ZombieBase` is the entry point, not this.",
  "DayZPhysics.RaycastRV": "The workhorse raycast: begin and end position in, contact point and direction out, flags for what counts as a hit. Each side casts against its own world — client and server results can disagree.",
  "DayZPlayer.CameraHandler": "Picks which player camera runs for `pCameraMode` (`DayZPlayerConstants.CAMERAMODE_*`). Override it to return a `DayZPlayerCameras.DAYZCAMERA_*` id — vanilla uses this for ironsights, optics, vehicles and unconscious.",
  "DayZPlayer.CommandHandler": "The heart of player simulation, running every tick on the server and the owning client. Animation commands (`StartCommand_*`) may only be issued from inside it — calling them elsewhere is the classic source of command glitches.",
  "DayZPlayerConstants": "The grab-bag enum of the player command system: stance indices (`STANCEIDX_`), command ids (`CMD_`), and the `DEBUG_` toggles the player implement checks. Referenced constantly inside `CommandHandler` code.",
  "DayZPlayerImplement": "The layer between the engine's `DayZPlayer` and gameplay's `PlayerBase`: animation commands, weapon lifting, fall damage, death handling. Overrides here run inside the player simulation loop on both server and owning client.",
  "DayZPlayerImplement.CameraHandler": "Vanilla camera selection: optics, ironsights, 1st/3rd, vehicle and unconscious. Override and return a `DayZPlayerCameras.DAYZCAMERA_*` constant; fall through to `super` for everything you do not handle.",
  "DayZPlayerSyncJunctures": "Reliable server-to-owning-client player messages, applied inside the player's own simulation step — unlike a plain RPC, which lands whenever it lands. This is how shock, stagger and similar effects stay in step with animation.",
  "DayZPlayerUtils": "Static toolbox for player and entity queries. `SceneGetEntitiesInBox` and `PhysicsGetEntitiesInBox` are the standard answers to finding what is near a position; vanilla uses them for every proximity check.",
  "DiagMenu": "Engine API for the debug overlay in `DayZDiag_x64.exe` — the retail client never shows it. Open with Win+Alt in a 3D viewport. Register items with `RegisterMenu`, `RegisterBool` and `RegisterRange`; IDs must not collide with `DiagMenuIDs`. Mods should hook `PluginDiagMenu.RegisterModdedDiagsIDs` / `RegisterModdedDiags` rather than calling this from a random init.",
  "DiagMenuIDs": "Vanilla diag-menu ID space. Do not reuse these values — claim a new one with `PluginDiagMenu.GetModdedDiagID`.",
  "EClientKicked": "The kick reasons behind the 0x0004xxxx disconnect errors — from SERVER_EXIT through the LoginMachine, verification and Steam auth families to BATTLEYE. The official wiki's DayZ:Error Codes page decodes each value with its player-facing message.",
  "ERPCs": "The built-in RPC ids. A custom RPC just needs an int that does not collide with these — the common pattern is a const block of your own ids well above this range.",
  "EStatLevels": "The five bands a player stat reads back as, `GREAT` down to `CRITICAL` — the resolution the HUD badges and many modifiers work at.",
  "Edible_Base": "Everything eatable or drinkable. Food state (raw, baked, boiled, dried, burned, rotten) lives in `FoodStage`; nutrition and agents come from config; cooking is driven by item temperature.",
  "EffectArea": "Base of the gas-zone family (`ContaminatedArea_*` and kin): the trigger, the particle field and the PPE requester that tints the camera inside. Since 1.28 the particles are laid out by `FillWithParticles` circle packing instead of the old `PlaceParticles` rings — reverting a zone means overriding `InitZoneClient` back to `PlaceParticles`.",
  "EffectArea.FillWithParticles": "The 1.28+ particle layout: packs emitters across the area, spaced by `partSize` (perceived particle size), with `outwardsBleed` letting particles show past the radius. Clamped to 1000 emitters per zone — every emitter costs client performance.",
  "EffectSound": "A playing sound effect, client-side only — the dedicated server has no audio. Created via `SEffectManager.PlaySound`; call `SetAutodestroy(true)` for fire-and-forget one-shots, or keep a reference and stop it yourself.",
  "EmoteConstructor": "Builds the emote table in `ConstructEmotes`. A custom emote is an `EmoteBase` subclass that a modded override registers there, with its id and input wiring beside it.",
  "EntityAI.AfterStoreLoad": "Runs after every entity in storage has loaded — the safe place for logic that needs other entities (attachment fixups, cross-references), which `OnStoreLoad` is too early for.",
  "EntityAI.EEDelete": "Called when the entity is being deleted, on both server and client. `parent` is the inventory parent when it was attached or in cargo. Be careful spawning replacements from here — you are mid-deletion.",
  "EntityAI.EEHealthLevelChanged": "Damage-state transitions: levels run `GameConstants.STATE_PRISTINE` (0) through `STATE_RUINED` (4), per zone, with `zone` empty for global health. Fires on both server and client — the usual place to swap models or textures as an item degrades.",
  "EntityAI.EEHitBy": "Server-side, after the damage is applied. `damageResult.GetDamage(dmgZone, \"Health\")` for the amount, `source` for what dealt it (walk `GetHierarchyRootPlayer()` to find the attacker), `ammo` for the damage type string from config. Always call `super.EEHitBy(...)`.",
  "EntityAI.EEInit": "Runs once the entity exists and its config is applied — on server and client both, before any storage load. Prefer it over the constructor for logic that needs config values or a world position.",
  "EntityAI.EEItemAttached": "Fires on the parent when something lands in an attachment slot — on server and client, including initial spawns and storage load, so don't assume a player did it. The item's own side of the event is `ItemBase.OnWasAttached`.",
  "EntityAI.EEItemDetached": "The counterpart of `EEItemAttached`, with the same caveats: both sides, and also during entity teardown. Slot names arrive spelled as in config.",
  "EntityAI.EEKilled": "Server-side, once, when the entity dies. `killer` is the direct source of the lethal hit — cast it and walk `GetHierarchyRootPlayer()` to reach the player behind a weapon. Null-check everything: the killer may already be gone.",
  "EntityAI.EEOnCECreate": "Server-side, and only when the Central Economy (or a debug spawn) creates the entity brand new — not on storage load after a restart. The right place to randomize quantity, health or attachments of world loot.",
  "EntityAI.GetCompEM": "The entity's `ComponentEnergyManager`, or null when its config has no `EnergyManager` class. Guard it: `if (GetCompEM() && GetCompEM().IsWorking())`.",
  "EntityAI.GetHierarchyParent": "The inventory parent: a mag on a gun returns the gun, an item in cargo returns the container, null when the entity is loose in the world. Unrelated to `IEntity.GetParent()`, which is the scene-graph parent from `AddChild()` — a player in a vehicle has a `GetParent()` (the vehicle) and no hierarchy parent; the mag has the reverse.",
  "EntityAI.GetHierarchyRootPlayer": "Walks the inventory chain to the player at the top, null when no player holds it. The standard answer to whose pocket an item is in, however deeply nested.",
  "EntityAI.GetInventory": "The entity's `GameInventory`, or null for entities that have none. Attachments and cargo both live behind it; players additionally expose `GetHumanInventory()` for hands.",
  "EntityAI.OnStoreLoad": "Reads what `OnStoreSave` wrote, in the same order — one misread desyncs the rest of the stream. Call `super.OnStoreLoad(ctx, version)` first, return false on failure (which deletes the entity), and use `version` to migrate saves from older storage versions.",
  "EntityAI.OnStoreSave": "Server-side persistence: call `super.OnStoreSave(ctx)` first, then `ctx.Write(...)` your state. Whatever you write, `OnStoreLoad` must read back exactly — same types, same order — or every field after the mismatch loads garbage.",
  "EntityAI.OnVariablesSynchronized": "Client-side: fires when a batch of net-sync variables arrives, including once shortly after the entity appears on the client. Compare against your previous values if you need to know what changed.",
  "EntityAI.OnWork": "The powered device’s tick, server-side, while switched on and fed: `consumed_energy` is this update’s draw. Updates arrive on the energy manager’s schedule, not every frame.",
  "EntityAI.OnWorkStart": "Energy manager event, server-side, once as the device begins working — light it, start the loop, flip the visuals. `OnWorkStop` is where it all comes down again.",
  "EntityAI.OnWorkStop": "Switched off or out of power, server-side. Undo whatever `OnWorkStart` set up; state worth keeping should be read off `GetCompEM()` rather than mirrored in flags.",
  "EntityAI.RegisterNetSyncVariableFloat": "Same flow as the int variant, plus `precision` — digits after the decimal that survive quantization, default 1, so a float synced with defaults arrives rounded to one decimal. `minValue == maxValue` disables quantization.",
  "EntityAI.RegisterNetSyncVariableInt": "Register in the constructor (both sides construct the entity). The server changes the member and calls `SetSynchDirty()`; clients receive it in `OnVariablesSynchronized()`. `minValue`/`maxValue` quantize to save bandwidth — values outside the range don't survive the trip.",
  "EntityAI.SetLifetime": "How long the Central Economy lets this instance lie unattended before cleanup, in seconds, server-side. Player interaction resets the clock; `SetLifetimeMax` moves the ceiling itself.",
  "EntityAI.SetSynchDirty": "Marks the entity's registered net-sync variables for transmission — server-side, multiplayer only, cheap to call. Nothing syncs until you call it, which is the most common reason a net-sync variable never arrives.",
  "EntityEvent": "The bitmask `IEntity.SetEventMask` takes: which `EOn*` engine callbacks this entity wants delivered. Nothing arrives unrequested — an `EOnFrame` override without `EntityEvent.FRAME` in the mask never runs. Do not `super` those `EOn*` overrides: the original always runs.",
  "Environment": "The per-player environment simulation: heat comfort from clothing insulation, wetness, wind and nearby heat sources — what the HUD temperature arrows reflect. Simulated per player on the server.",
  "ErrorCategory": "Which error module owns a failure: the 0x0001 connect errors, 0x0002 server rejections, 0x0003 script-side and 0x0004 kicks each map to one enum — `EConnectErrorClient`, `EConnectErrorServer`, `EConnectErrorScript`, `EClientKicked`. The wiki's DayZ:Error Codes page decodes the full table.",
  "FoodStage": "The raw/baked/boiled/dried/burned/rotten state machine of `Edible_Base`. Transitions come from cooking temperature over time; each stage remaps the item's nutrition and agents.",
  "FreeDebugCamera": "The camera behind the diag menu's Free Camera: noclip flight that leaves the player standing where it took off, Enter links it to the targeted object, Insert teleports the player to the cursor. Diag executable only.",
  "GameConstants": "Where the magic numbers live: damage states (`STATE_PRISTINE` through `STATE_RUINED`), storage versions, environment and stamina tuning. Worth skimming before hardcoding any gameplay number.",
  "GameInventory": "The inventory of one entity: attachment slots, cargo, or both. Mutate it server-side (or through the player's `Predictive*`/`Local*`/`Server*` calls); clients mostly read.",
  "GameInventory.CanAddEntityIntoInventory": "Whether the entity fits anywhere in this inventory — any free slot or cargo space. Check it before a `CreateInInventory`-style call instead of cleaning up after a null.",
  "GameInventory.CreateInInventory": "Creates a new item of the given type in the first location it fits, attachment slots included. Returns null when nothing fits, so check it. Server-side for synchronized entities.",
  "Hive.IsIdleMode": "Whether the Central Economy is sleeping. On an empty server it enters idle mode after `IdleModeCountdown` seconds from `globals.xml` (60 by default); setting `IdleModeStartup` to 0 only skips idle mode at startup — the countdown can still engage later.",
  "Hologram": "The green/red placement ghost shown while positioning a deployable. It exists on the client for the preview and on the server for validation — placement rules you change must hold on both sides.",
  "Hologram.EvaluateCollision": "The placement validation itself, run on the client for the preview and again on the server for authority. Each check — bbox collision, player collision, roof clipping, slope, water — has its own `disable*` switch in `cfggameplay.json`'s `BaseBuildingData`; turning one off leaves the rest active.",
  "IEntity.EOnFrame": "Runs every frame with `timeSlice` as the delta — but only after `SetEventMask(EntityEvent.FRAME)` opted this entity in, which is the step everyone forgets. Do not call `super` in this or any other `EOn*` on `IEntity`: the original always runs, and `super` only adds extra calls. Vanilla does it in a few places; it is still wrong.",
  "IEntity.GetParent": "The scene-graph parent: whatever this entity was `AddChild()`'d to, otherwise null. A player sitting in a vehicle returns the vehicle. Not the inventory parent — that is `EntityAI.GetHierarchyParent()`. A mag on a gun has a hierarchy parent and no `GetParent()`.",
  "IEntity.SetEventMask": "Opts the entity into the `EOn*` callbacks named by `EntityEvent` bits; without the mask the overrides sit silent. Additive — `ClearEventMask` takes bits back off.",
  "IngameHud": "The vanilla HUD: badges, notifiers, stance and quickbar. Client-side, reached as `IngameHud.Cast(GetGame().GetMission().GetHud())` once the mission is up.",
  "InventoryLocation": "A slot address: ground, attachment slot, cargo cell, or hands, plus the parent it is relative to. The inventory API speaks these — `GetInventory().GetCurrentInventoryLocation(loc)` tells you where an item currently sits.",
  "Inventory_Base": "An empty `ItemBase` under the name plain item configs extend. A `CfgVehicles` class with no script class of its own runs as its nearest configured ancestor’s — for ordinary items, this one.",
  "ItemBase": "The scripted base of every inventory item; config classes reach it through `Inventory_Base`. New items subclass it (or a closer base like `Edible_Base`) and hook the `CanPut*`, `OnWas*` and action registration methods.",
  "ItemBase.AddQuantity": "Delta version of `SetQuantity` — same server-side rule, same destroy semantics when the result hits the minimum.",
  "ItemBase.CanPutInCargo": "Veto hook asked on both client (UI) and server (authority) — keep it pure, and always combine with the parent: `return super.CanPutInCargo(parent) && yourRule;`.",
  "ItemBase.CanReceiveItemIntoCargo": "The container's side of the question `CanPutInCargo` asks of the item. Both run; either can veto the move.",
  "ItemBase.OnCombine": "Server-side stack merge — pouring one stack into another. `other_item` is the source stack.",
  "ItemBase.OnItemLocationChanged": "Fires on the item for every move — ground, hands, cargo, attachment slot. `old_owner` and `new_owner` are the hierarchy roots on each end, and either can be null: the ground owns nothing.",
  "ItemBase.OnQuantityChanged": "After the quantity actually moved, with `delta` signed — the reactive mirror of `SetQuantity`, firing for consumption, combining and splitting alike.",
  "ItemBase.OnWasAttached": "Fires on the item itself after it landed in a parent's slot — the mirror of the parent's `EEItemAttached`. Also runs for spawn-time and storage-load attachment, not just player moves.",
  "ItemBase.OnWasDetached": "Mirror of `OnWasAttached` on the way out, with the same caveat about non-player causes.",
  "ItemBase.SetActions": "Where an item declares its user actions via `AddAction`. Called once per item type — keep `super.SetActions()` or every inherited vanilla action silently disappears.",
  "ItemBase.SetQuantity": "Server-side (`allow_client` exists for special cases). Clamps into the config quantity range; with `destroy_config` the item is destroyed at minimum only when config sets `varQuantityDestroyOnMin`, and `destroy_forced` destroys regardless. Returns true when the item got destroyed.",
  "Magazine": "Magazines and loose ammo alike — an ammo pile is a `Magazine` subclass whose ammo count is the pile size. Use `ServerSetAmmoCount` on the server; the `Local` variant skips synchronization.",
  "Man.GetIdentity": "The network identity of the account driving this character. Reliable only on the server, and null once the owner disconnects — logout-timer corpses are the classic null pointer in kill-log mods.",
  "Math.RandomInt": "`max` is exclusive: `RandomInt(0, arr.Count())` is the correct random-index idiom, and `RandomInt(0, 1)` only ever returns 0. Use `RandomIntInclusive` when you want both ends.",
  "MiscGameplayFunctions": "A pile of static helpers vanilla reaches for everywhere: `TurnItemIntoItem` to swap an item in place, quantity and health transfer between items, heading math. Check here before writing a utility yourself.",
  "MiscGameplayFunctions.TurnItemIntoItem": "The right way to replace an item with another type in place (worn variants, sharpening, painting): it carries location, quantity, health and attachments over through a replace lambda. Server-side.",
  "Mission.AddActiveInputExcludes": "Pushes named exclude groups (`menu`, `inventory`, …) so vanilla gameplay binds go quiet. Custom `UAInput`s keep firing unless you `ForceDisable(true)` each one and call `GetUApi().UpdateControls()`; reverse that in `RemoveActiveInputExcludes`. Client code usually overrides this on `MissionGameplay`.",
  "MissionGameplay": "The client-side mission: HUD, menus, input handling. Client mods extend it (`modded class MissionGameplay`) to poll keybinds in `OnUpdate` and open custom menus.",
  "MissionGameplay.AddActiveInputExcludes": "Pushes named exclude groups (`menu`, `inventory`, `radialmenu`, …) so vanilla gameplay binds go quiet. Custom `UAInput`s keep firing unless you `ForceDisable(true)` each one and call `GetUApi().UpdateControls()` when `excludes` contains the group; reverse that in `RemoveActiveInputExcludes`.",
  "MissionGameplay.OnKeyPress": "Raw key events on the client, `key` being a `KeyCode` value. Fine for debug shortcuts; for real, rebindable keybinds register input actions and read the input API instead.",
  "MissionGameplay.OnUpdate": "Every frame, client-side, menus included. The vanilla override is where keybind polling lives — keep additions light, this is a hot path.",
  "MissionGameplay.RemoveActiveInputExcludes": "Pops exclude groups added with `AddActiveInputExcludes`. If you `ForceDisable`d custom binds when `menu` went on, `ForceDisable(false)` them here and `UpdateControls()` again. `bForceSupress` skips the next frame of input.",
  "MissionServer": "The server mission — `init.c` returns one from `CreateCustomMission`, and `modded class MissionServer` is the standard hook for connect, disconnect and spawn logic. One instance for the whole session. Lifecycle: new character is `OnClientPrepare` → `OnClientNew` (vanilla `CreateCharacter`/`EquipCharacter`) → `InvokeOnConnect`; existing character is `OnClientPrepare` → `OnClientReady` → `InvokeOnConnect`; respawn inserts `OnClientRespawn` before prepare. Logout is `OnClientDisconnectedEvent`; a cancelled countdown is `LogoutCancelEventTypeID`. Disconnect is `PlayerDisconnected` then `InvokeOnDisconnect` if the character is still there.",
  "MissionServer.ControlPersonalLight": "Applies the `disablePersonalLight` setting: the faint proximity light every player carries at night. Server-side, from `cfggameplay.json` (or the `serverDZ.cfg` fallback) — unrelated to held light items.",
  "MissionServer.CreateCharacter": "Fresh-spawn character creation. When spawn-gear JSON is enabled, setting your own `characterName` here overrides the preset's `characterTypes`; leave character selection to `PlayerSpawnHandler` if the JSON should choose the survivor model.",
  "MissionServer.OnClientDisconnectedEvent": "After the logout countdown finishes (or auth failed), while the character still exists server-side. Last chance to persist anything about them.",
  "MissionServer.OnClientNewEvent": "A brand-new character is needed — a fresh spawn, not a reconnect. Vanilla picks a position, calls `CreateCharacter`, then equips it via `EquipCharacter` and `StartingEquipSetup`; overriding that last one is the easiest custom loadout.",
  "MissionServer.OnClientReadyEvent": "The player is fully loaded and in the world — the safest moment for on-join logic like welcome messages or syncing mod state to the client. Fires for fresh spawns and reconnects alike.",
  "MissionServer.OnEvent": "The raw client lifecycle stream (`ClientPrepareEventTypeID`, `ClientNewEventTypeID`, ...) that the friendlier `OnClient*Event` wrappers are dispatched from. Only needed when the wrappers don't cover your moment.",
  "MissionServer.StartingEquipSetup": "Called for fresh spawns after the character exists — the usual script hook for starting clothes and items. A non-empty `spawnGearPresetFiles` in `cfggameplay.json` replaces this path entirely, so use either this override or spawn-gear JSON for a loadout, not both.",
  "ModifierBase": "One status effect in the server-side modifier system (diseases, wound infection, drug effects): `OnActivate`, per-tick logic, `OnDeactivate`, each with its own tick rate. Lives in the player's `ModifiersManager`.",
  "ModifiersManager": "The server-side registry that ticks `ModifierBase` effects on a player. Get it with `player.GetModifiersManager()`; effects are activated and deactivated by modifier id.",
  "NotificationSystem": "The engine's toast popups. From the server, `SendNotificationToPlayerExtended(player, time, title, text, icon)` shows one on that player's screen — no custom RPC needed.",
  "Object.GetHealth01": "Health normalized to 0..1 of the zone's maximum — handy for bars and thresholds without reading config maxima.",
  "Object.GetOrientation": "Yaw, pitch, roll in degrees — `x` is yaw, not an X-axis rotation. `SetOrientation` takes the same convention; most tilted-object bugs are an XYZ assumption.",
  "Object.GetSelectionPositionMS": "A named model selection in model space. On guns the muzzle pair is `usti hlavne` (muzzle) and `konec hlavne` (breech): ADS rays go breech → muzzle; hipfire uses `GetGame().GetCurrentCameraDirection()` instead. `LS`/`WS` variants are local and world space.",
  "Object.GetType": "The config class name, via `CGame.ObjectGetType` — a different string from `ClassName()` (the script class). A `CfgVehicles` entry with no script of its own reports its own name here but its nearest scripted ancestor from `ClassName()`.",
  "Object.IsKindOf": "Inheritance test against the config hierarchy by class-name string — works for any config class, scripted or not. For script classes, a cast or `IsInherited(SomeType)` is the cheaper test.",
  "Object.OnSpawnByObjectSpawner": "Runs when the Object Spawner creates this entity, with the whole JSON entry — `customString` included — as the `ITEM_SpawnerObject`. Override it to make a spawner-placed object configurable; `StaticFlagPole` is the vanilla example, reading the flag to hoist from the string.",
  "Object.SetAllowDamage": "Passing false makes the object invulnerable — the god-mode switch, server-side. Remember it also blocks intended damage such as item wear.",
  "Object.SetHealth": "Empty strings target global health: `SetHealth(\"\", \"\", 0)` ruins or kills. Zones come from the config damage system; `healthType` is `Health`, `Shock` or `Blood`. Server-side for synchronized entities.",
  "Object.SetPosition": "Instant teleport, no physics sweep — call it on the server for synchronized entities. `PlaceOnSurface()` afterwards keeps things from floating or sinking into terrain.",
  "ObjectSpawnerHandler": "Server-side spawner behind `objectSpawnersArr` in `cfggameplay.json`: each listed JSON file adds objects (class name or p3d path, position, yaw–pitch–roll, scale) at mission start. `VALID_PATHS` limits p3d spawning to the `DZ/plants*` and `DZ/rocks*` trees; a name that resolves to nothing logs \"Object spawner failed to spawn\" in the RPT.",
  "ObjectSpawnerHandler.SpawnObject": "The `enableCEPersistency` JSON flag does not make the spawned object persistent immediately: it starts without CE persistence, then enables persistence after a player takes it if that type supports persistence. Large object-spawner lists cost both server and client performance.",
  "Particle": "Client-side effect playback: `Particle.PlayInWorld(ParticleList.MY_ID, pos)` or `PlayOnObject`. A dedicated server has nothing to draw — from server code, go through `SEffectManager`’s `*Server` helpers instead.",
  "ParticleList": "The id table `Particle.PlayInWorld` and `PlayOnObject` read: one constant per registered effect. Mods extend it with `modded class ParticleList`, which is how the sources themselves add to it.",
  "PlayerBase": "The survivor. Stats, modifiers, bleeding, emotes and the quickbar all hang off it, and `modded class PlayerBase` is the single most common mod entry point. It is constructed on both server and client, so gate side-specific init.",
  "PlayerBase.GetBleedingManagerServer": "Server-only — null on clients. Tracks each active bleeding source; clients only ever see the synced source count the HUD uses.",
  "PlayerBase.GetStatWater": "Server-side stats: `.Get()`, `.Set(value)`, `.Add(delta)`. Stats are not simulated client-side, so read and write them on the server (same for `GetStatEnergy` and the rest).",
  "PlayerBase.GiveShock": "Pass a negative value to inflict shock damage — vanilla comments say so explicitly. Enough accumulated shock knocks the player unconscious.",
  "PlayerBase.MessageStatus": "Server-side chat message to this player on the status channel (grey text). Siblings: `MessageImportant`, `MessageAction`, `MessageFriendly`. For popups use `NotificationSystem` instead.",
  "PlayerBase.OnConnect": "Server-side, as the owning client attaches to this character — fresh spawns and reconnects to a logout body alike. For “actually in the world”, `MissionServer.OnClientReadyEvent` is the later, safer moment.",
  "PlayerBase.OnDisconnect": "Server-side as the owner drops, with the logout timer still ahead of the character. `MissionServer.OnClientDisconnectedEvent` is the other end, once the countdown has run out.",
  "PlayerBase.OnScheduledTick": "The player's slow server-side tick, staggered across players to spread load — this is where stats and modifiers advance. `deltaTime` is the real seconds since this player's last tick, not a fixed rate.",
  "PlayerBase.PredictiveDropEntity": "The prefix convention for inventory ops: `Predictive*` runs client-side with prediction and server confirmation, `Server*` is authoritative, `Local*` skips sync entirely. Pick by where your code runs.",
  "PlayerBase.ProcessDrowning": "The server-side drowning tick: while the player's head is underwater it drains stamina, health and shock at the `DrowningData` rates from `cfggameplay.json` — 10 points per second each by default.",
  "PlayerIdentity": "The account behind a connected player: ids, name, ping. Obtained from `player.GetIdentity()` or the connect events; the getters are declared on `PlayerIdentityBase`.",
  "PlayerIdentityBase.GetId": "A hash of the platform id, stable per player and safe for databases and logs — the id most server tools key players by.",
  "PlayerIdentityBase.GetPlainId": "The raw platform id — Steam64 on PC. The engine docs warn against storing it in databases or logs; persist `GetId()` instead.",
  "PlayerIdentityBase.GetPlayerId": "Session-local numeric id, reused after disconnects — fine for addressing within one session, wrong as a persistent key.",
  "PlayerRestrictedAreaInstance": "One restricted-area JSON: `PRABoxes`/`PRAPolygons` are the keep-out zone, `safePositions2D`/`safePositions3D` are the teleport targets. List the file in `playerRestrictedAreaFiles` in `cfggameplay.json` (and enable that file in `serverDZ.cfg`).",
  "PlayerSpawnHandler": "Server-side preset loader enabled by a non-empty `spawnGearPresetFiles` array in `cfggameplay.json`. It replaces `MissionServer.StartingEquipSetup` and can replace the survivor chosen in the main menu; presets and their item variants are selected by `spawnWeight`, while an empty `characterTypes` keeps the menu's survivor model.",
  "PluginAdminLog": "Writes the `.ADM` admin log, server-side — hits, kills, placement and base building all pass through overridable methods here. The file needs the `-adminlog` launch parameter, and `serverDZ.cfg` gates what vanilla logs (`adminLogPlayerHitsOnly`, `adminLogPlacement`, `adminLogBuildActions`, `adminLogPlayerList`). Connect, chat and report lines are engine-side and out of reach; `CGame.AdminLog` appends custom ones.",
  "PluginBase": "A game-wide singleton service (recipes, admin log, lifespan, ...). Get any of them with the global `GetPlugin(PluginType)`; `OnInit` runs once when the plugin comes up.",
  "PluginDiagMenu": "Vanilla owner of the diag menu. Override `RegisterModdedDiagsIDs` to claim IDs via `GetModdedDiagID`, then `RegisterModdedDiags` to add items, and bind handlers on `PluginDiagMenuClient`. Does nothing on the retail exe.",
  "PluginKeyBinding": "Script-side registration of key bindings — the diag menu's script-bound shortcuts (free camera on Home, teleport on Insert, mouse toggle on LCtrl+NUM9) come through here, next to the C++-hardcoded \"cheat inputs\".",
  "PluginManager": "Creates and owns every `PluginBase` singleton, on server and client. The global `GetPlugin(typename)` is the front door.",
  "RecipeBase": "One handcrafting recipe: ingredients and results declared in `Init()`, extra conditions in `CanDo`, the server-side outcome in `Do`. Recipes are not auto-discovered — add yours in a modded `PluginRecipesManagerBase.RegisterRecipies` with `RegisterRecipe(new MyRecipe)`.",
  "SEffectManager": "Static manager for sounds and particles. Effects exist client-side only, but the `*Server` helpers (like `CreateParticleServer`) do the RPC round-trip for you. `PlaySound` returns an `EffectSound` — set `SetAutodestroy(true)` on one-shots.",
  "ScriptCallQueue": "The deferred-call scheduler behind `GetGame().GetCallQueue(...)`. `CallLater(fn, 1000, true, args)` is the standard timer idiom; it holds references to the arguments until the call runs, and `Remove(fn)` cancels.",
  "ScriptCallQueue.CallLater": "`delay` is in milliseconds; `repeat = true` makes an interval timer. On the `CALL_CATEGORY_GAMEPLAY` queue execution pauses while the in-game menu is open — use `CALL_CATEGORY_SYSTEM` for logic that must always run.",
  "ScriptInvoker": "A multicast callback list: `Insert(handler)` to subscribe, `Invoke(args)` to fire. The engine and vanilla expose many as `Event_*` members — subscribing beats overriding when you only need to observe.",
  "ScriptModule": "A compiled script unit. Vanilla loads five in order (`1_Core` through `5_Mission`). `LoadScript` compiles an extra file against a parent module; `Call` / `CallFunction` run names inside it. `modded` does not apply to classes already compiled in another module.",
  "ScriptModule.LoadScript": "Compiles `scriptFile` as a new module parented to `parentModule`. On the retail client this has been a no-op since 1.24; it still works on the diagnostics exe and the dedicated server. Workbench and offline loaders use it — a signed multiplayer session will not pick up extra client scripts this way.",
  "ScriptRPC": "The write-your-own-payload RPC: `Write(...)` the params, then `Send(target, id, guaranteed, recipient)`. From a client it executes on the server; from the server it goes to all clients unless `recipient` narrows it. `Send` does not clear the buffer — call `Reset()` before reuse.",
  "ScriptedLightBase": "Dynamic lights from script: subclass it, set radius, brightness and colour in the constructor, spawn with `ScriptedLightBase.CreateLight(MyLight, pos)`. Client-side only — a dedicated server has nothing to light, and `CreateLight` returns null there on purpose.",
  "ScriptedLightBase.CreateLight": "Spawns the light at `global_pos`, or returns null on a dedicated server. Call it from client (or offline) code; never from the server in multiplayer.",
  "ScriptedWidgetEventHandler": "Subclass it, override `OnClick`, `OnChange`, `OnMouseEnter` and friends, then attach with `widget.SetHandler(this)`. Return true from a handler to consume the event.",
  "Serializer": "The read/write stream behind persistence and RPC — `ParamsReadContext` and `ParamsWriteContext` are typedefs of this class. The golden rule everywhere it appears: reads must match writes in type and order, exactly.",
  "StaticFlagPole": "The pre-built, non-dismantlable flag pole. Also the vanilla example of Object Spawner `customString` handling: its `OnSpawnByObjectSpawner` reads the string as the flag type to hoist on spawn.",
  "SurvivorBase": "Config class every survivor model inherits (`class SurvivorBase: Man`). To attach proxies to bones that vanilla does not expose, add `DayZPlayer.P3DAttachments` with matching `P3DProxies[]` and `BoneNames[]` — prefer every character bone from `model.cfg` so other mods keep working — and list `DZ_Characters` in `requiredAddons`.",
  "Timer": "Must be held in a `ref` member — a local or unreferenced `Timer` is garbage-collected and silently never fires, the most common timer bug. For most cases `GetGame().GetCallQueue(...).CallLater(...)` is the simpler tool.",
  "TotalDamageResult": "What the damage system hands to `EEHitBy`: `GetDamage(zone, healthType)` with `Health`, `Shock` or `Blood` as the type and an empty string for the global zone.",
  "TrapBase": "Bear traps, land mines, tripwires. `StartActivate` begins arming and `OnSteppedOn` is the spring, server-side; each concrete trap tunes damage, timing and what counts as a victim.",
  "UAInput.ForceDisable": "Silences this bind regardless of the current exclude group. Custom actions still fire while `menu` is excluded unless you force-disable them in `MissionGameplay.AddActiveInputExcludes` and undo that in `RemoveActiveInputExcludes`, then `GetUApi().UpdateControls()`.",
  "UIManager": "The client-side menu stack. `EnterScriptedMenu(id, parent)` opens a registered menu by its `MENU_*` id; `ShowScriptedMenu(instance, parent)` shows an instance directly — custom menus usually take that route with their own id above the vanilla range.",
  "UIScriptedMenu": "One scripted menu: build and return the widget tree from `Init()`, say whether it wants the cursor via `UseMouse` and `UseKeyboard`, and open it through `UIManager`. Custom menus take an id above the vanilla `MENU_*` range.",
  "UndergroundHandlerClient": "Client-side half of `cfgundergroundtriggers.json`: interpolates eye accommodation from triggers and breadcrumbs and fades underground ambience. Outer triggers also let normally night-only lights such as chemlights work in daylight near entrances; DayZDiag can show breadcrumbs or disable darkening with Ctrl+F.",
  "UndergroundTrigger": "One trigger from `cfgundergroundtriggers.json`, driving eye accommodation (the simulated darkness) and ambience as players go below. Its type is inferred from the data: breadcrumbs make it Transitional, no breadcrumbs is Outer when `EyeAccommodation` is 1 and Inner otherwise. The diag menu's Script > Underground Areas visualises triggers and breadcrumbs.",
  "Weapon.Fire": "The server-side fire call. On the owning client the weapon FSM fires through `TryFireWeapon` instead, and that has to run synchronously from the FSM — not from a random tick or RPC. Do not call `Fire` from client script expecting it to shoot.",
  "Weapon_Base": "Firearms. The firing cycle is a script-side state machine — `WeaponFSM` and its weapon events — rather than simple overridable methods: chambering, jams and reloads are all states. Ammo lives per muzzle as chamber plus attached `Magazine`. Server shots go through `Weapon.Fire`; the client path is `TryFireWeapon` from inside the FSM.",
  "Weather": "Reached via `GetGame().GetWeather()`. Each phenomenon (`GetOvercast()`, `GetRain()`, `GetFog()`) interpolates toward a forecast you set — see `WeatherPhenomenon.Set`. Change it on the server; it syncs to clients.",
  "Weather.MissionWeather": "Pass true from mission `main()` to take weather away from vanilla's scripted state machine and control it manually through the Weather API. For ordinary server tuning Bohemia recommends `cfgweather.xml`; use this when code must own every transition.",
  "WeatherPhenomenon.Set": "`Set(forecast, time, minDuration)`: reach `forecast` (0..1) over `time` seconds, then hold it at least `minDuration` seconds before the engine may drift it again. `Set(1, 0, 3600)` is an instant hour-long storm.",
  "Widget.FindAnyWidget": "Finds a descendant widget by the name given in the `.layout` file, at any depth. Returns null quietly — check it, and cache lookups instead of searching every frame.",
  "Workbench": "The script API for the Enforce Workbench. `Print` in its output window accepts a subset of HTML/CSS: `font-family`, `font-size`, `color`, `background-color`, and tags `<span>`, `<p>`, `<b>`, `<u>`, `<s>`, `<br>`, `<h1>`. Example: `Print(\"<style>*{color:yellow;}</style><span>yellow</span>\");`.",
  "WorkspaceWidget.CreateWidgets": "Instantiates a `.layout` file into a widget tree: `GetGame().GetWorkspace().CreateWidgets(\"MyMod/gui/menu.layout\")`. Client-only — a dedicated server has no workspace.",
  "WorldData": "Per-map gameplay tuning: base environment temperature, wind behavior and similar knobs. Fetch it with `GetGame().GetMission().GetWorldData()`; each terrain ships its own subclass.",
  "WorldData.WeatherOnBeforeChange": "Hook used by vanilla's server-side scripted weather state machine before a transition; terrain subclasses such as `Enoch` provide the pattern. Override it for programmatic weather rules, or prefer `cfgweather.xml` when configuration is enough.",
  "ZombieBase": "The scripted infected. The AI brain — targeting, attack selection — runs engine-side; script hooks like `EEHitBy` and the mind-state accessors are where mods adjust damage, loot and aggro reactions.",
  "eAgents": "The disease agents, each a power of two so a whole pool fits one int — the list must match the config-side agent classes. `PlayerBase.InsertAgent(eAgents.SALMONELLA, 1)` is script-side infection.",
  "string.ToType": "Turns a class-name string into a `typename` — the bridge from config strings to script types: `\"ItemBase\".ToType()`. Only script classes resolve; plain config classes have no typename.",
  "vector": "Three floats. A string of three numbers casts straight into one (`\"0 0 0\"` is everywhere), `v[1]` is the height, and orientations travel as yaw–pitch–roll vectors — see `Object.GetOrientation`."
}