Parachute System, Profiles, Inputs, and Rig Behavior

Plane Deploy includes the IMC parachute subsystem inside the same plugin. This means the parachute runtime is not an afterthought or a separate add-on. It is part of the live deployment stack.

Where the parachute config lives

Everything parachute-related sits under:

imcparachute:

That block currently covers:

• activation rules
• session rules
• seat behavior
• flight tuning
• impact damage
• sounds and messages
• parachute profiles
• display-rig offsets

Activation behavior

The current config supports:

• click deploy while holding the pack item
• F key deploy while holding the pack item
• airborne-only deploy
• auto-deploy if configured

The important practical rule is this:

• opening can happen from click or F
• closing should happen through sneak or losing the offhand control item
• click-to-close should stay disabled

That keeps the runtime aligned with the safer behavior expected by the current plugin.

Session behavior

The current session block is designed around a real open, cut, and reopen loop:

session:
  consumePackOnDeploy: true
  closeOnSneak: true
  allowControlRightClickReopen: true
  allowControlRightClickClose: false
  closeIfControlNotInOffhand: true

That means:

• opening consumes the pack for the session
• sneaking closes the canopy
• right click can reopen after a close
• right click does not close the canopy anymore

Seat and rig stability

The parachute visuals are built around:

• a seat entity for stable rider pose
• a display-entity rig for backpack, canopy, and strings
• anti-jitter teleport settings
• a seat-anchor option that mounts the display to the seat

Those details exist because this system has historically been sensitive to vibration, orbiting, and display desync.

Flight tuning

The flight block separates:

• open-canopy descent
• opening catch behavior
• closed-canopy descent
• impact damage

That separation matters because "close the canopy" and "remove all motion logic" are not the same thing.

Impact damage

Impact damage is intentionally physics-aware instead of being a simple yes or no landing check.

The current config exposes:

• a safe impact speed
• damage per block-per-second over that threshold
• a max damage cap
• a decaying peak-speed model so last-second reopen attempts do not erase all consequences

If landing damage feels unfair or too forgiving, adjust the impact-damage numbers before you start rewriting the whole chute flow.

Parachute profiles and style content

The current config ships style profiles such as:

• default
• standard
• rainbow
• tiger
• fargo
• duck_defense
• crater_stone
• stone
• raider
• soldier
• imc
• marauder

These are content definitions, not only gameplay toggles.

The pack item versus the visible canopy

One important design detail in the current setup is that the offhand pack item stays the same backpack control item across variants, while the visible canopy models change by profile.

That means a style profile can change the parachute appearance without forcing every variant to become a different offhand control item.

Current admin commands

The parachute admin surface includes:

/parachute give <player> [amount] [style]
/parachute style <player> <style>
/parachute styles
/parachute who <player>
/parachute test [style]
/parachute tune [style]
/parachute reload

Use /parachute styles whenever you are unsure what profile IDs are live on the server.

When to edit profiles versus rig offsets

Edit profiles when:

• you are adding new canopy variants
• the title or description is wrong
• the custom-model-data values changed in the pack

Edit rig when:

• the backpack sits in the wrong place
• the canopy anchor is wrong
• strings look detached
• seated visuals look stable in one pose and wrong in another

Those are two different classes of edit. Keeping them separate is how you avoid introducing visual regressions while only trying to add content.