5 classes ajoutées dans rig/patch/ :
- TiedUpCapabilities.java
Holder du Capability<EntityPatch> CAPABILITY_ENTITY (CapabilityToken
auto-register) + helpers getEntityPatch / getPlayerPatch /
getPlayerPatchAsOptional. Simplifié de EF (pas de ITEM/PROJECTILE/SKILL
caps, combat only).
- EntityPatchProvider.java
ICapabilityProvider + Map<EntityType, Function<Entity, Supplier<EntityPatch<?>>>>.
registerEntityPatches() pour commonSetup (EntityType.PLAYER seul Phase 2),
registerEntityPatchesClient() pour clientSetup (dispatch LocalPlayerPatch vs
ClientPlayerPatch<RemotePlayer> vs ServerPlayerPatch). CUSTOM_CAPABILITIES
pour extensions futures. Pas de GlobalMobPatch combat fallback.
IMPORTANT : n'enregistre PAS EntityType.VILLAGER (MCA conflict V3-REW-10).
- TiedUpCapabilityEvents.java
@Mod.EventBusSubscriber sur AttachCapabilitiesEvent<Entity>. Check oldPatch
pour éviter double-attach, construit provider, appelle onConstructed eager
(D-01 pattern EF), addCapability. Priority NORMAL (order d'attachement
ne matière pas, c'est les runtime cross-cap reads qui importent et ceux-là
sont déjà lazy dans onConstructed).
3 stubs PlayerPatch subclasses (placeholders Phase 2.4) :
- ServerPlayerPatch : overrideRender=false, getArmature=null stub, updateMotion no-op
- ClientPlayerPatch<T extends AbstractClientPlayer> : overrideRender=true, @OnlyIn CLIENT
- LocalPlayerPatch extends ClientPlayerPatch<LocalPlayer> : vide pour l'instant
Ces stubs satisfont le compile de EntityPatchProvider.registerEntityPatchesClient().
Le getArmature() null est non-bloquant Phase 2.3 mais devra être fixé Phase 2.4
pour le vrai rendering (lien avec TiedUpRigRegistry.BIPED à créer Phase 2.7).
Compile BUILD SUCCESSFUL + 11 tests bridge GREEN maintenus.
faad0ced0f