CS2 Update (Sep 30, 2026)

This update overhauls the Rush 001 mode’s scripting and UI, adds a new generation of Vulkan shaders, significantly expands crosshair customization (including a new quadrant style and outline color), and refines both the game’s toolchain and tournament item data.

Crosshair and HUD Updates

• New crosshair style and limits: The cl_crosshairstyle convar now allows values up to 9, with style 9 defined as Static Quadrant in the UI. Style 7 has been renamed in text to Dynamic Quadrant to better describe its look.
• Much wider gap range: cl_crosshair_gap now accepts values from -3840 to 3840 (previously 0–128). This enables extremely fine control for players who want very compact or very spread-out crosshairs, including unusual setups on high resolutions.
• Slightly increased thickness cap: cl_crosshair_thickness now supports up to 32 (previous max was 31), giving a bit more room for very bold crosshairs.
• Crosshair outline color controls: New per-user convars cl_crosshairoutline_r, _g, _b, and _a (0–255) define the outline’s RGB color and opacity. The options menu now exposes this as “Outline Color and Transparency”, so players can separate inner color from outline for better visibility on different maps.
• Quadrant-specific tuning: The crosshair settings add a “Quadrant Size” slider (GameUI_StaticQuadSplitRatio) for the quadrant-style crosshairs, enabling more precise control over how large each quadrant appears.
• Reticle friend/observer art removed: Old HUD reticle assets and XML entries for special friend and observer crosshair images have been removed from the HUD layout and related image resources. This suggests CS2 is consolidating around the main configurable crosshair rather than additional overlaid reticle art.
• Round end win panel clarity: The round-end win probability graph and MVP panel logic (hudwinpanel.js / hudwinpanel_background_map.js) received extensive internal cleanup and commentary. The behavior is the same, but the code now more clearly documents how hit events, odds changes, sounds, and MVP backgrounds are sequenced, which should make future polishing more reliable.
• Post-round damage readout hooks: The team counter script logs and manages the Post-Round Damage Report panels more explicitly, tying into the existing animation classes. While behavior is unchanged, this refactor may make it easier for Valve to tweak timing and visibility of those popups.
• Demo controller UX tweaks: The demo UI script adds more descriptive comments and improves internal state handling for:
  • The highlights vs. round playback toggle and text
  • Placement of interval markers under the timeline slider
  • Handling of TrueView prediction and DOA toggles These changes are aimed at robustness and clarity rather than new visible features.

Rush 001 Mode: Deep Script Rewrite and Quality-of-Life

The script backing Rush 001 (maps/scripts/rush_001.js) has been heavily rewritten with clearer logic and detailed in-line documentation. The gameplay rules remain the same, but the flow is now much more explicit.

Confirmed behavioral details from the updated script:

• Linear tug-of-war layout: The mode is explicitly described as a seven-room tug-of-war, with Terrorists pushing toward room index 6 and CTs toward index 0. A special decider room (“Convoy”) is reserved for 9–9 situations and is not used in the normal random room selection.
• Room selection and identities: Rooms are organized by index with specific ID sets per slot (e.g., base rooms at IDs 301/401, a four-room start cluster 101–104, mid-room pools 201–212). Comments label the rooms by name (Spire, Trainyard, Crane, Hydra, etc.), but the practical behavior is that each index pulls from a fixed list of eligible room IDs.
• Match and round tracking:
  • The script tracks round wins per team internally because the scripting API does not expose team scores directly.
  • It carefully detects when the engine restarts the match (e.g., via mp_restartgame or match end), then reseeds room layout and tallies to avoid mismatches.
  • On warmup, round-end logic is bypassed so warmup draws do not corrupt the tug-of-war state.
• Frontline and victory logic:
  • At round end, the frontline room index is adjusted toward the winning team.
  • If the frontline moves past the far base (beyond the first or last playable index), the match immediately ends in that team’s favor.
  • If the overall max rounds are exhausted while both bases still stand, the winner is determined first by total round wins and, if tied, by which side has pushed the frontline closer to the enemy base. If both are exactly balanced around the start room, the result is treated as a true draw.
• Decider round behavior: When both teams are one win away (e.g., 9–9 in a 19-round race) or when forced via a cheat, the script swaps in the Convoy decider room into the frontline slot. That room will then always decide the match.
• Round timing per room: Base rooms have longer round timers than mid rooms. The script calibrates mp_roundtime one round ahead so that the next room’s intended duration is captured when the engine latches round time.
• Team elimination handling:
  • The script detects if a team has been fully eliminated while ensuring empty teams (in tests) do not auto-lose.
  • If both teams are wiped, the current room controller decides the winner; otherwise, the last standing team wins.
  • A kill-less team wipe case (e.g., disconnects) is backstopped by re-checking elimination after button captures.
  • An optional END_ROUND_ON_TEAM_ELIMINATION flag remains, but is off by default.
• Countdown after elimination: If elimination does not end the round outright, the script can start a countdown with a terminal beep and an end-of-time sound while still allowing room captures to matter.

Antenna, Beacons, and Sounds

Rush’s tower/antenna system has been carefully clarified and decoupled from map authoring quirks:

• Single shared antenna per map: Instead of per-room copies, one antenna assembly is teleported into the active room each round based on marker entities (ant.base.<id>, ant.top.<id>). That keeps the visuals consistent and makes it cheaper to manage.
• Tall vs. short antenna tops: Certain room IDs use a shorter mast (for low ceilings); others use a tall one. Both tops are teleported every round, and the unused one is explicitly hidden and has collision disabled so players do not bump into invisible geometry.
• Side lights per room: Each room contains its own pair of light_barn side lights (e.g., ant.side.light.201.a/b), tinted based on which team controls the room. The script:
  • Iterates over all rooms and switches lights on only for the active room, off everywhere else, reducing the cost of dynamic lighting in unused spaces.
  • Uses a central team color table so antenna, flags, and related glow are always color-consistent.
• Antenna glow during freezetime:
  • At round start, the antenna glows in the owning team’s color during the freeze period to highlight the objective.
  • Once the round goes live (freeze ends), the glow is removed. There is no separate freezetime callback, so the script watches IsFreezePeriod() and toggles when it transitions.
• Global vs. actual antenna state:
  • The script distinguishes between logical control of a room (_roomStates) and the visual antenna color (_antennaTeam), especially at round end.
  • When a round ends, the script updates room ownership but delays repainting the antenna until the next round, so the last live color remains associated with actual player presence.
• Button behavior and beacons:
  • The single shared button on the antenna posts OnPressed events that the script reconnects every round.
  • Button presses:
    • Play either a “press” or “error” beacon depending on whether the pressing team already owns the tower or if the round is already decided.
    • Update room control, antenna lights, and UI when valid.
  • Sound entities for idle hum, press, error, countdown beeps, and time expiry are all dynamically repointed to the current room’s button so map authors don’t need per-room duplicates.

Timer Beeps and Round-Ending Audio

• The terminal countdown system now has explicit tempo stages and scheduling rules:
  • Multiple tempo stages, each for a fixed number of beeps (e.g., 1.0s, 0.5s, 0.25s, 0.125s intervals), are used as the timer approaches zero.
  • The script keeps track of the next beep time and the count of beeps emitted, and advances through stages as counts are consumed.
  • A small tolerance is built in so a think tick that lands slightly before a scheduled time will still emit the beep, rather than waiting for the next tick and drifting progressively late.
  • If the server hitches and falls more than an interval behind, the schedule re-anchors at the current time so the rest of the beeps don’t bunch up.
• An end-of-round timer end sound plays only when the round actually expires on time; elimination wins suppress it, to avoid misleading audio.

Fog and Map Atmosphere in Rush

• The script now centralizes fog presets and room → fog mappings:
  • An env_gradient_fog entity named fog is expected and controlled via scripted inputs.
  • Presets (e.g., exterior, interior, tunnel, base) specify color, start distance, end distance, opacity, and falloff.
  • Each room ID is mapped to a fog preset (e.g., interior settings for tight indoor rooms, tunnel for sewers, base-style fog for the castles).
  • Rooms not in the map fall back to a default preset.
• This system keeps Rush’s visual readability consistent and may make it easier for Valve to tweak visibility and mood room-by-room without manual entity work.

Rush UI and Player Feedback

• The Rush-specific HUD (“rush_ui” panorama layout) is driven more precisely:
  • A canonical list of room panel class names (e.g., room_101) lets the script cleanly clear old classes and apply new ones when showing progression.
  • On round start, the script:
    • Updates ownership indicators for the current frontline room.
    • Decides whether to show a forward or backward slide animation based on which team advanced, or a neutral “no progress” animation if nobody moved.
  • The same progression panel is reused for both teams, with per-player classes like view-t and view-ct so each side sees orientation from their perspective.
• For each player, the attack/defend hint UI is updated based on which team currently controls the tower, with CT/T variants and a neutral spectator description.
• The UI code is explicitly resilient to warmup and to missing entities (e.g., if the Rush UI isn’t present, the script will quietly skip calls rather than erroring).

Tournament Item Economy: Cologne 2026 Capsule Logic

There are focused changes to items_game.txt relating to Cologne 2026 sticker and highlights packs:

• New volatile capsule prefab: A new cologne2026_sticker_capsule_prefab_volatile prefab is introduced. It inherits from the main Cologne 2026 sticker capsule prefab and defines a "volatile container" "3" attribute.
• Crates now reference the volatile prefab: Several Cologne 2026 packs (e.g., all-team, champion, rankings, and highlights stages 1–6) now use the new _volatile prefab plus appropriate volatile_pricing_* modifiers, instead of adding volatile container attributes directly on the item:
  • For example, crate_sticker_pack_cologne2026_all, crate_sticker_pack_cologne2026_champion, and multiple crate_highlights_pack_cologne2026_X entries now refer to cologne2026_sticker_capsule_prefab_volatile.
• Consolidated volatile attributes: The direct "volatile container" "2" attributes were removed from individual crates and moved to the _volatile prefab. This suggests Valve is centralizing how volatile pricing or supply behavior is defined for these capsules.
• Spray-related fields removed: A Cologne 2026 prefab had "type" "spraypaint", a secondary item_slot2/item_sub_position2 of spray, and an inv_graphic_art of graffiti. These have been removed, signaling that this particular tournament item is no longer treated as a spray-like tool.

Impact-wise, this appears to be backend preparation for how Cologne 2026 sticker and highlight capsules are sold and priced. Market behavior or UI presentation may change when Valve enables these items, but this update itself primarily restructures data and does not directly introduce them to players.

Pets and Vanity: Photo Book and Hints

Panorama scripts and assets related to pets and the pet book feature were also updated:

• New VTex image entries for multiple pet book pages (e.g., “early days”, “road trip”, “park life”, “balloons”) were added, backing the in-game photo album visuals.
• The English localization expands several pet book hint strings:
  • The previous single pet_book_hint_adolescent_road_trip line is now split into two variants, each explicitly naming map sets like “Dust II, Baggage, Inferno, or Train” and “Mirage, Nuke, Cache, or Ancient”.
  • This suggests the pet progression system may use more specific map categories when giving players photo challenges, though there is no direct gameplay change confirmed here.
• Multiple Panorama scripts (pet_book_pages.js, pet_book_turn.js, vanity_pet_info.js, pet_photo_* popups) were touched as part of the large UI refactor. The behavior appears to be maintained but the code is cleaner and better documented.

Vulkan Shader Suite and Tools Pipeline

A substantial chunk of the update lands in the shader pipeline and tooling, mainly affecting creators, modders, and performance under the hood.

New and Updated Vulkan Shaders

• Dozens of *.slang shader definitions under shaders_vulkan_dir/shaders/vfx/ were added or updated, including:
  • Core material shaders: csgo_character.slang, csgo_vertexlitgeneric.slang, csgo_lightmappedgeneric.slang, csgo_unlitgeneric.slang.
  • Weapon and glove shaders: csgo_customweapon.slang, csgo_customglove.slang, plus a csgo_customglove_preview.slang for inspection previews.
  • Environment and decals: csgo_projected_decals.slang, csgo_decal_renderer.slang, csgo_water.slang, csgo_decalmodulate.slang, csgo_beachfoam.slang.
  • UI and special-purpose: csgo_crosshair.slang, tools_wireframe.slang, csgo_tools_shading_complexity.slang, sky.slang, spritecard.slang.
• Manifest entries for both Vulkan and PC shader directories were updated to include these new shader files.

For players, this likely means stability and performance gains on Vulkan, and more consistent visuals across characters, weapons, gloves, decals, and UI elements. For Workshop creators and level artists, it standardizes the available CS2-specific shader set, making it easier to target the intended pipeline.

Resource Compiler and Tools Settings Integrated into Gameinfo

The main gameinfo.gi for CS2 has been heavily expanded by merging settings previously spread across internal “core” or “imported” configurations into one file. Confirmed highlights:

• Engine and rendering defaults:
  • SteamAppId explicitly set to 710 and mod/tool systems marked as 64-bit capable.
  • Default render system and tools render system both set to -dx11, with a defined RenderingPipeline block that:
    • Enables post-processing in the main pipeline
    • Supports MSAA
    • Enables tools visualization modes and high precision lighting
• Console and input QoL:
  • PauseOnCtrlConsole is forced to 0, preventing the Source 2 behavior where holding Ctrl + console toggle auto-pauses—matching CS:GO’s behavior.
  • RestrictConsoleCloseKey set to ` so non-default console keybinds can open but not close the console; Escape always closes, again mirroring CS:GO.
  • cl_joystick_enabled and panorama_joystick_enabled are defaulted to 0, with the possibility to be turned on by players.
• New or pinned convars:
  • demo_max_consecutive_skip_packets defaults to 2500, setting a cap on how far demo playback can skip forward in a single jump.
  • r_particle_batch_collections set to 1, which may improve particle batching performance.
  • spec_replay_enable is constrained with min/max of 0, effectively disabling spectator replay from user-side configuration for now.
• Resource compiler defaults:
  • Map building: Default builders now include baked lighting (bakedlighting), nav mesh generation (nav), and multiple Steam Audio passes (sareverb, sapaths, sacustomdata).
  • MeshCompiler: Enables vertex/index buffer encoding, per-draw culling data, meshlets, MikkTSpace tangent generation, and depth stream splitting.
  • WorldRendererBuilder: Turned on visibility-guided clustering, static envmap usage for certain objects, non-uniform scale baking, and aggregate instancing.
  • Baked lighting: Sets up deterministic builds, LPV usage, default lightmap sizes and gutters, and multiple lightmap channels (irradiance, shadows, directional irradiance, debug colors) with DXT1 compression.
  • VisBuilder: Caps vis clusters at 4096 and enables deterministic builds with several thresholds for merging open space.
  • Texture compilation: Uses lz4 compression, compressed mips on disk, non-power-of-two textures, Panorama mip generation, and a public tools default max resolution of 2048.

For mappers and asset creators, this consolidated configuration means Hammer and resourcecompiler will behave much more predictably for CS2, with CS:GO-specific choices encoded as defaults rather than hidden in separate mods.

Scene, Audio, and Tools Systems

Several engine-side modules and tools gained new capabilities or safer defaults:

• SceneSystem:
  • Confirms use of GPU light binning, dynamic shadow resolution, sparse shadow trees, point light shadows, character decals, firstperson legs, hybrid instanced fade support, and multiple tonemapping and fog options.
  • Introduces well-known light cookie slots for blank, flashlight, and muzzleflash, backed by newly added textures under materials/effects/lightcookies/.
• Particles:
  • Settings declare particles are fogged by default, support mixed resolution, and can offset collision traces in a way tuned for CS2.
• WorldRenderer:
  • Standardizes environment map settings (blur type GGX, BC6H format, cube arrays, per-map atlases) and sets grass rendering parameters.
• NavSystem:
  • Global nav mesh parameters (tile size, cell size/height, region thresholds, max poly edge length, detail sampling) are defined, with an explicit NavHullsPreset of default and a custom nav build interface loaded from server.dll.
• Hammer:
  • Confirms CS2’s Hammer uses csgo.fgd plus csgo_internal.fgd, Counter-Strike feature set, terrain tools, Steam Audio, lattice deformers, smart prop instance rendering, and a 6144x6144 shadow atlas.
• ModelDoc and asset tools:
  • ModelDoc flags CS2-specific features, enforces stricter treatment of missing materials, and treats warnings as errors for key paths like agents and weapon models, pushing higher content quality.

Networking Protocol Cleanup

• Several Game Coordinator message types and the supporting EInitSystemResult enum were removed from the shared cstrike15_gcmessages.proto and corresponding client schemas:
  • GC2ClientRefuseSecureMode
  • GC2ClientRequestValidation
  • GC2ClientInitSystem
  • GC2ClientInitSystem_Response
• Fields for things like module manifests, system packages, and validation results were excised.

This indicates the game is **retiring an e