CS2 Update (Aug 26, 2026)

A small CS2 update quietly refines custom HUD support for scripted maps, tightens how addons are treated by the UI system, and freshens up tools documentation for creators experimenting with cs_script and Panorama.

Custom HUD layouts for scripted maps

This update focuses heavily on improving and clarifying how custom HUD layouts work in scripted addons and maps.

• Clearer CustomHudLayouts docs: The cs_script_demo example and its point_script TypeScript definitions now spell out how to build a custom HUD layout for your addon:
  • You can use a limited set of Panorama panels: Panel, Label, Image, and Button, with specific supported attributes like id, class, hittest, text, and src.
  • CSS styling (.vcss assets) is supported, but events and client‑side scripting in the layout itself are explicitly not supported.
  • The documentation now walks through a concrete example in the cs_script_demo addon: a custom_hud_layout entity named welcome_layout that displays a welcome.vxml layout and uses a matching CSS file.
• Practical setup guidance: Creators get step‑by‑step notes on how to wire everything together:
  • Place your Panorama layout .xml (actually .vxml asset) under panorama/layout/custom_game in your addon.
  • Add a custom_hud_layout point entity to your map and point its layout property at that .vxml.
  • Use a CSS file under panorama/styles/custom_game to control appearance; the example shows a dialog panel whose Dismissed class is removed from a cs_script file (maps/scripts/setup.js).

These changes are documentation and tooling improvements rather than new gameplay features, but they should make it easier for Workshop and community creators to build polished custom HUDs without guesswork.

Improved entity and editor labeling for custom HUDs

Hammer users and map authors get a small but meaningful tweak that should make custom HUD entities easier to work with.

• Friendlier custom_hud_layout field name: In the game’s FGD definition, the layout key for the custom_hud_layout entity now has a clearer display name ("Layout") and description:
  • The field is explicitly described as a Panorama layout resource with limited supported panel types and attributes.
  • This helps level designers immediately understand what they’re picking in Hammer and how it ties back to the cs_script custom HUD documentation.

In practice, this should reduce confusion when wiring HUD layouts to maps, especially for creators following the new cs_script_demo example.

Scripted camera behavior clarification

For scripters experimenting with camera control, there’s an extra bit of guidance around how player cameras are managed.

• Per‑player camera note: The point_script definitions now explain that the camera object used to control a player’s view without moving their pawn:
  • Exists at most once per CSPlayerPawn.
  • Is created on demand when CSPlayerPawn.GetCamera is called.

This doesn’t introduce new functionality by itself, but it gives a clearer mental model for how scripted camera control is structured, which may help authors avoid incorrect assumptions or misusing multiple cameras per player.

Addon trust debugging and Panorama behavior

There are a couple of subtle under‑the‑hood changes around how Panorama and addons are treated, which may matter most to developers, modders, and debugging workflows.

• New addon trust debug convar: A hidden, development‑only console variable named panorama_debug_treat_all_addons_as_untrusted has been added.
  • This is clearly marked as a defensive debug option rather than a player‑facing setting.
  • It likely exists to let developers simulate all addons being treated as “untrusted” by the UI system, helping test how CS2 behaves under stricter addon security or sandboxing.
• Panorama file creation messages adjusted: Internal Panorama UI strings relating to disallowing layout, script, or style file creation have been cleaned up.
  • References to the client “disallowing” the creation of Panorama layout/script/style files have been removed from internal logs.
  • This suggests the engine’s handling or messaging around these situations has been streamlined, which may affect how errors or restrictions show up in dev tools or logs.

For ordinary players, these shifts are unlikely to be visible, but for UI and addon developers they may change how certain edge cases are logged and debugged.

Client, server, and HUD state internals

A set of small, internal changes touch client and server code, especially around how HUD layout state is tracked.

• Custom HUD layout state schema nudges: Both client and server schemas for CCSCustomHudLayoutState have been adjusted, with a field for CPlayerSlot m_playerSlot effectively updated.
  • While the net result looks like a no‑op in the header listing, it indicates that internal plumbing for per‑player HUD layout state has been revisited.
  • This may help ensure that custom HUDs stay properly synced to the correct player slot across client and server.
• New internal filters: A new internal OwningSlotOnlyRecipientsFilter appears on both client and server.
  • This likely affects how certain messages or effects are targeted only to the owning player’s slot.
  • For custom HUDs or item‑related UI, this could help tighten which player receives which updates.
• HUD buy zone message cleanup: The #SFUI_BuyMenu_NotInBuyZone string has been adjusted slightly (removing a stray control character), which should make that buy‑menu warning more consistent in UI code.

These are low‑level changes, but they point toward ongoing work on per‑player HUD correctness and message routing.

Scripting example and documentation polish

The cs_script_demo addon and its TypeScript typings get a few quality‑of‑life documentation updates that matter for anyone using them as a learning resource.

• Example references updated:
  • Comments no longer refer generically to script_zoo.vmap; they now point directly to the cs_script_demo example addon and its cs_script_demo.vmap.
  • The hello_cs_script example is called out as living inside this demo map, making it easier for new creators to locate a working reference.
• CustomHUD docs expanded:
  • The description of supported panel types and attributes for CustomHudLayouts has been reorganized into a clearer bullet structure.
  • Extra explanation is provided on how the welcome example layout and CSS interact, including the Dismissed class toggle from setup.js.

This doesn’t change game behavior, but it makes the official example addon a more reliable starting point for community creators.

Build and version bump

Finally, there’s a routine version and build refresh that marks this as a distinct CS2 patch.

• Version numbers updated:
  • ClientVersion and ServerVersion have both been incremented.
  • PatchVersion has moved from 1.41.7.7 to 1.41.7.8.
• New source revision and build ID:
  • Internal SourceRevision and build identifiers have been bumped, indicating a new compiled build of the game.

These changes don’t imply specific balance or feature additions by themselves, but they formally wrap the scripting, UI, and documentation improvements into a new live version.

Overall impact

Taken together, this update is a small but meaningful step for creators working with CS2’s scripting and custom HUD systems. Players won’t see major front‑facing changes, but Workshop authors and modders get clearer examples, better Hammer labeling, and slightly more robust internals for per‑player HUD state and addon handling. Future custom game modes and scripted experiences should be a bit easier—and safer—to build on top of these refinements.