/* ══════════════════════════════════════════════════════════════════
   ESTÉTICA DO COMBATE — a metade em DOM do #73.

   O `translate` e a largura da barra são calculados no JS (dependem do
   tamanho do canvas); aqui fica só o que é fixo.
   ══════════════════════════════════════════════════════════════════ */

/* ── 1. a barra de vida acima do personagem ─────────────────────── */

/*
 * `position: absolute` e não só um `translate`: assim ela SAI DO FLUXO da
 * doca. Com o translate sozinho ela continuaria ocupando a linha de cima e
 * deixaria um buraco de 30px entre a barra de habilidades e a borda.
 *
 * `left/bottom: 0` a leva ao canto da doca; quem a põe no lugar certo é o
 * `translate` que o JS escreve, medido a partir daí.
 */
.hpbar--acima {
  position: absolute;
  left: 0;
  bottom: 0;
  height: 22px;
  padding: 0 9px;
  gap: 7px;
  font-size: 11px;
  /* Um pouco mais escura e com contorno: sobre o cenário claro do jogo a
     versão do rodapé (que vivia sobre o preto) perdia legibilidade. */
  background: #00050ceb;
  box-shadow: 0 2px 8px #000000a6, inset 0 0 0 1px #ffffff14;
}

/*
 * Some enquanto o herói corre entre as fases.
 *
 * O desenhista carimba a fase no canvas dos atores
 * (`set phaseName(t){this.glCanvas.dataset.phase=t}`), então dá para ler o
 * estado do jogo em CSS puro, sem JS e sem estado meu. Nas fases `leaving` e
 * `gap` o herói está fora da tela — e uma barra de vida sozinha no vazio é a
 * pior parte de mover a barra para junto do personagem.
 */
.hpbar--acima {
  transition: opacity 0.18s ease;
}

/* 🚨 Ancorado na `.scene`, não na `.scene-canvas`: a `.scene__dock` (onde a
   barra mora) é IRMÃ do canvas, não filha dele. Com `.scene-canvas:has(...)`
   o seletor casava com o canvas mas nunca alcançava a barra — medido, a
   opacidade ficava em 1 nas quatro fases. */
.scene:has(canvas[data-phase='leaving']) .hpbar--acima,
.scene:has(canvas[data-phase='gap']) .hpbar--acima,
.scene:has(canvas[data-phase='entering']) .hpbar--acima {
  opacity: 0;
}

/*
 * 🚨 `entering` entrou na lista no #109.
 *
 * Eu já escondia a barra em `leaving` e `gap`, mas deixava reaparecer em
 * `entering` — e nessa fase o herói ainda está CORRENDO de fora da tela para o
 * lugar dele. O resultado era a barra de vida flutuando sozinha e o personagem
 * chegando depois. Agora ela só volta quando a luta começa, e a transição de
 * opacidade que já existe faz a entrada ser suave em vez de um estalo.
 */

.hpbar--acima img {
  width: 13px;
  height: 12px;
}

.hpbar--acima .bar {
  height: 12px;
}

.hpbar--acima .hpbar__value {
  font-size: 10px;
}

/* ── 4. o flash da barra do inimigo ─────────────────────────────── */

.enemy-plate--apanhou {
  animation: ep-apanhou 0.22s ease-out;
}

/*
 * `filter` em vez de mudar cor: a placa é desenhada com `border-image`, então
 * não há uma propriedade de cor para animar. O brilho avermelhado atravessa a
 * arte inteira e volta, sem redesenhar nada.
 */
@keyframes ep-apanhou {
  0% {
    filter: brightness(1.9) saturate(2.4) drop-shadow(0 0 6px #ff3a2ecc);
  }
  100% {
    filter: none;
  }
}

/* ── 3. o tremor dos críticos muito altos ───────────────────────── */

.scene-canvas--treme {
  animation: cena-treme 0.2s ease-out;
}

@keyframes cena-treme {
  0% {
    translate: 0 0;
  }
  22% {
    translate: -4px 2px;
  }
  45% {
    translate: 3px -2px;
  }
  68% {
    translate: -2px 1px;
  }
  100% {
    translate: 0 0;
  }
}

@media (prefers-reduced-motion: reduce) {
  .enemy-plate--apanhou,
  .scene-canvas--treme {
    animation: none;
  }
}


/* 18/09, pedido do Zerg: interruptor "HUD de combate" (painel Ações admin)
   — `body[data-cenario-hud="off"]` é escrito por combate/index.js a partir
   de combate.hudLigado. Some a barra de vida e a placa do inimigo, nada
   mais — o HP real não muda, só o que aparece na tela. */
body[data-cenario-hud='off'] .hpbar,
body[data-cenario-hud='off'] .enemy-plate {
  display: none !important;
}


/* 18/09 ~13h30, 4ª rodada — achado testando "tudo desligado" ao vivo: as
   barras de vida/mana flutuantes acima de herói/aliados/inimigos são
   OUTRO sistema (`.bt-campo`, de `batalha/campo.js`), sem relação com
   `.hpbar`/`.enemy-plate` acima. Mesma intenção do Zerg ("barra de vida"),
   reaproveita o MESMO interruptor — não cria chave irmã pra a mesma coisa.

   🚨 18/09 ~22h, achado real (Rafael reportou battle fx de ataque dos
   companions nunca aparecendo): `.bt-campo` foi REAPROVEITADA por
   `companions-render/index.js` (`garantirCamadaFxMob()`) só pelo tamanho/
   posição em % que ela já dá (bate com o palco, não o viewport) — não tem
   NADA a ver com HUD/barra de vida. Essa regra pegava ela também sem
   querer: toda vez que `combate.hudLigado` estava OFF, o efeito de
   ATAQUE dos companions em cima do mob ficava com `display:none` herdado
   do pai, 0×0px, tecnicamente "carregado" (a `<img>` tinha o `src` certo)
   mas invisível de verdade — o que enganou até uma verificação técnica
   (`getBoundingClientRect` só foi olhado depois de horas de investigação).
   `:not(#companions-render)` exclui só o container reaproveitado (tem
   esse id de propósito, "mesmo hack de ID repetido que `raiz` já usa" —
   ver comentário em `garantirCamadaFxMob()`), sem tirar o poder do
   interruptor sobre a barra de vida/mana de verdade (`campo.js`, sem id
   nenhum). */
body[data-cenario-hud='off'] .bt-campo:not(#companions-render) {
  display: none !important;
}

/* 18/09 ~13h30, 4ª rodada — `combate.fundoLigado` já existia e já limpava o
   canvas (ver CombatCanvas-CWCkqOUN.js), mas o `.scene` (`comum/base-visual.css`)
   tem sua PRÓPRIA cor de fundo fixa via CSS (`#000d1e`), nunca gateada — era
   o "fundo escuro" que o Zerg via mesmo com o canvas já transparente. Só a
   `background` muda; borda/sombra/cantos arredondados do quadro continuam. */
body[data-cenario-fundo='off'] .scene {
  background: transparent !important;
}