CS2 Update (Oct 4, 2026)

A behind-the-scenes CS2 update focuses on engine data, networking definitions, lighting, and tooling infrastructure, with knock-on benefits likely for custom content creators, map makers, and anyone working with Workshop or community servers.

Engine networking and entity definitions updated

• New network schema dumps: Fresh client and server network descriptions now cover a wide range of engine types, including bounding boxes, model configs, animation data, and item attributes. This suggests the internal view of what’s networked between server and client has been brought in line with the current binaries, which may help modders and tool authors who rely on accurate entity and netvar information.
• Animation graph wiring clarified: Client and server networking now explicitly include AnimGraph2 structures such as serialized pose recipes, playback rate, and loop mode. This may make it easier for tools and debugging workflows to reason about how player and prop animations replicate and update.
• Sequence operation helper baseclass: A shared CNetworkedSequenceOperation base description (cycle, sequence name, sequence index) was added for both client and server entity definitions. Custom tools or map logic that introspect animation state could potentially use this to reason about what an entity is currently playing.

Richer FGD support for mapping and scripting

• Expanded base entity layout: The client.fgd and server.fgd files (used by Hammer and other tools to describe entities) now expose more of the core C_BaseEntity / CBaseEntity scene node:
  • Local/world origin and angles
  • Parent attachment name and parent target
  • Flags for using local offsets, parent render bounds, and local-space positioning
  • Scale fields (scales, local.scales, scalar scale, and ModelScale)
• VScripts as formal keyfields: The vscripts property on base entities is now marked as an added keyfield on both client and server. This confirms script bindings are intended to be set via keyvalues, and may improve editor integration (exposed fields, validation, or helpers) for scripted entities.
• Base model entity components: basemodelentity now explicitly documents render and hitbox components, plus skeleton instance fields like hitbox set, velocity, rotation axis and speed. Hammer definitions that pick up these fields can give creators a clearer view of how animated models will behave in-game.
• Prop data components: Several prop classes (breakable_prop, func_breakable, prop_ragdoll, and the base prop class) are now annotated as having a CPropDataComponent. Health is explicitly removed as a direct key on the base prop type, reinforcing that damage behavior is meant to go through standardized propdata.
• New helper datamaps: Additional base definitions appear for:
  • HullFlags_t (AI hull type flags like human, small, wide, tall)
  • hudtextparms_t (HUD text channel, effect, x/y)
  • These may help advanced users or tooling introspect AI and HUD-related behaviors more accurately.

Detailed light entity controls exposed

• Full light component in FGDs: The light_omni entity on both client and server now exposes a comprehensive CLightComponent block, including:
  • Color & intensity: Primary/secondary color, brightness, brightness scale, range, falloff.
  • Attenuation & cones: attenuation0/1/2, inner/outer cone angles.
  • Shadows & cascades: Number of cascades, per-cascade distances and resolutions, whether to render static objects into shadows, crossfade and distance fade controls, shadow texture size, shadow priority, baked shadow indices, and flags for using baked shadowing.
  • Rendering options: Separate toggles for diffuse, specular, transmissive rendering, orthographic light width/height, style and pattern string, direct light and bounce light with a bounce scale.
  • Fade behavior: Fade and shadow fade min/max distances, precomputed bounds (mins, maxs, OBB origin, angles, extent) and whether those precomputed fields are valid.
  • Fog and environment: Fog lighting mode, fog contribution strength, near clip plane, sky color/intensity, sky ambient bounce.
  • Advanced options: Secondary color usage, capsule length, mixed shadows, minimum roughness, and a cluster of ambient occlusion proxy strengths and cone angles.
  • Special flags: allow_sst_generation (server) and baked_light_indexing plus IDs tying lights into light path and lightmap indexing.
• Practical impact for mappers: This level of detail in the FGD means Hammer and other editors can now present far more of the engine’s lighting capabilities as editable properties. Map makers may find it easier to control performance (shadow resolution, cascades, AO proxies) and look (fog interaction, mixed shadows, advanced cones) without resorting to guesswork or custom tooling.

Animation and camera tuning options surfaced

• BaseAnimGraph controller fields: The shared baseanimgraph pointclass on both client and server now references the CBaseAnimGraphController, exposing:
  • playbackrate as a networked, quantized float
  • animgraph2_identifier as a global symbol string This hints that more control over which AnimGraph2 resource is used and how fast it plays may be visible to tools and diagnostics.
• Depth-of-field as keyfields: For point_camera_vertical_fov, the depth-of-field settings (dof_far_crisp, dof_far_blurry, dof_tilt_to_ground) are now explicitly marked as keyfields. Mappers may find these easier to tweak directly in Hammer for cinematic or spectator cameras.
• Physics impact scaling in editor: physdamagescale on prop_physics is also marked as a keyfield, which should make tuning how much damage physics impacts do to props more discoverable.

Player and path components clarified

• Touch expansion on players: The player pawn base on server now shows a CTouchExpansionComponent. This likely reflects internal collision/interaction volumes around players, and may matter for understanding how triggers or touch-based logic interact with player entities.
• Path_simple query component: Both client and server definitions for path_simple now note a CPathQueryComponent, aligning the FGD with the set of available queries (closest direction, position, etc.). Path-based movers and scripted logic that rely on these queries appear better documented for tool authors.
• Mover solidity as a key option: On certain mover entities, the solidbsp flag is now tagged as an added keyfield. This should make it clearer when a brush-based mover is expected to be solid at runtime, which is important for collision and gameplay design.

Lighting, materials, and rendering resource manifests

• Client resource manifests: A new client resource manifest pulls together a variety of runtime assets:
  • Cosmetic prewarming: custom_glove_prewarm and custom_weapon_prewarm materials, likely used so glove and weapon skins appear without hitching when first shown.
  • Agent models: References to core models like ctm_sas and tm_phoenix ensure they’re preloaded for the client.
  • Post-processing: Startup entries for ClientModeCSNormalPostProcessing and dedicated death_cam postprocessing effects (including a low-violence variant) indicate the death cam visual pipeline is formally hooked into the manifest system.
  • UI & HUD: Manifests for minimal graphics settings, StatTrak item preview, vanity panels, HUD (CS2Hud_client), and a CS-specific color picker tie various Panorama and 3D panel systems into controlled loading paths.
  • Rendering pipeline: Entries for CS2’s shadow pipeline (CS2RenderingPipelineShadowsManifest and startup group) and a GaussianBloomBlurManifestClient alongside associated dev materials suggest more structured management of advanced effects like bloom and histogram passes.
• Server resource manifests: On the server side, new manifest entries include:
  • A minimal player pawn setup (CCSPlayerPawn_Minimal_server)
  • The bomb defuser item (item_defuser_server and item_defuser.ventr)
  • A large list of agent model .vmdl files across CT factions (SAS, diver, FBI, gendarmerie, etc.) This organization should help servers precache and manage agents and critical gameplay items more predictably.
• Core engine systems: Several engine subsystems now have explicit resource_manifests.txt files (for example engine2, particles, soundsystem, vphysics2, materialsystem2, worldrenderer, scenesystem, vrad3 and others). This shifts more resources into declarative manifests, which may improve stability and consistency when loading complex scenes or running tools.
• Hair and debug materials placement: Developer materials like hair_sim_cs.vmat and sum_aggregate_cull_stats.vmat have been moved into a scenesystem-level manifest. This points to some internal cleanup in how debug and simulation materials are referenced.

Pulse system and gameplay scripting hooks

• Pulse bindings for game events: New pulse_bindings.txt files for client, server, pulse_system, and resourcecompiler define Pulse “cells” and domains:
  • Core base classes (BaseDomain, CPulseCell_Base* variants) and flow/value cells (e.g. IntervalTimer, LimitCount, PickBestOutflowSelector).
  • Server-specific gameplay events like OnRoundStart, OnRoundFreezeEnd, and OnRoundEnd with parameters (winner, reason, round number).
• Entity and light APIs: Server Pulse bindings now expose APIs for:
  • Ambient sound entities (CAmbientGeneric_API) with actions such as Fade In/Out, Play/Stop/Toggle.
  • Barn lights (CBarnLight_API) with actions such as Enable/Disable, Set Brightness/Color/Color Temperature, toggling dynamic shadows and bounce scale.
  • Parenting helpers (maintain offset, attach to bones, and mover offset from paths).
• Particles and game state: Pulse bindings for resourcecompiler and client include CParticleBindingRealPulse and CParticleCollectionBindingInstance, described as enabling particle content to query game state. This suggests particle systems may gain more powerful logic hooks, likely useful for reactive or gameplay-aware VFX authored in tools.
• Practical impact: For now these are wiring changes rather than user-facing UI, but they strongly indicate an ongoing effort to make CS2’s node-based scripting system (Pulse) a first-class way to drive gameplay, VFX, and entity logic.

Toolchain and Hammer/QT editor cleanup

• Split of metadata vs. bind targets: Many tool-related .kv3 metadata files for Hammer, PET (particle editor), ModelDoc, SFM, the postprocessing editor, asset browser, item editor, and others have had large blocks of “class” declarations removed in favor of new bind_targets.txt files.
  • The new bind_targets files map friendly names (e.g. MapView, Camera, ToolSceneWidget, ModelDocEditorApp, ParticlePreview) to the underlying C++ classes and source files.
  • This suggests Valve is standardizing how editing tools discover and bind to their UI and scene components, which may reduce maintenance burden and improve consistency across tools.
• Global hotkeys and shared widgets: Many tools now share the same bindings for CGlobalHotkeyCommands, CQSessionCycleWidget, CQToolSceneWidget, CQCurveEditorWidget, and various timeline widgets. Tool users might see more consistent keyboard shortcuts and timeline behavior across the CS2 toolchain.
• Asset and preview tools: Asset browser and asset preview now have explicit bindings for cameras, lighting control rigs, and tool scene widgets. ModelDoc and PET similarly declare their camera, preview, and lighting components. This is likely to make it easier to maintain shared preview behavior (lighting presets, camera controls) between different authoring tools.
• Engine-side strings trimmed: Many internal string tables for tools and engine DLLs had entries like animgraph2_identifier, attenuation settings, and debug fields removed or reorganized. While not a direct gameplay change, this points to ongoing refactoring of how debug and editor-facing properties are surfaced.

Manifests for binaries and community content

• New depot manifests: Several new manifest_2347***.txt files describe updated Steam depots:
  • Core game depots: One manifest lists thousands of files for the main game binaries and VPKs (including pak01_000.vpk onwards, shaders, and core config), confirming a full repack of game content.
  • Windows binaries: Another manifest enumerates Windows 64-bit DLLs and EXEs (cs2.exe, client/server DLLs, engine, rendering, V8, physics, etc.), indicating a coordinated rebuild of most runtime components.
  • Linux binaries: A Linux Steam Runtime 64 depot manifest lists the corresponding .so libraries and the cs2 launcher script.
• Curated community map packs: Multiple manifests reference large csgo_community_addons VPKs for maps such as cs_shelter, de_boulder, de_debris, de_eldorado, and de_fachwerk, as well as de_poseidon.
  • This strongly suggests that a curated set of community or “community addons” maps is being distributed alongside the game.
  • From a player perspective, these maps may be used in official playlists, featured servers, or special events, although how they will surface in-game isn’t explicitly stated here.

Overall impact

This update is primarily structural and tooling-focused rather than a direct gameplay or balance patch. Confirmed changes include:

• More accurate and expressive FGDs for entities, lights, paths, and animation controllers.
• Expanded Pulse bindings that wire core CS2 gameplay events, entities, and lights into the node-based scripting layer.
• A manifest-driven approach to loading client and server resources, including agents, postprocessing effects, HUD/UI, and advanced rendering pipelines.
• Standardized bindings across the CS2 toolchain (Hammer, ModelDoc, PET, SFM, postprocessing editor, asset browser), which should benefit map makers and content creators.
• Updated depots that bundle a suite of community addon maps and rebuilt binaries for Windows and Linux.

For everyday players, the visible effects may be subtle at first—smoother map lighting, more reliable custom content, and cleaner deathcam and HUD effects. For mappers, modders, and tool authors, this update lays more of the groundwork needed to fully exploit CS2’s Source 2 capabilities and to integrate community content more tightly into the game’s ecosystem.