Troubleshooting and Integration Notes

Plane Deploy is at its best when each layer is debugged in order instead of all at once.

If a player does not deploy correctly

Check these first:

• are they in the right world
• are they inside a real door zone
• does that door zone point to an existing spawn group
• does that spawn group contain valid spawns
• is the player state what you expect

If needed, use:

/pd deploy <doorId|spawnGroup>
/pd state

That lets you separate broken geometry from broken player state.

If the plane visual looks wrong

The cinematic plane display is usually affected by:

• visuals.planeDeploy.durationTicks
• speed settings
• per-door flight direction
• display view range and culling size
• chunk-loading behavior
• cleanup timing

If the visual feels frozen or inconsistent, enable plane debug and test one door at a time.

If wind feels too aggressive or too weak

Check the full wind block together:

• base speed
• active duration
• direction
• oscillation
• whether open parachutes should ignore wind

Do not only nudge one number repeatedly if the player-state timing is also wrong.

If parachutes do not behave correctly

The most common checks are:

• does the player actually have the pack item
• is airborne deploy required
• is auto-deploy masking a manual-input misunderstanding
• is click-to-close still disabled
• is the profile ID valid
• do the custom-model-data values match the current resource pack

Use:

/parachute styles
/parachute who <player>
/parachute test [style]

before assuming the problem is deep rig math.

If squads do not deploy together

Check:

• squads.enabled
• requireInPlaneWorld
• requireState
• deploy mode
• onlyLeaderCanTrigger
• whether deaths have already removed members from the squad

Most squad complaints are eligibility problems, not broken invite commands.

Debug toggles that matter

The current debug block includes:

• debug.logDeployEvents
• debug.logSquadEvents
• debug.logStateChanges
• debug.logFallDamageSuppressed
• debug.plane

Turn on only the lane you need. This plugin has enough moving parts that noisy logs become their own problem.

Optional integrations

The combined plugin currently has:

• no hard dependency plugins
• optional ModelEngine soft dependency

That means the core deployment flow should work without ModelEngine. Treat ModelEngine as an optional visual or future integration lane, not a boot requirement.

The practical troubleshooting order

When something feels broken, use this order:

1. confirm data.yml
2. confirm player state
3. confirm drop behavior
4. confirm wind and HUD
5. confirm parachute behavior
6. confirm plane visual polish
7. confirm squad layering

That order matches the real dependency chain in the plugin and keeps you from chasing cosmetic symptoms before the route itself is correct.