Atualização do CS2 (26 de ago. de 2026)

Uma pequena atualização do CS2 aprimora silenciosamente o suporte a HUDs personalizados para mapas scriptados, ajusta como addons são tratados pelo sistema de UI Panorama e melhora a documentação para criadores que experimentam com cs_script e Panorama.

Layouts de HUD personalizados para mapas scriptados

Esta atualização concentra‑se em melhorar e esclarecer o funcionamento dos layouts de HUD personalizados em addons e mapas scriptados.

• Documentação de CustomHudLayouts mais clara: O exemplo cs_script_demo e as definições TypeScript de point_script agora explicam como construir um layout de HUD personalizado para seu addon:
  • É possível usar um conjunto limitado de painéis Panorama: Panel, Label, Image e Button, com atributos suportados como id, class, hittest, text e src.
  • Estilização via CSS (.vcss assets) é suportada, mas eventos e scripts do lado do cliente dentro do próprio layout são explicitamente não suportados.
  • A documentação passa por um exemplo concreto no addon cs_script_demo: uma entidade custom_hud_layout chamada welcome_layout que exibe o layout welcome.vxml e usa um arquivo CSS correspondente.
• Orientação prática de configuração: Criadores recebem instruções passo a passo sobre como ligar tudo:
  • Coloque seu layout Panorama .xml (na prática um asset .vxml) em panorama/layout/custom_game dentro do addon.
  • Adicione uma entidade ponto custom_hud_layout ao mapa e aponte sua propriedade layout para esse .vxml.
  • Use um arquivo CSS em panorama/styles/custom_game para controlar a aparência; o exemplo mostra um painel dialog cuja classe Dismissed é removida a partir de um arquivo cs_script (maps/scripts/setup.js).

Essas mudanças são melhorias de documentação e ferramentas, não novas funcionalidades de jogo, mas devem facilitar que criadores do Workshop construam HUDs personalizados polidos sem adivinhações.

Rotulagem de entidade e editor melhorada para HUDs personalizados

Usuários do Hammer e autores de mapas ganham um ajuste pequeno, porém útil, que facilita o trabalho com entidades de HUD personalizadas.

• Nome de campo mais claro para custom_hud_layout: Na definição FGD do jogo, a chave layout da entidade custom_hud_layout agora tem um nome de exibição mais claro ("Layout") e uma descrição:
  • O campo é descrito explicitamente como um recurso de layout Panorama com tipos de painel e atributos limitados suportados.
  • Isso ajuda level designers a entenderem rapidamente o que estão selecionando no Hammer e como isso se relaciona à documentação do cs_script.

Na prática, isso deve reduzir confusões ao ligar layouts de HUD aos mapas, especialmente para quem segue o exemplo cs_script_demo.

Esclarecimento sobre comportamento de câmeras em scripts

Para scripters que experimentam controle de câmera, há uma orientação adicional sobre como as câmeras dos jogadores são gerenciadas.

• Nota sobre câmera por jogador: As definições de point_script agora explicam que o objeto de câmera usado para controlar a visão de um jogador sem mover seu pawn:
  • Existe no máximo uma vez por CSPlayerPawn.
  • É criado sob demanda quando CSPlayerPawn.GetCamera é chamado.

Isso não introduz nova funcionalidade por si só, mas oferece um modelo mental mais claro de como o controle de câmera scriptado é estruturado, ajudando autores a evitar suposições incorretas ou o uso indevido de múltiplas câmeras por jogador.

Depuração de confiança de addons e comportamento do Panorama

Há algumas mudanças sutis por baixo dos panos sobre como o Panorama e os addons são tratados, que interessarão mais a desenvolvedores, modders e fluxos de depuração.

• Novo convar de depuração de confiança de addon: Foi adicionado um convar oculto, apenas para desenvolvimento, chamado panorama_debug_treat_all_addons_as_untrusted.
  • Está claramente marcado como uma opção de depuração defensiva, não como uma configuração voltada para jogadores.
  • Provavelmente existe para permitir que desenvolvedores simulem todos os addons sendo tratados como “não confiáveis” pelo sistema de UI, ajudando a testar o comportamento do CS2 sob restrições de segurança mais rígidas.
• Mensagens sobre criação de arquivos Panorama ajustadas: Strings internas de UI Panorama relacionadas a impedir a criação de arquivos de layout, script ou estilo foram limpas.
  • Referências ao cliente “impedindo” a criação de arquivos de layout/script/style do Panorama foram removidas dos logs internos.
  • Isso sugere que o tratamento ou a mensagem do motor nesses casos foi simplificada, o que pode alterar como erros ou restrições aparecem em ferramentas de desenvolvedor ou logs.

Para jogadores comuns, essas mudanças provavelmente não serão visíveis, mas para desenvolvedores de UI e addons elas podem alterar como certos casos de borda são registrados e depurados.

Internos do cliente, servidor e estado do HUD

Um conjunto de pequenas mudanças internas afeta código do cliente e do servidor, especialmente sobre como o estado de layout do HUD é rastreado.

• Ajustes no esquema de estado de layout de HUD: Os esquemas do cliente e do servidor para CCSCustomHudLayoutState foram ajustados, com um campo para CPlayerSlot m_playerSlot efetivamente atualizado.
  • Embora o resultado aparente seja um no‑op na listagem do header, isso indica que a tubulação interna para o estado de layout por jogador foi revisitada.
  • Isso pode ajudar a garantir que HUDs personalizados fiquem sincronizados com a slot do jogador correta entre cliente e servidor.
• Novos filtros internos: Um novo OwningSlotOnlyRecipientsFilter aparece tanto no cliente quanto no servidor.
  • Isso provavelmente afeta como certas mensagens ou efeitos são direcionados apenas à slot do jogador proprietário.
  • Para HUDs personalizados ou UI relacionada a itens, isso pode restringir melhor quem recebe quais atualizações.
• Limpeza em mensagem do HUD de compra: A string #SFUI_BuyMenu_NotInBuyZone foi ajustada levemente (remoção de um caractere de controle), o que deve deixar esse aviso do menu de compras mais consistente no código de UI.

São mudanças de baixo nível, mas indicam trabalho contínuo para a correção de estado por jogador e roteamento de mensagens.

Aprimoramento de exemplos e documentação de script

O addon cs_script_demo e seus typings TypeScript receberam algumas atualizações de qualidade de vida que importam para quem usa o exemplo como referência.

• Referências de exemplo atualizadas:
  • Comentários não se referem mais de forma genérica a script_zoo.vmap; agora apontam diretamente para o addon de exemplo cs_script_demo e seu cs_script_demo.vmap.
  • O exemplo hello_cs_script é destacado como estando dentro deste mapa de demonstração, facilitando a localização de um exemplo funcional.
• Docs de CustomHUD expandidos:
  • A descrição dos tipos de painel e atributos suportados para CustomHudLayouts foi reorganizada em uma estrutura de bullets mais clara.
  • Há explicações extras sobre como o layout de exemplo welcome e o CSS interagem, incluindo a troca da classe Dismissed a partir de setup.js.

Isso não altera o comportamento do jogo, mas torna o addon de exemplo uma base de partida mais confiável para criadores da comunidade.

Atualização de versão e build

Por fim, houve um refresh rotineiro de versão e build que marca este patch como uma compilação distinta do CS2.

• Números de versão atualizados:
  • ClientVersion e ServerVersion foram incrementados.
  • PatchVersion passou de 1.41.7.7 para 1.41.7.8.
• Novo SourceRevision e ID de build:
  • Identificadores internos de revisão e build foram atualizados, indicando uma nova compilação do jogo.

Essas mudanças não implicam necessariamente adições de balanceamento ou funcionalidades por si só, mas formalizam as melhorias de script, UI e documentação em uma nova versão.

Impacto geral

Em conjunto, esta atualização é um passo pequeno, porém relevante, para criadores que trabalham com os sistemas de script e HUD personalizados do CS2. Jogadores não verão grandes mudanças visíveis, mas autores do Workshop e modders ganham exemplos mais claros, rotulagem melhor no Hammer e internos ligeiramente mais robustos para estado de HUD por jogador e tratamento de addons. Modos personalizados e experiências scriptadas futuros devem ficar um pouco mais fáceis — e mais seguros — de construir sobre essas refinarias.