Config YML, Runtime, and the File Split

Plane Deploy uses one large config.yml because the core deploy flow and IMC parachute runtime now live in the same plugin.

That does not mean everything belongs in one mental bucket. The file has a clear split, and using that split is how you keep edits safe.

The top-level sections that matter

The current config is organized around these sections:

plane:
deploy:
visuals:
hud:
squads:
squadAnnouncements:
windDrift:
debug:
imcparachute:

What each section is responsible for

plane

This is the staging location and join behavior layer.

Use it for:

• the plane world and spawn point
• whether players enter the plane on first join
• whether respawns return players to the plane
• the radius that counts as "in plane"

deploy

This is the actual drop setup layer.

Use it for:

• drop height offset
• whether yaw is randomized
• post-drop fall-damage suppression ticks
• starter kit commands
• whether Plane Deploy gives the parachute item directly

visuals

This is where chat-title polish and the cinematic plane flyby live.

Use it for:

• deploy titles
• deploy sounds and particles
• plane display model settings
• plane trail particles
• plane wobble and cleanup settings

The important design line here is simple: the plane flyby is visual polish. It is not the actual thing selecting a spawn or moving the player.

hud

This controls the altitude display while the player is in the right state.

Use it for:

• bossbar versus actionbar mode
• update interval
• which player states show the HUD
• bossbar title and thresholds

squads and squadAnnouncements

These control group-drop behavior and team logic.

Use them for:

• squad size and invite expiration
• whether members must be in the plane world
• whether only the leader can trigger a group drop
• spread radius for squad drops
• friendly-fire blocking
• public drop announcements

windDrift

This is the early-air push after a deploy.

Use it for:

• how long wind stays active
• the base direction and speed
• sideways oscillation
• whether wind should ignore open parachutes

debug

This is the live logging surface.

Use it when the plugin feels wrong and you need to know why:

• deploy event logging
• squad event logging
• state-change logging
• plane-specific debug logging

imcparachute

This is the combined parachute subsystem.

Use it for:

• activation rules
• auto deploy
• close and reopen behavior
• seat and rig behavior
• flight tuning
• impact-damage tuning
• messages and sounds
• parachute profiles and display models

The file split that keeps the plugin readable

Treat the plugin like this:

• config.yml decides how the systems behave
• data.yml decides where players can deploy

If you blur those together, every future edit gets riskier than it needs to be.

Safe live edits versus restart-worthy edits

Usually safe to reload live:

• titles, sounds, messages, and HUD formatting
• squad messages and toggles
• wind drift numbers
• parachute profile labels and model-data values

Usually better to test carefully after editing:

• plane flyby movement and cleanup values
• parachute seat or rig offsets
• impact-damage tuning
• join behavior or plane spawn location
• anything in data.yml that changes active door zones

Continuity-first rule for config changes

This plugin has a long history, so the safest rule is:

• add keys
• keep old defaults unless you are intentionally changing behavior
• do not wipe user sections just because the default file moved forward

That is especially important in imcparachute.profiles, where style definitions are content as much as they are config.

The two pages to keep beside you

When you are editing the live server, keep these pages open together:

• data YML, Door Zones, Spawn Groups, and Weighted Drops
• commands, Permissions, and Live Admin Tasks

That combination covers both the saved data and the in-game tools used to test it.