onboarding-project/docs/worklog/11-payzone-deposit-flight-unified.md

PayZoneC: уніфікація депозит-флайту з ResourceC (2026-08-12)

playDepositFlight (політ токена з HUD в Pay Zone) використовував окремий TweenJS-based шлях, не звʼязаний з новою логікою ResourceC: мав ротейт (mesh.rotation.y += 0.3) і стартовий scale=1 (дефолт свіжого ResourceC.createVisual(), без жодного стиску).

• Ротейт прибрано повністю (користувач: "ротейту не має бути").
• Компенсація перспективи — та ж сама техніка, що й у ResourceC.toTarget, але в ПРОТИЛЕЖНИЙ бік: цей політ стартує БЛИЗЬКО до камери (HUD-анкер) і летить ДАЛІ (Pay Zone, зазвичай далі від камери) — без компенсації токен би візуально ЗМЕНШУВАВСЯ на льоту.
• ⚠️ Знайдений і виправлений баг: токен був значно більшим за ресурс з наземної анімації Причина: ResourceC.createVisual() не проходить через SHRINK_AMOUNT- стиск (той стосується лише "живих" FlyingResource з баунсом) — токен стартував з scale=1, тоді як ресурс, який щойно долетів на те саме місце з ResourceC, виглядав як 0.85. Фікс: RESOURCE_ICON_BASE_SCALE = 1 - SHRINK_AMOUNT (0.85) винесений з ResourceC.ts як export, PayZoneC множить на нього. Плюс окремий DEPOSIT_FLIGHT_SCALE_MULTIPLIER (зараз 1, користувач підкрутив до 0.3 в UI-сесії) — локальний тюнер розміру САМЕ цього польоту, не торкаючись спільної константи (яка вплинула б і на "земля->юай" анімацію).
• Урок: коли два різні контролери візуально показують "той самий" ресурс в різних сценах польоту — тримати спільну константу базового розміру (export), а не дублювати магічне число, інакше вони розходяться, як тут.