Atualização do CS2 (30 de set. de 2026)

Esta atualização reescreve profundamente o script e a interface do modo Rush 001, acrescenta uma nova leva de shaders Vulkan, amplia substancialmente as opções de personalização da mira (incluindo um novo estilo em quadrantes e cor/alpha do contorno) e refina a cadeia de ferramentas e os dados de itens de torneio.

Atualizações da Mira e HUD

• Novo estilo e limites: a convar cl_crosshairstyle passa a aceitar valores até 9, com o estilo 9 definido na UI como Static Quadrant. O estilo 7 foi renomeado em texto para Dynamic Quadrant para descrever melhor sua aparência.
• Intervalo de gap muito maior: cl_crosshair_gap agora aceita valores de -3840 a 3840 (anteriormente 0–128), permitindo ajustes extremamente compactos ou muito espalhados, úteis em resoluções elevadas.
• Leve aumento no limite de espessura: cl_crosshair_thickness agora suporta até 32 (antes o máximo era 31), para opções mais grossas.
• Controles de cor do contorno da mira: Novas convars por usuário cl_crosshairoutline_r, _g, _b e _a (0–255) definem a cor RGB e a opacidade do contorno. O menu de opções expõe isso como “Outline Color and Transparency”, permitindo separar cor interna e contorno para melhor visibilidade em diferentes mapas.
• Ajuste específico para quadrantes: As configurações adicionam um slider “Quadrant Size” (GameUI_StaticQuadSplitRatio) para as miras em quadrante, permitindo controlar o tamanho de cada seção.
• Remoção da arte reticle para friend/observer: Recursos antigos de HUD e entradas XML para imagens de retícula especiais de amigos/observadores foram removidos do layout do HUD e dos recursos de imagem, sugerindo consolidação na mira configurável principal em vez de sobreposições separadas.
• Clareza no painel de vitória: O gráfico de probabilidade de vitória e a lógica do painel MVP (hudwinpanel.js / hudwinpanel_background_map.js) receberam limpeza interna e comentários. O comportamento permanece, mas o código documenta melhor a sequência de eventos, o que facilita futuros polimentos.
• Ganchos de leitura de dano pós-rodada: O script de contador de equipe agora registra e gerencia os painéis de Post-Round Damage Report de forma mais explícita, integrando as classes de animação existentes. O comportamento não mudou, mas a refatoração facilita ajustes de tempo e visibilidade.
• Ajustes de UX no controlador de demos: O script da UI de demo possui comentários mais descritivos e melhor tratamento de estado interno para:
  • Alternância e texto de highlights vs. round playback
  • Posicionamento de marcadores de intervalo sob o slider da timeline
  • Tratamento de TrueView prediction e toggles DOA Essas mudanças visam robustez e clareza, não novas funcionalidades visíveis.

Rush 001: Reescrita Profunda do Script e QoL

O script principal de Rush 001 (maps/scripts/rush_001.js) foi reescrito com lógica mais clara e documentação inline detalhada. As regras de jogo não mudaram, mas o fluxo está muito mais explícito.

Detalhes comportamentais confirmados pelo script atualizado:

• Layout linear de tug-of-war: O modo é descrito como um tug-of-war de sete salas, com Terroristas empurrando em direção ao índice de sala 6 e CTs ao índice 0. Uma sala especial de decider (“Convoy”) é reservada para situações 9–9 e não entra na seleção aleatória normal.
• Seleção e identidade das salas: As salas são organizadas por índice com conjuntos de IDs elegíveis por slot (por exemplo, salas base em 301/401, cluster inicial 101–104, pools de mid 201–212). Comentários nomeiam salas (Spire, Trainyard, Crane, Hydra, etc.), mas na prática cada índice puxa de uma lista fixa de IDs elegíveis.
• Rastreamento de partidas e rounds:
  • O script rastreia vitórias de round por equipe internamente porque a API de scripting não expõe placares de equipe diretamente.
  • Detecta com cuidado quando o motor reinicia a partida (ex.: via mp_restartgame ou fim de partida) e então reseeda layout de salas e contadores para evitar dessincronizações.
  • Em warmup, a lógica de final de round é ignorada para que empates de warmup não corrompam o estado do tug-of-war.
• Lógica de frontline e vitória:
  • Ao fim do round, o índice da frontline é ajustado na direção da equipe vencedora.
  • Se a frontline ultrapassar a base mais distante (além do primeiro ou último índice jogável), a partida termina imediatamente em favor dessa equipe.
  • Se os rounds máximos se esgotarem com ambas as bases ainda de pé, o vencedor é decidido primeiro por total de vitórias de round e, em caso de empate, por qual lado empurrou a frontline mais perto da base inimiga. Se ambos ficarem exatamente equilibrados ao redor da sala inicial, o resultado é tratado como empate.
• Comportamento do round decisor: Quando ambas as equipes estão a uma vitória de distância (ex.: 9–9 numa corrida de 19 rounds) ou via cheat forçado, o script insere a sala Convoy como o decider na slot da frontline; essa sala decide a partida.
• Tempo de round por sala: Salas base têm timers de round maiores que salas de mid. O script calibra mp_roundtime com uma rodada de antecedência para que a duração pretendida da próxima sala seja capturada quando o motor fixar o tempo de round.
• Tratamento de eliminação de equipe:
  • O script detecta se uma equipe foi totalmente eliminada garantindo que equipes vazias (em testes) não percam automaticamente.
  • Se ambas as equipes forem derrotadas, o controlador da sala atual decide o vencedor; caso contrário, a última equipe de pé vence.
  • Casos de wipe sem kills (ex.: desconexões) têm um mecanismo de verificação adicional após capturas de botão.
  • A flag opcional END_ROUND_ON_TEAM_ELIMINATION existe, mas está desligada por padrão.
• Contagem regressiva após eliminação: Se a eliminação não terminar a rodada de imediato, o script pode iniciar uma contagem regressiva com um bip terminal e som de fim de tempo, permitindo ainda que capturas de sala influenciem o resultado.

Antena, Beacons e Sons

O sistema de torre/antena foi clarificado e desacoplado de peculiaridades de autoria de mapas:

• Uma antena compartilhada por mapa: Em vez de cópias por sala, uma montagem de antena é teleportada para a sala ativa a cada round com base em entidades marcador (ant.base.<id>, ant.top.<id>), mantendo visuais consistentes e reduzindo custo de gerenciamento.
• Tops altos vs. baixos: Certos IDs de sala usam um mastro mais curto (teto baixo); ambos os tops são teleportados e o não usado é explicitamente ocultado e com colisão desabilitada.
• Luzes laterais por sala: Cada sala contém um par de light_barn (ex.: ant.side.light.201.a/b), tingidas conforme a equipe que controla a sala. O script:
  • Itera todas as salas e liga luzes somente para a sala ativa, desligando as demais, reduzindo custo de iluminação dinâmica em espaços não usados.
  • Usa uma tabela central de cores por equipe para manter antena, bandeiras e glow consistentes.
• Glow da antena durante freezetime:
  • No início do round, a antena brilha na cor da equipe proprietária durante o freeze para destacar o objetivo.
  • Quando o round entra ao vivo (fim do freeze), o brilho é removido. Não existe callback separado de freezetime; o script observa IsFreezePeriod() e alterna ao detectar a transição.
• Estado lógico vs. visual da antena:
  • O script diferencia entre o controle lógico de uma sala (_roomStates) e a cor visual da antena (_antennaTeam), especialmente ao fim do round.
  • Ao terminar o round, o script atualiza propriedade das salas mas adianta a repintura da antena até o próximo round, para que a última cor viva permaneça associada à presença de jogadores.
• Botões e beacons:
  • O único botão compartilhado na antena emite eventos OnPressed que o script reconecta a cada round.
  • Ao pressionar:
    • Toca um beacon de “press” ou “error” dependendo se a equipe já controla a torre ou se o round já está decidido.
    • Atualiza controle da sala, luzes da antena e UI quando válido.
  • Entidades sonoras para idle hum, press, error, countdown beeps e time expiry são repontadas dinamicamente para o botão da sala atual, evitando duplicação por mapa.

Bips do Timer e Áudio de Término de Round

• O sistema de contagem terminal agora tem estágios de tempo explícitos e regras de agendamento:
  • Vários estágios de tempo, cada um com um número fixo de bips (ex.: intervalos de 1.0s, 0.5s, 0.25s, 0.125s), são usados à medida que o timer se aproxima de zero.
  • O script rastreia o próximo tempo de bip e a contagem de bips emitidos, avançando pelos estágios conforme os bips são consumidos.
  • Há uma pequena tolerância para que um tick de think que ocorra pouco antes do tempo programado ainda emita o bip, evitando atrasos acumulados.
  • Se o servidor travar e ficar mais atrasado que um intervalo, a agenda re-ancora no tempo atual para evitar que os bips se agruem.
• Um som de timer end toca apenas quando a rodada expira realmente por tempo; vitórias por eliminação suprimem esse som para não induzir ao erro.

Névoa e Atmosfera do Mapa em Rush

• O script centraliza presets de fog e mapeamentos sala → fog:
  • Espera-se um env_gradient_fog chamado fog controlado via inputs scriptados.
  • Presets (ex.: exterior, interior, tunnel, base) especificam cor, distância de início/fim, opacidade e falloff.
  • Cada ID de sala é mapeado a um preset (ex.: configurações interiores para salas apertadas, tunnel para esgotos, base para castelos).
  • Salas ausentes no mapa recorrem a um preset padrão.
• Esse sistema mantém a legibilidade visual do Rush e facilita ajustes de visibilidade e clima por sala sem trabalho manual extenso.

UI do Rush e Feedback ao Jogador

• O HUD específico do Rush (rush_ui panorama layout) é dirigido com mais precisão:
  • Uma lista canônica de nomes de classes de painel de sala (ex.: room_101) permite ao script limpar classes antigas e aplicar novas ao mostrar progressão.
  • No início do round, o script:
    • Atualiza indicadores de propriedade para a sala da frontline.
    • Decide entre animação de slide forward ou backward dependendo da equipe que avançou, ou animação neutra se ninguém progrediu.
  • O mesmo painel de progressão é reutilizado para ambas as equipes, com classes por jogador como view-t e view-ct para orientar cada lado pela sua perspectiva.
• Para cada jogador, o UI de hint atacar/defender é atualizado conforme a equipe que controla a torre, com variantes CT/T e descrição neutra para espectadores.
• O código de UI é resiliente a warmup e entidades ausentes (ex.: se o Rush UI não existe, o script ignora chamadas em silêncio em vez de gerar erro).

Economia de Itens de Torneio: Lógica de Capsulas Cologne 2026

Mudanças focadas em items_game.txt relacionadas a stickers e packs de highlights de Cologne 2026:

• Novo prefab de cápsula volátil: Introduzido cologne2026_sticker_capsule_prefab_volatile. Herdando do prefab principal, define "volatile container" "3".
• Crates referenciam o prefab volátil: Vários packs Cologne 2026 (ex.: all-team, champion, rankings e highlights stages 1–6) agora usam o prefab _volatile mais os modificadores volatile_pricing_*, em vez de adicionar volatile container diretamente no item. Exemplos incluem crate_sticker_pack_cologne2026_all, crate_sticker_pack_cologne2026_champion e múltiplos crate_highlights_pack_cologne2026_X que referenciam cologne2026_sticker_capsule_prefab_volatile.
• Atributos voláteis centralizados: Os atributos "volatile container" "2" foram removidos dos crates individuais e movidos para o prefab _volatile, indicando centralização de como o comportamento de preço/suprimento volátil é definido.
• Campos relacionados a spray removidos: Um prefab Cologne 2026 tinha "type" "spraypaint", um item_slot2/item_sub_position2 secundário spray e inv_graphic_art igual a graffiti. Esses campos foram removidos, indicando que esse item de torneio não é mais tratado como spray-like.

No impacto prático, isso parece ser uma preparação de backend para como cápsulas de sticker/highlight de Cologne 2026 serão vendidas e precificadas. O comportamento de mercado ou apresentação UI pode mudar quando a Valve habilitar esses itens, mas esta atualização reorganiza dados sem introduzir diretamente os itens ao jogador.

Pets e Vanity: Álbum de Fotos e Dicas

Scripts Panorama e recursos relacionados a pets e ao pet book também foram atualizados:

• Novas entradas VTex para múltiplas páginas do pet book (ex.: “early days”, “road trip”, “park life”, “balloons”) foram adicionadas para as visuais do álbum.
• A localização em inglês expande várias strings de hint do pet book:
  • A linha anterior pet_book_hint_adolescent_road_trip foi dividida em duas variantes, cada uma nomeando conjuntos de mapas como “Dust II, Baggage, Inferno, or Train” e “Mirage, Nuke, Cache, or Ancient”.
  • Isso sugere que o sistema de progressão de pets pode usar categorias de mapas mais específicas ao dar desafios de foto, embora não haja mudança de gameplay confirmada.
• Múltiplos scripts Panorama (pet_book_pages.js, pet_book_turn.js, vanity_pet_info.js, pet_photo_* popups) foram tocados no grande refactor de UI. O comportamento aparenta ser mantido, com código mais limpo e documentado.

Suite de Shaders Vulkan e Pipeline de Ferramentas

Uma parte substancial do update afeta o pipeline de shaders e ferramentas, impactando criadores, modders e performance.

Novos e Atualizados Shaders Vulkan

• Dezenas de definições *.slang sob shaders_vulkan_dir/shaders/vfx/ foram adicionadas ou atualizadas, incluindo:
  • Shaders de material core: csgo_character.slang, csgo_vertexlitgeneric.slang, csgo_lightmappedgeneric.slang, csgo_unlitgeneric.slang.
  • Shaders de arma e luvas: csgo_customweapon.slang, csgo_customglove.slang, e csgo_customglove_preview.slang para previews de inspeção.
  • Ambiente e decals: csgo_projected_decals.slang, csgo_decal_renderer.slang, csgo_water.slang, csgo_decalmodulate.slang, csgo_beachfoam.slang.
  • UI e propósitos especiais: csgo_crosshair.slang, tools_wireframe.slang, csgo_tools_shading_complexity.slang, sky.slang, spritecard.slang.
• As manifests para os diretórios de shader Vulkan e PC foram atualizadas para incluir esses arquivos.

Para jogadores, isso deve significar ganhos de estabilidade e performance no Vulkan e visuais mais consistentes para personagens, armas, luvas, decals e UI. Para criadores, padroniza o conjunto de shaders específicos do CS2, facilitando direcionamento ao pipeline pretendido.

Defaults do Resource Compiler e Integração em gameinfo.gi

O gameinfo.gi principal do CS2 foi expandido, fundindo configurações antes espalhadas em arquivos “core” ou importados para um único arquivo. Destaques confirmados:

• Defaults de engine e renderização:
  • SteamAppId definido explicitamente para 710 e sistemas de mod/ferramentas marcados como 64-bit.
  • Sistema de render padrão e de tools setados para -dx11, com um bloco RenderingPipeline que:
    • Habilita pós-processamento na pipeline principal
    • Suporta MSAA
    • Habilita modos de visualização de tools e iluminação de alta precisão
• Console e input QoL:
  • PauseOnCtrlConsole forçado para 0, evitando comportamento onde segurar Ctrl + toggle do console pausava o jogo—alinhado ao comportamento do CS:GO.
  • RestrictConsoleCloseKey setado para `, permitindo que binds não padrão abram mas não fechem o console; Escape sempre fecha, novamente como no CS:GO.
  • cl_joystick_enabled e panorama_joystick_enabled defaultadas para 0, podendo ser ativadas pelo jogador.
• Convars novos ou fixados:
  • demo_max_consecutive_skip_packets com default 2500, limitando quanto o demo pode pular numa única ação.
  • r_particle_batch_collections setado para 1, potencialmente melhorando batch de partículas.
  • spec_replay_enable com min/max de 0, efetivamente restringindo replay de espectador por configuração do usuário no momento.
• Defaults do resource compiler:
  • Construção de mapa: Builders padrão agora incluem lighting baked (bakedlighting), nav mesh (nav) e múltiplas passagens Steam Audio (sareverb, sapaths, sacustomdata).
  • MeshCompiler: Habilita encoding de vertex/index buffer, dados de culling por draw, meshlets, geração de tangentes MikkTSpace e divisão de depth stream.
  • WorldRendererBuilder: Ativa clustering guiado por visibilidade, uso de envmap estático para certos objetos, baking para escala não uniforme e instancing agregado.
  • Baked lighting: Configura builds determinísticos, uso de LPV, tamanhos default de lightmap e gutters, múltiplos canais de lightmap (irradiance, shadows, directional irradiance, debug colors) com compressão DXT1.
  • VisBuilder: Limita clusters de vis a 4096 e habilita builds determinísticos com thresholds para merge de espaços abertos.
  • Compilação de texturas: Usa compressão lz4, mips comprimidos em disco, textures non-power-of-two, geração de mips Panorama e resolução máxima pública de tools de 2048.

Para mappers e criadores, essa consolidação torna o comportamento do Hammer e resourcecompiler mais previsível para CS2, com escolhas específicas do CS:GO codificadas como defaults.

Scene, Áudio e Sistemas de Ferramentas

Módulos de engine e ferramentas ganharam capacidades novas ou defaults mais seguros:

• SceneSystem:
  • Confirma uso de GPU light binning, resolução dinâmica de sombras, sparse shadow trees, sombras de point lights, decals em personagens, firstperson legs, suporte híbrido a instanced fade e múltiplas opções de tonemapping e fog.
  • Introduz slots de well-known light cookie para blank, flashlight e muzzleflash, apoiados por texturas em materials/effects/lightcookies/.
• Particles:
  • Declara que partículas são fogged por default, suportam mixed resolution e podem deslocar traces de colisão ajustados para CS2.
• WorldRenderer:
  • Padroniza settings de environment map (blur GGX, formato BC6H, cube arrays, atlas por mapa) e define parâmetros de renderização de grama.
• NavSystem:
  • Parâmetros globais de navmesh (tile size, cell size/height, region thresholds, max poly edge length, detail sampling) são definidos, com NavHullsPreset default e interface de build carregada de server.dll.
• Hammer:
  • Confirma que o Hammer do CS2 usa csgo.fgd + csgo_internal.fgd, conjunto de features Counter-Strike, terrain tools, Steam Audio, lattice deformers, smart prop instance rendering e um shadow atlas de 6144x6144.
• ModelDoc e ferramentas de asset:
  • ModelDoc evidencia features específicas do CS2, trata materiais faltantes com maior rigor e converte warnings em errors para caminhos-chave como agentes e modelos de arma, elevando a qualidade de conteúdo.

Limpeza do Protocolo de Networking

• Vários tipos de mensagens do Game Coordinator e o enum EInitSystemResult foram removidos do cstrike15_gcmessages.proto compartilhado e dos esquemas cliente-correspondentes:
  • GC2ClientRefuseSecureMode
  • GC2ClientRequestValidation
  • GC2ClientInitSystem
  • GC2ClientInitSystem_Response
• Campos relacionados a manifests de módulo, pacotes de sistema e resultados de validação foram excisados.

Isso sugere que o jogo está aposentando um conjunto antigo de mensagens e campos do protocolo de inicialização/validação do GC, alinhando o sistema a uma interface mais enxuta.