CS2 Update (Sep 24, 2026)

This update quietly rewires a lot of CS2’s under-the-hood systems, with a strong focus on bots, Workshop support, entity definitions for mapmakers, and new materials and models tied to Anubis, water, and various props.

Gameplay & Workshop: Bot and Command Whitelisting

A large set of console variables and commands have been re‑tagged so they are explicitly Workshop‑whitelisted. In practice, this primarily affects custom servers and local play rather than official matchmaking.

• Bot convars now Workshop‑whitelisted:

  • Classic settings like bot_difficulty, bot_quota, bot_join_team, bot_allow_rifles, bot_allow_grenades, bot_freeze, bot_ignore_enemies, and many more now include the workshop_whitelisted tag.
  • Grenade and item limits such as ammo_grenade_limit_default, ammo_grenade_limit_flashbang, ammo_grenade_limit_total, and ammo_item_limit_healthshot are also marked workshop_whitelisted.
  • This suggests Workshop maps and community servers will have clearer, supported access to these controls, making it easier to script bot behavior and equipment setups without conflicting with official restrictions.

• Key commands opened up for Workshop use:

  • Bot management: bot_add, bot_add_t, bot_add_ct, bot_kick, bot_kill, bot_knives_only are now tagged workshop_whitelisted.
  • Movement/cheat utilities (for practice maps and tools): noclip, god, setpos, setang, ent_create, ent_fire, ent_fire_output, ent_setname, subclass_create, give.
  • Match flow and voting: callvote, mp_warmup_end, game_alias, map_workshop.
  • Config and logging helpers: exec, execifexists, host_writeconfig_with_prompt, log_color, log_flags, log_verbosity.
  • Player interaction and UI: say, say_team, player_ping, radio commands radio, radio1, radio2, radio3, and weapon slot selects slot1–slot9.
  • Utility/practice: annotation_load, regenerate_weapon_skins, restart.

These changes do not introduce new commands, but they clarify what’s allowed for Workshop content. Workshop map authors and training‑map creators will likely find it easier to rely on these commands without running into inconsistent behavior between clients and servers.

Mapping & Modding: New FGD Entity Definitions

Two big definition files have been added for entities:

• Server entity definitions: server.fgd
• Client entity definitions: client.fgd

These files enumerate base classes and inputs/outputs for Source 2 entities.

• Richer base classes for mappers:

  • CEntityInstance and C_BaseEntity are described with properties like health, velocity, owner, spawnflags, movement types (MoveType), platform behavior (platform_type), and more.
  • Inputs such as GetAbsOrigin, GetAbsAngles, GetAbsTransform, GetAttachmentOrigin, and GetTeamNumber are listed, including Pulse‑node style descriptions (return types like PVAL_VEC3_WORLDSPACE).
  • There are also inputs for parenting, damage forces, sleeping, platform enabling/disabling, and user events (FireUser1–FireUser4).

• Why it matters for creators:

  • While these FGDs are not directly shipped as Hammer configs here, they outline the entity API more completely.
  • This should help tool authors, modders, and advanced mappers better understand what inputs/outputs and properties exist in CS2’s entity system, potentially leading to more sophisticated scripted setups once integrated into tools.

Materials, Models, and Map Art Updates

The tools asset manifest (readonly_tools_asset_info.txt) has been heavily updated with new visual assets.

• Anubis‑related environment content:

  • New materials and models under materials/anubis and models/anubis, including:
    • materials/anubis/hr_sand_skybox_beach.vmat
    • materials/anubis/models/foliage/palm_bark.vmat, palm_frond.vmat
    • models/anubis/foliage/palm_tree_01.vmdl
    • models/anubis/unique/water_wall02.vmdl
  • This suggests further visual refinements or experiments around Anubis, especially beach/skybox sand and foliage.

• Prop and environment props:

  • New props and materials for large structures and vehicles:
    • Dust‑style barge and crane: models/props/dust_massive/barge/crane_arm.vmdl and matching crane_arm_color.vmat.
    • Cargo containers: multiple models/props/hr_massive/cargo_container_* and materials/models/props/hr_massive/survival_cargo_container/survival_cargo_container_color.vmat.
    • Wood planks, utility poles, sign poles, corrugated panels, plywood sheets, and urban metal poles under models/props_* and corresponding materials/models/props_*.
    • An APC model: models/vehicles/apc/apc_vehicle_1.vmdl with tint and base vmats.
  • These appear aimed at level art and set‑dressing; players may notice more detailed props on certain maps as these assets are adopted.

• Particle debris and dev models:

  • Generic dev shapes: models/dev/dev_cylinder.vmdl, dev_sphere.vmdl.
  • Debris leaves: models/particle/debris/street_leaf_05.vmdl, _07.vmdl.
  • These are mostly tooling and VFX conveniences, but they can translate into better‑looking debris and effects in maps.

• Water and liquid texture cleanup:

  • Several legacy or experimental water and liquid textures have been removed, such as:
    • materials/dev/water_height_psd_*.vtex
    • materials/dev/water_substance_*_psd_*.vtex
    • materials/liquids/water_debris_color_*.vtex
    • Map‑specific water tints for Anubis and Nuke (e.g. anubis_water_canal_vmat_g_tcolor_*.vtex, nuke_water_vmat_g_tcolor_*.vtex).
  • This points to a cleanup or consolidation of water materials. Players may eventually see more consistent water appearance across maps, but the immediate in‑game impact is uncertain.

• Chicken and graffiti asset adjustments:

  • Many entries touch materials/models/chicken and sounds/ui/chickens, plus removal of some chicken_vmorf textures.
  • There are also changes under materials/decals/graffiti and Cache mural textures.
  • This may indicate a re‑authoring or optimization pass for the chicken model and some graffiti/decals; any visible change would likely be minor (e.g. slightly different shading or memory usage).

Audio & Tools: Steam Audio and Diagnostics

Multiple audio‑related schema libraries and tool assets were updated:

• Low‑level and mix graph schemas:

  • soundsystem_lowlevel, soundsystem_voicecontainers, sounddoc_lib, and soundsystem schemas have new or adjusted definitions for processors (e.g. CVMixSteamAudioHybridReverbProcessorDesc, CVMixPitchShiftProcessorDesc), voice containers, and sound‑group actions.
  • This is engine‑side work; it may allow more advanced mixing, reverb, and spatialization setups but doesn’t, by itself, confirm new audible features.

• Steam Audio tool materials:

  • New dev and tool materials like materials/tools/toolssteamaudiofullabsorption.vmat, materials/tools/toolssteamaudiofulldiffuse.vmat, and an associated color texture.
  • These are typically used in Hammer or baking tools to mark surfaces for audio simulation (e.g. how much sound they absorb/reflect). Mappers may gain finer control over how sound behaves around walls or volumes.

• Diagnostic audio content:

  • Additional debug sounds:
    • sounds/diagnostics/sine_sweep.vsnd
    • sounds/diagnostics/sin_1k_0p005_oneshot.vsnd
    • Beat‑pattern events and stacks: soundevents/soundevents_beat_pattern.vsndevts, soundstacks/soundstacks_beat_pattern.vsndstck.
  • These will mostly matter for sound designers and tool debugging; normal gameplay shouldn’t expose them directly.

Engine & Systems: Interfaces and Logging Channels

New tracking files describe the engine’s public interfaces and logging channels, which mainly helps tool and integration authors.

• Interface registry (interfaces.txt):

  • Lists interface names grouped by module, such as:
    • Source2Client002, Source2EngineToClient001, Source2Server001.
    • Tools and editors: CS2ItemEditor, CS2WorkshopManager, ToolSystem2_001 for various tools (hammer, postprocessingeditor, pet, etc.).
    • Systems like MaterialSystem2_001, MeshSystem001, NavSystem001, VPhysics2_Interface_001, WorldRendererMgr001, VScriptManager010.
  • While this doesn’t change gameplay, it documents how subsystems expose functionality, which may benefit advanced tooling or diagnostics built around CS2.

• Logging channels (logging_channels.txt):

  • A comprehensive list of logging categories with colors and default verbosities, such as:
    • AnimationSystem, Particles, Physics, SoundSystem, WorldRenderer.
    • Tool‑oriented channels: Hammer, ModelDoc, PostProcessEditor, VisBuilder, MapBuilderSystem, ToolFramework2.
    • Gameplay and networking: Matchmaking, Networking, Server, Client, Workshop, Inventory, GCClient.
  • This suggests internal debugging and development workflows are being made more structured. It may indirectly improve stability and speed of future fixes, but players won’t interact with these channels directly.

Source 2 Schemas: Animation, Particles, Physics, and Smart Props

A huge amount of schema metadata was refreshed across multiple subsystems. These are data descriptions the engine uses to serialize and introspect systems rather than new code themselves.

Notable areas touched:

• Animation graphs and motion systems:

  • Libraries: animlib, animgraphlib, animgraphdoclib, animdoclib, modtools.
  • Nodes for motion matching, orientation/target warping, foot IK, ragdolls, hit reactions, camera aiming, locomotion helpers (jump, slow on slopes, follow path), and various parameter selectors.
  • This work appears to refine how character and weapon animation graphs are described, likely helping animators and tools rather than changing feel immediately. Over time it may enable smoother blending, better hit‑reacts, or more robust pose handling.

• Particle systems:

  • particles and particleslib schemas were updated for many operators and initializers (C_OP_RenderTrails, C_OP_RenderSprites, C_OP_RenderRopes, C_OP_BasicMovement, various vector/remap operators, and random seed handling).
  • These changes seem focused on how particle parameters and randomness are defined. VFX artists may get more predictable or controllable behavior; players might eventually notice more consistent smoke, sparks, debris, or environmental effects.

• Smart props & world building:

  • smartprops module updates cover filters and operations for placing and transforming props (paths, meshes, grids, random rotations, scaling, color tinting, material overrides, traces, etc.).
  • This likely streamlines workflows for automatically placing clutter, props, and decorations, which can translate into richer environments with less manual labor.

• Physics and world renderer:

  • physicslib, vphysics2, and worldrenderer schemas were touched, including ragdoll control fields and proxy BLAS (ray‑tracing / acceleration structure) metadata.
  • These updates mostly look like correctness and data‑format improvements (e.g. handling invalid mass values, index ranges). They may improve stability of ragdolls and collision or prepare for more advanced rendering, but nothing explicitly indicates a gameplay physics change.

Tooling & Post‑Processing

Several schema libraries and assets relate to rendering and post‑processing tools:

• Resource compiler & post‑process layers:

  • resourcecompiler schemas enumerate color correction layers like brightness/contrast, hue/saturation, LUTs, local contrast, bloom, tone mapping, fog scattering, vignette, and exposure.
  • Coupled with new dev materials such as materials/dev/vrad3/* and materials/editor/far_field.vmat, this suggests ongoing work on lighting and post‑process tooling for CS2 maps.

• Default materials for tools:

  • New materials/default textures (default_normal, default_metal, default_detail, default_selfillum, etc.) are now referenced in the tool manifest.
  • These likely serve as safe fallbacks in tools and engine rendering when an asset is missing or uninitialized, which can reduce broken visuals during development.

Overall Impact

For day‑to‑day players, this update doesn’t introduce marquee gameplay or UI changes. Its impact is more enabling than immediately visible:

• Workshop creators get clearer, officially whitelisted access to vital commands and bot controls, which should make training maps, co‑op scenarios, and custom modes more robust and easier to maintain.
• Mappers and tool authors gain richer entity definitions, improved audio and lighting tools, and a broader set of props and materials—especially around Anubis‑style environments, cargo containers, vehicles, and foliage.
• Engine‑side schema and logging updates should help Valve (and advanced tool developers) debug, iterate, and polish CS2’s animation, particles, physics, audio, and rendering pipelines more effectively.

Players may only see subtle visual or behavioral tweaks in the short term, but this kind of foundational work tends to pay off in smoother features and more polished community content over time.