Skip to main content
Plane Deploy wiki

Wiki

Plane Deploy Wiki

Plane insertion, spawn routing, parachute profiles, squads, wind drift, and admin workflows for cinematic round starts.

Getting Started

Start here for first boot, the file split, and the deployment data that actually drives drops.

Deployment Stack

Follow the live player flow from plane state through drop, wind drift, parachute control, and landing.

Squad and Admin Tools

Use squads, the hotbar editor, and the admin command surface to run real drops instead of hand-editing blind.

Operations and Troubleshooting

Troubleshoot live deployments, optional integrations, and the most common reasons a drop feels wrong.

Deployment Stack

Deploy Flow, Player State, HUD, and Plane Visual

See how Plane Deploy moves a player from IN_PLANE through DEPLOYED and where the cinematic plane flyby fits in.

Plane Deploy works best when you separate the real drop mechanics from the cinematic polish layered on top.

The state flow

The current player state enum is:

TEXT
IN_PLANE
DEPLOYING
DEPLOYED
GROUND

That is the backbone of the plugin.

What each state means

IN_PLANE

The player is staged in the aircraft area and has not started the drop yet.

This state matters for:

  • join and respawn behavior
  • squad eligibility
  • door-trigger detection

DEPLOYING

The player has just been routed into a drop.

This is where the plugin typically:

  • teleports to the chosen drop point
  • applies starter effects
  • gives the parachute item if enabled
  • starts any deploy titles, sounds, and plane visuals

DEPLOYED

The player is actively descending. This is where HUD altitude, wind drift, and parachute logic do the most work.

GROUND

The player has landed and the active drop flow should be over.

What is mechanical versus visual

The actual deploy mechanic comes from:

  • the current player state
  • the chosen door zone
  • the chosen spawn point
  • the drop and parachute logic

The cinematic plane model comes from:

YAML
visuals:
  planeDeploy:

That plane model is a display-entity flyby. It is not the aircraft that physically carries the player.

The plane visual controls that matter most

The current plane visual block lets you tune:

  • duration
  • speed
  • start distance and start offset
  • per-door flight direction
  • display view range and culling box
  • wobble smoothing
  • trail particles
  • stuck detection
  • cleanup timing

That means you can make the plane feel dramatically different without touching the actual drop route.

Per-door direction support

The current config already supports per-door flight directions:

  • left_door
  • right_door
  • back_door

Use this when one aircraft has multiple exits and you want the flyby to feel believable from each one.

HUD placement in the flow

The current default HUD is a bossbar and is configured to show during:

YAML
hud:
  showDuringStates:
  - DEPLOYED

That makes the altitude readout a descent tool, not a pre-drop lobby element.

A clean mental model for testing

When you test a drop, check it in this order:

  1. does the player move to the correct spawn
  2. does the state reach DEPLOYED
  3. does the HUD show correctly
  4. does wind drift behave correctly
  5. does the parachute behave correctly
  6. does the plane visual look correct

That order matters because a beautiful plane flyby cannot fix a broken drop route.

When to tune this page's systems first

Open this part of the wiki first when:

  • players reach the wrong place
  • the altitude HUD appears too early or too late
  • the plane visual feels frozen or disappears too fast
  • the plane looks like it flies in the wrong direction relative to the door

Then use wind Drift, HUD, and Ground Detection and parachute System, Profiles, Inputs, and Rig Behavior for the layers that sit on top of the base flow.