CS2 Update (Sep 9, 2026)

This update focuses on new GOTV encryption controls, a more flexible custom camera system for scripts and spectators, and some groundwork clean‑up in networking and tools.

GOTV encryption and chat relay controls

Several new options have been added around how GOTV data is sent and who can read it, aimed at tournament organizers, broadcasters, and server operators.

• Client-side decryption keys:

  • cl_decryptdata_key – Key to decrypt encrypted GOTV messages.
  • cl_decryptdata_key_pub – Key to decrypt public encrypted GOTV messages.

  These convars let compatible clients (for example, casting tools) provide keys to decode encrypted data coming from GOTV. This appears targeted at official or private broadcast setups rather than regular players.

• Server-side encryption keys:

  • tv_encryptdata_key – When set to a valid key, communication messages will be encrypted for GOTV.
  • tv_encryptdata_key_pub – When set to a valid key, public communication messages will be encrypted for GOTV.

  With these set, GOTV traffic can be encrypted on the server before being sent to viewers or broadcast tools. This likely helps protect sensitive information such as team comms or tactical data in high‑level events.

• Encrypted network message type:

  • New service message svc_EncryptedData with CSVCMsg_EncryptedData carries encrypted payloads and a key_type value.
  • Voice packets (CSVCMsg_VoiceData) now include a caster flag, which may be used to distinguish caster voice from player voice in GOTV.

  Together, these changes suggest a more robust pipeline for selectively encrypting different categories of GOTV data (for example, team comms vs. public comms) while still letting authorized tools decode them.

• GOTV chat relay options:

  • tv_relaytextchat – Relay text chat data to GOTV: 0 = off, 1 = say, 2 = say+say_team.
  • tv_show_allchat has been removed.

  Server operators now have more explicit control over which in‑game text chats are visible to GOTV viewers, including the option to relay team‑only chat.

Chat user messages and legacy compatibility

User message definitions have been adjusted in a way that appears to clearly separate CS2 behavior from legacy CS:GO formats.

• Renamed legacy user messages:
  • CS_UM_SayText, CS_UM_SayText2, CS_UM_TextMsg, and CS_UM_UpdateTeamMoney have all been relabeled with a _CSGOLegacy suffix in the internal enums.

This suggests that CS2 is explicitly tagging certain message types as CS:GO‑legacy formats while still keeping them available. Plugins, tools, or third‑party services that rely on raw user message IDs may need to be aware that these are now clearly identified as legacy, though the numeric IDs are unchanged.

Additionally, the user messages for chat now carry more metadata:

• New textallchat field:
  • CUserMessageSayText and CUserMessageSayText2 now include a textallchat boolean.

This extra flag appears designed to indicate whether a given message is part of an "all chat" context, which may help HUDs, parsing tools, and overlays distinguish global chat from team or local chat more reliably.

New CustomPlayerCamera system for scripts and spectators

The update introduces a new, more capable camera system for scripted content and marks the older interface as deprecated.

• New camera API in point_script:

  • CSPlayerPawn.GetCustomCamera() now returns a CustomPlayerCamera.
  • The previous GetCamera() method remains for now but is explicitly marked as deprecated.

• CustomPlayerCamera class:

  • Exposed to scripts as CustomPlayerCamera (and internally as CCSCustomPlayerCamera).
  • Key methods:
    • GetPlayer() – Returns the associated CSPlayerPawn.
    • GetMode() / SetMode(mode: CustomCameraMode) – Control how the camera behaves.
    • SetFollowConfig(followConfig: CameraFollowConfig) – Configure what the camera follows and how.

• Camera modes (CustomCameraMode / CustomCameraMode_t):

  • DISABLED – Camera uses the player’s normal eye position and angles.
  • CONTROLLED – Position and angles come directly from the camera entity.
  • CONTROLLED_POSITION – Position comes from the camera entity; angles are still player‑controlled.
  • FOLLOW_POSITION – Position follows a configured offset around a followed position; angles are player‑controlled.

• CameraFollowConfig options:

  • followEntity – The entity to follow.
  • followEyes – Whether the follow position is based on the entity’s eyes instead of origin.
  • followOffset – Offset from the follow position.
  • cameraOffset – Offset around the followed position, rotated by the player’s eye angles.
  • clipCameraOffset – Whether the camera should be pulled in to avoid clipping into solids.
  • cameraOffsetReturnStrength – How strongly the camera returns to its ideal offset after being clipped.

For creators using cs_script, this opens up more advanced spectator and cinematic setups: following players from configurable offsets, orbiting shots that respect collision, and camera rigs that do not require moving the actual player pawn. The system is marked as experimental, so scripts using it may need updates as Valve iterates.

• Old CSPlayerCamera deprecated:
  • GetCamera() and the CSPlayerCamera class are still present but are marked to be removed in a future update.
  • The old fields like m_bEnabled and m_bIsControllingAngles have been removed in favor of the new unified CustomPlayerCamera base.

Map and mode authors relying on the old camera should plan to migrate to CustomPlayerCamera and GetCustomCamera().

Custom HUD layout observability

Custom HUD layouts have gained an extra piece of metadata that appears to control what spectators can see.

• New Observable property in Hammer (csgo.fgd):

  • The cs_custom_layout (Panorama UI entity controlled by cs_script) now has an observable(boolean) key:
    • Description: "Show each player's own version of this UI to whoever is spectating them."

• Matching network field:

  • Internal CCSCustomHudLayout has gained a m_bObservable boolean on both client and server.

In practice, this means scripted HUD elements can opt into being visible to spectators the same way the built‑in HUD is. Tournament overlays or custom informational panels can, in theory, be authored once and then automatically shown to viewers following that player, improving the spectator experience.

Tools, languages, and packaging

The update also includes smaller clean‑up and background changes.

• Map icon assets:

  • Manifest entries for de_cache Panorama map screenshot icons across multiple resolutions (360p, 720p, 1080p) have been touched but end up with the same paths before and after. This often indicates asset repacks or minor revisions rather than visible changes, but it may reflect updated or re‑compressed loading screen images for that map.

• Localization resource entries:

  • Manifest references to resource/csgo_dutch.txt, csgo_romanian.txt, csgo_schinese.txt, csgo_swedish.txt, and csgo_tchinese.txt were cycled but remain present. This suggests internal updates or repacks to these language files rather than the addition or removal of a language.

• Networking and tools strings:

  • Various engine and tool binaries have had internal strings updated in line with the new GOTV encryption message type and camera changes.
  • Some older references to a generic key_type string in several tools have been removed, likely as part of consolidating how encryption keys are handled.

These changes should not affect regular gameplay directly but may benefit tooling stability and future features.

Overall impact

For most players, this update will be largely invisible day‑to‑day. The main beneficiaries are:

• Tournament and broadcast setups, which get more granular GOTV encryption and chat‑relay control, plus clearer separation of public vs. sensitive data.
• Script and map authors, who gain a significantly more powerful CustomPlayerCamera system and the ability to mark custom HUD layouts as spectator‑visible.
• Tool and plugin developers, who should be aware of the new and renamed user messages, extra chat metadata, and the new encrypted network message type when updating integrations.

As the new camera and HUD systems are explicitly marked experimental and some older APIs are deprecated, community creators may want to start adapting now to stay ahead of future breaking changes.