CBC Enchanced Shells [Create Big Cannons]

# Changelog

## [1.1.4] - 2026-05-31

**Hotfix Shell Holder + corrections rocket**

Cette release corrige un crash bloquant du Shell Holder introduit dans 1.1.3 ainsi que deux bugs sur les rocket lancées au canon (notamment depuis un ship Sable) et les Cluster Shell montées sur rocket.

### Corrigé

#### Shell Holder — crash à la pose / wrench / contraption

- **Cause** : régression introduite en 1.1.3. La méthode `applyImplicitComponents` appelait `applyComponents(...)`, qui à son tour appelle `applyImplicitComponents` → **récursion infinie → `StackOverflowError`**.

- **Déclencheur** : pose d'un Shell Holder depuis l'inventaire, wrench du bloc en monde, assemblage Create contraption — tout chemin où Minecraft transfère les composants de l'item vers le block entity.

- **Fix** : refactor complet du stockage des shells, suivant le pattern CBC v5.11.4 pour `FuzedBlockEntity.fuze` et `BigCannonProjectileBlockEntity.tracer` :

  - `LOADED_SHELLS` est désormais stocké dans un champ direct `protected ItemContainerContents loadedShells`, plus dans la map de composants

  - `applyImplicitComponents` écrit uniquement dans ce champ, **jamais via `applyComponents`** (évite la récursion)

  - Persistance NBT explicite via `saveAdditional` / `loadAdditional` / `writeSafe` (chunk save, contraption freeze)

  - `collectImplicitComponents` lit depuis le champ pour transférer à l'item à la cassure

#### Rocket lancée au canon — montait verticalement au lieu de suivre l'angle

- **Symptôme** : tir d'une rocket depuis un canon à 45° → la rocket part vers le haut au lieu de suivre une trajectoire balistique. Particulièrement visible depuis un canon monté sur entité Sable.

- **Cause** : `RocketLoadingHelper.tryBuildRocket` passait un vecteur placeholder `(0, 1, 0)` à `configureForCannon`, et `RocketEntity.launchVector` restait à cette valeur. CBC écrit la vélocité de tir sur l'entité **après** ce call, donc notre `launchVector` ignorait l'angle du canon. Le thrust de la rocket s'appliquait verticalement (`0.10 × (0, 1, 0)` chaque tick) et dépassait la gravité (`-0.04`) → ascension parasite.

- **Fix** : `launchVector` est désormais capturé au premier tick valide depuis `getDeltaMovement()`, qui contient la vraie vélocité écrite par CBC (incluant la vélocité héritée du ship Sable v5.11.4). Flag `pendingCannonThrustCapture` persisté en NBT pour survivre au chunk reload pendant le vol.

#### Cluster Shell sur rocket avec fuze — explosion prématurée + sub-shells avec fuze épuisée

- **Symptôme** : monter une Cluster Shell sur rocket avec une fuze (timer, inertia, etc.) → la rocket explosait au timer de la fuze (avant l'apogée), et les sub-shells spawnées héritaient d'une fuze à `FUZE_TIMER=1` (détonation immédiate inutile).

- **Comportement attendu** : peu importe la fuze, le split doit avoir lieu à l'apogée de la rocket, et chaque sub-shell doit recevoir la fuze **avec ses réglages d'origine** (timer original, etc.).

- **Fix** sur 3 fichiers :

  - `ClusterShellProjectile.splitImmediately()` : nouveau point d'entrée public qui bypass le garde `fuzeEquipped`

  - `RocketEntity.tick` : skip de `fuzeItem.onProjectileTick` quand le payload est un Cluster (la fuze ne décompte plus pendant l'ascension)

  - `RocketEntity.releaseProjectile` : ne clampe plus `FUZE_TIMER=1` pour les clusters, puis appelle `splitImmediately()` après spawn → les sub-shells héritent de la fuze intacte via la reflection existante de `ClusterShellProjectile`

  - `RocketBaseBlock.tryLaunch` : `autoApogee = true` toujours pour les clusters, peu importe si une fuze est présente