# Day 8 (продовження): WeaponHudC, ZombieInvasionHudC, InstallBanner-рестайл, шрифт, ротація (2026-08-13)

Усе нижче — **ще не закомічено** (тільки `4a22a9b`/`63609ee` в git; це
робота вже після другого коміту). `npm run export` вже прогонявся раз
успішно (з побічним авто-встановленням `three.quarks`, бо в `export.cjs`
своя мережева воркфлоу — див. окремий output_export_browser_en.html).

## `WeaponHudC.ts`/`ZombieInvasionHudC.ts` — нові статичні/напівстатичні юайки
Реалізовані аналогічно `HudC` (окремий контролер на юайку, `init()` з
`TestSceneC`). Ассети: `ZombiePunk_Icon-Bottom.webp`+`Tool_2.webp` для
зброї, `REF_1.png` (**насправді webp**, розширення джерела — брехня,
перевірено по сирих байтах RIFF/WEBP заголовку) для голови зомбі.

**ZombieInvasionHudC пройшов кілька раундів фідбеку**:
1. Спочатку `.zombie-invasion__bar` мав суцільний зелений `background`
   (статично "повний" від t=0) — користувач: "WARNING_FRACTION чомусь
   почався тільки коли шкала повністю заповнилась". Причина НЕ в
   таймінгу (`114000мс з 120000мс` — точно останні 5%, перевірено), а в
   тому, що шкала і так ЗАВЖДИ виглядала на 100% — різницю "майже" vs
   "повна" було неможливо побачити. **Фікс**: реальна заливка
   (`.zombie-invasion__track` з `overflow:hidden` + `.zombie-invasion__fill`,
   росте `width:0%->100%` з `right:0`, стартує в ТОЙ САМИЙ тік з тією ж
   тривалістю, що й голова — їхні межі математично завжди збігаються, без
   пофреймової синхронізації).
2. Голова мала бути БІЛЬШОЮ за саму шкалу (`0.24 * width` проти
   `0.15 * width` висоти бару) — але `.zombie-invasion__bar` мав
   `overflow:hidden` для заливки, що обрізало б і голову. **Фікс**: голова
   винесена сиблінгом `.zombie-invasion__track` (не її дитиною) — обрізає
   тільки заливку/флеш, не голову.

## InstallBanner (SDK-компонент) — свідомо НЕ переписаний, лише CSS-рестайл
Круглий портрет персонажа + кнопка "INSTALL" знизу — це **не наша**
юайка, а SDK `InstallBanner` (`node_modules/@hitplay/playable_template`,
підключений в `beforeResourcesLoadedCb.ts`) з реальним кліком
(`AnalyticsC.sendDownload()` -> `Template.end()`) і власною
конфіг-системою (`src/configUIParams/installBanner.ts`, `upload_file`
+ X/Y/scale-відсотки окремо для portrait/landscape — реальні значення це
**треті числа** в кожному `values: [min, max, default]`). Користувач
попросив "уніфікувати" з іншими юайками — явно спитав через
`AskUserQuestion`, чи переписувати логіку самому, чи тільки CSS —
**вибрав тільки CSS-рестайл** (безпечний варіант). Додано лише
адитивні властивості (`filter: drop-shadow`, `-webkit-text-stroke` на
`.bannerButtonText`) — нічого, що конфліктувало б з інжектованим SDK-стилем.

**⚠️ Знахідка: purgecss мовчки вирізає `.bannerButton`, але не `.bannerLogo`/`.bannerButtonText`**
При білді (не тільки в dev) `purgecss` скановує лише `src/**/*.{js,ts,tsx}`
+ `**/*.html` на предмет "чи цей клас реально використовується" — а
`InstallBanner`'s класи призначаються в JS всередині ВЖЕ мінифікованого
SDK dist-бандла (не в нашому `src/`). Емпірично перевірено в реальному
білд-виводі (`export/index.html`): `.bannerLogo{filter:...}` і
`.bannerButtonText{...}` виживають, а `.bannerButton{filter:...}` — ні,
навіть як окреме правило. Ймовірна причина: мінифікатор пакета
де-дублював рядок `"bannerButton"` (4 похідні: сам +
`Holder`/`Img`/`Text`) на спільний префікс, тож він більше не існує
цілим рядком у бандлі — `"bannerLogo"` (лише 2 похідні) не досяг порогу
для такої оптимізації. Поза нашим контролем (сторонній пакет) — просто
не писати CSS-правила під `.bannerButton` окремо, вони будуть мертвим кодом.

## `gameFont` нарешті став реальним шрифтом
`font-family: gameFont, sans-serif` використовувався в `main.css`/`ui.css`
з самого початку проєкту, але `gameFont` НІКОЛИ не був заведений через
`@font-face` — тихо відкатувався на дефолтний sans-serif усюди. Користувач:
"весь юай має використовувати шрифт PassionOne-Black, він у нас є в
temp". Додано `@font-face` в `main.css` (`src/resources/fonts/PassionOne-Black.otf`)
під іменем `gameFont` — усі існуючі посилання почали резолвитись сами,
без жодної іншої зміни. Технічний нюанс: для шрифтів (на відміну від
`images.ts`/`ConvertToBase64WhenRelease`-паттерна) НЕ треба нічого
особливого — `assetsInlineLimit: 100000000` в `vite.config.js`
(через `defineConfigTemplate`) вже інлайнить будь-який `url()` в CSS як
base64 і в dev, і в білді. Перевірено прямо в білд-виводі (не на око).

## `--lvh`/`--lvw` замість сирого `vh`/`vw`/`vmin` — ротація/адаптивність
Користувач (Day 8 чекліст, "All UI elements must be adaptive to changing
device rotation"): розвернув екран — нічого не змінилось. **Знахідка**:
SDK має `OrientationC` (`node_modules/@hitplay/playable_template`), який
під лок-режимом орієнтації обгортає сторінку в
`transform: rotate(-90deg)...`, щоб контент лишався візуально портретним
навіть на фізично горизонтальному екрані. Сирі `vh`/`vw`/`vmin`
**ігнорують transform батьків** і завжди рахуються від фізичного
(неповернутого) вьюпорта — тож будь-який розмір у `vh` стає неправильним
щойно лок реально спрацює. `OrientationC` для цього тримає `--lvw`/`--lvh`
("логічні" версії, коректно стежать за поворотом; в Adaptive-режимі без
локу — просто дорівнюють фізичним vw/vh, тобто нічого не коштують) —
той самий підхід, що вже й в `InstallBanner.ts` (`--lvw` в коментарях
"physical vw doesn't follow the orientation lock"). Усі `--*-width` в
`ui.css` тепер `calc(var(--lvh, 100vh) * ratio)`.

**⚠️ Важливо**: дефолт в `src/configUIParams/orientation.ts` — **"Adaptive"**,
НЕ лок. У цьому режимі `--lvh == vh` і фікс вище нічого не змінює
візуально прямо зараз — це радше "правильно про запас", коли/якщо
проєкт зрештою поставлять на Portrait Lock (майже неминуче для
вертикального плейбла). Коли користувач після цього фіксу все одно
сказав "нічого не змінилось, юайка так само зосереджена в центрі" —
попросив **медіа-правила** замість покладання на `--lvh`/лок-механізм.
**Фінал**: кожна з трьох юайок (`resource-hud`/`weapon-hud`/`zombie-invasion`)
тепер має власний `@media (orientation: landscape) { ... }` блок одразу
після portrait-правила, що перевизначає `top`/`left`/`right`/`bottom` і
`--*-width` — незалежно від `OrientationC`/локу, реагує на реальне
співвідношення сторін вьюпорта. Значення в landscape-блоках зараз лише
дублюють portrait як стартову точку — **ще НЕ підтверджені користувачем
візуально**, він вже почав підкручувати `.resource-hud`'s landscape
`--hud-width` (з `0.09` на `0.19` — бачив у diff, не сам робив).

## Стан на кінець цієї сесії
- Working tree: `src/configUIParams/installBanner.ts` (можливо просто
  line-ending, не досліджував — не моя зміна), `TestSceneC.ts`,
  `main.css`, `ui.css`, `images.ts` — модифіковані; `WeaponHudC.ts`,
  `ZombieInvasionHudC.ts`, `resources/fonts/`, три нові `.webp` — нові.
  **Не закомічено.**
- `stats.html` — як завжди, build-артефакт, свідомо не в git.
- Наступний крок, якщо буде запит: підтвердити/підкрутити landscape
  `@media`-значення разом з користувачем, коли він реально побачить це
  на розгорнутому екрані.