This page documents every command registered by Flan's Mod Ultimate 2.0. Commands marked Operator require Minecraft permission level 2 (normally an operator or a command block). Commands marked Player must be run by a player and cannot be run from the server console unless a player argument is explicitly shown.

Syntax notation:

• <value> is required.
• [value] is optional.
• <player> accepts one player; <players> also accepts selectors that resolve to multiple players, such as @a.
• Coordinates support Minecraft's normal absolute and relative (~) notation.
• IDs for teams, classes, maps, game types, loadout pools, and reward boxes come from the currently loaded content and configuration. Use the corresponding /teams list command to discover them. They are unique across content packs, which may differ from the ShortName a pack wrote; see Shortnames shared by two content packs.

Available to everyone, including the server console. Lists every main-mod command root and alias, with descriptions and operator requirements. Click a yellow help command to fill the chat input. Teams commands refer to /teams help; other server commands refer to Minecraft's /help <root> for syntax. Also lists the client-only /flansrenderstats command and its subcommands.

Permission: Operator; executor: Player

Gives the executing player the default ammunition for every supported item held in the main or off hand: guns, AA guns, and driveables. If neither hand holds an item with default ammunition, the command falls back to the driveable, AA gun, or deployed gun the player is riding. If the inventory is full, ammunition is dropped at the player's position.

• amount is an integer from 1 to 64 and defaults to 1.
• Guns, AA guns, and deployed guns use their first configured ammunition type.
• A driveable gives each distinct default round required by its mounted guns and bomb, mine, missile, or shell banks. A mecha also includes the defaults for guns currently installed in its hand-tool slots.
• When both hands contain supported items, duplicate ammunition types are given only once.
• Ammo items are created fully loaded with their configured rounds-per-item value.

Examples:

/defaultammo
/defaultammo 16

Permission: Operator; executor: Player

Loads the ridden driveable, AA gun, or deployed gun, or the driveable item held in either hand, with the main hand checked first. /flanrearm is an exact alias. Riding any driveable seat works, not only the driver's. Nothing is taken from the player's inventory; this is the mounted-weapon equivalent of /defaultammo.

Three groups of slots are filled, each from the driveable's own definition:

A mecha has none of those banks. Instead, each gun held in its tool slots gets a stack of its default ammunition in a free cargo slot, which is where a mecha reloads its hand guns from.

For a ridden AA gun, every barrel's ammunition slot is filled with the AA gun's default round. A deployed gun has its single loaded-ammunition slot filled with its gun definition's default round. The same keep, top-up, explicit replacement, and displaced-ammunition rules described below apply to both.

How the default round is chosen. A weapon bank takes the first entry of the driveable's own Ammo and AddAmmo list that belongs to that bank, the same way the first entry of a gun's list is that gun's default round. Definitions that declare bomb or shell slots and no ammunition at all, relying on AcceptAllAmmo, fall back to the least destructive registered round of the right kind, preferring one from the driveable's own content pack. That keeps the pick stable across loads and stops an aircraft being rearmed with the largest bomb some unrelated pack happens to register. Name the round explicitly when you want a different one.

What is left alone. Ammunition already loaded is kept, and a partly spent item is topped back up to its full rounds-per-item. Running the command again therefore rearms without discarding a loadout assembled by hand.

ammo names one ammunition short name and overrides every default above. It is loaded into every slot that accepts it and does replace ammunition already loaded; whatever it displaces is put back into the player's inventory, or dropped at their position if the inventory is full. Slots that do not accept the named round are reported and left untouched. Tab completion offers only the rounds the current target can actually take.

Each bank is reported on its own line, with the count loaded, topped up, replaced or left as loaded, and the round used. A bank that could not be filled is reported in red with the reason, and the rest of the driveable is still loaded.

=== A-10 Thunderbolt rearmed ===
  GAU-8 Avenger (1 slot): 1 loaded (30mm HE)
  bombs (7 slots): 5 loaded, 2 topped up (FAB-100 Bomb)
Rearmed A-10 Thunderbolt: 7 slots

Reloading a driveable's weapon inventory takes the crew the definition's ReloadTimePrimary and ReloadTimeSecondary, exactly as loading it by hand does, so the weapons stay unavailable for that long after the command runs.

Examples:

/rearm
/rearm BombUSSRFAB500

Permission: Player

Lists the attachments explicitly accepted by the Flan's Mod gun held in either hand; the main hand is checked first. Each entry includes the localized item name and its modern registry ID. Guns configured to accept every compatible attachment report that policy directly instead of printing the complete attachment catalog.

/flansmodultimate attachments is the namespaced form. The legacy /flans allowedAttachments spelling is also accepted for compatibility.

Example:

/flans attachments

All /digitalammo commands require Operator permission and only work while the digital ammo system is enabled in the common config. Ammo type numbers start at 1; the maximum is the configured digitalAmmoNumTypes value (seven by default).

Examples:

/digitalammo set Steve 1 250
/digitalammo add @a 2 50
/digitalammo fill @a all
/digitalammo get Steve

Permission: Operator

Spawns a named Flan's Mod particle for clients in the command source's current dimension. Only viewers within 512 blocks of the particle position receive it.

The accepted forms are:

/fmparticle <name>
/fmparticle <name> <x> <y> <z>
/fmparticle <name> <x> <y> <z> <dx> <dy> <dz> <speed> <count>
/fmparticle <name> <x> <y> <z> <dx> <dy> <dz> <speed> <count> <viewers>
/fmparticle <name> <x> <y> <z> <dx> <dy> <dz> <speed> <count> <scale>
/fmparticle <name> <x> <y> <z> <dx> <dy> <dz> <speed> <count> <scale> <viewers>

• name is the particle name understood by the Flan's Mod client renderer.
• pos defaults to the command source's position.
• delta defaults to 0 0 0 and controls positional spread when count is above zero. When count is zero it instead supplies the particle's motion direction.
• speed and scale must be 0 or greater. They default to 0 and 1.
• count must be 0 or greater. A value of 0 creates one particle; a positive value creates that many particles with randomized spread and velocity.
• viewers accepts players or a player selector. If omitted, all online players are considered, subject to the dimension and distance checks.

Examples:

/fmparticle fm_smoke
/fmparticle explode ~ ~1 ~ 0.5 0.5 0.5 0.1 20
/fmparticle flare 100 70 100 0 1 0 0.2 1 2 @a

For a player-focused explanation of the modes, flag objectives, classes, loadouts, and arena setup, see Teams.

/teams is the primary command. /team and /flansteams are exact aliases, so any syntax below can use any of the three roots.

Running /teams or /teams help prints a short in-game command summary.

These commands do not require operator permission.

The legacy aliases /teams listGametypes, /teams listMaps, /teams listRounds, and /teams listAllTeams remain available. Prefer the grouped /teams list ... forms in new documentation and scripts.

Every ID these commands print is unique across content packs and is the ID the other teams commands expect; see Shortnames shared by two content packs for what happens when two packs pick the same name. To try a class or a team's uniform without running a round at all, see Try a Player Class and Try a Team.

All commands in this section require Operator permission.

getOpKit is player-only. It gives one operator stick, 16 each of flagpoles, player spawners, item spawners, and vehicle spawners, and five capture points; overflow is dropped at the player's position.

The individual rules are the same ones the arena and survival presets set all at once; each command changes one of them and keeps the others. They are saved with the world.

Lag compensation. A bullet checks players where they were a few ticks earlier, to make up for the shooter's ping: it uses the player position from min + ping / divisor ticks ago, with the ping in milliseconds. A divisor of 0 ignores the ping. min is 0..100 and divisor 0..1000; the defaults are 0 and 50. The values are stored as bulletSnapshotMin and bulletSnapshotDivisor in the common config, so they also survive restarts.

Every /teams admin ... command requires Operator permission. These grouped forms are preferred for server administration.

The kit form is player-only.

When a round ends the server runs up to three stages in order before the next round starts: the scoreboard, then the rank update screen where a loadout pool is active, then voting where it is enabled. Setting a stage's duration to 0 skips it.

The greeting appears as the header of the ranked loadout screen.

Examples:

/teams admin map add desert_arena Desert Arena
/teams admin round add desert_arena TDM red vs blue 15 50
/teams admin round add desert_arena con us+uk vs germany+italy 20 300
/teams admin start 0
/teams admin setvariable friendlyFire false

/tryclass equips a teams player class outside of a round, so a class can be tried without first configuring a map, a game type and two teams. /flantryclass is an exact alias. All forms require Operator permission. /tryclass <class> and /tryclass clear act on the executing player and cannot be run from the console; /tryclass list can.

Neither form touches the armour slots. To put on or take off armour, use /tryteam.

/tryclass <class> takes a class ID as shown by /tryclass list or /teams list classes, and performs the same steps the teams system performs when a player spawns into a round:

• The carried inventory and the off hand are emptied first. The armour slots are not.
• The class Hat, Chest, Legs, and Shoes entries are worn. A slot the class does not define keeps whatever is already worn, which is how a real spawn lets team armour fill the gaps the class does not cover.
• Every AddItem entry is given, with the requested amount and damage value. Guns are built with the attachments written after + in the entry and are loaded with their default ammunition. Paintable items also receive the optional Paintjob=id selected after amount and damage, for example AddItem romanScutumImperial 1 0 Paintjob=2.
• Items that do not fit are dropped at the player's position.
• The class is recorded on the player, so a class with a SkinOverride is drawn on that skin for every client that has player class skin overrides enabled.

Because the armour slots survive, one team's uniform can be put on once with /tryteam <team> and then kept while trying one class after another:

/tryteam us
/tryclass us_assault
/tryclass us_sniper

One part of a real round spawn is deliberately not applied, because there is no round to take it from: the ranked loadout pool. /tryclass always gives the class's own starting items, even when a loadout pool is active, so what you get is exactly what the class definition declares.

No team is joined and the round state is not touched. The class is remembered across respawns until it is changed or cleared.

UnlockLevel is ignored: any class can be equipped regardless of the executing player's rank, which is the point of the command.

/tryclass clear

This empties the carried items and forgets the class, which removes the skin override. The armour slots are left as they are, so the team uniform underneath survives; take it off with /tryteam clear.

/tryclass list prints one line per class:

shortname - Display Name (rank 3) [Content Pack]

The rank suffix is shown only for classes with a non-zero UnlockLevel. The name at the start of the line is always the name to type. When a class had to be given an alias because another pack claimed its shortname first, the pack's own spelling follows it in parentheses (see Shortnames shared by two content packs):

assault_2 (= assault) - Assault [Modern Warfare]

The optional filter is resolved as a team ID first, then as a content pack name. Content pack names are matched loosely: case, spaces, underscores, and hyphens are ignored, so modernwarfare, Modern Warfare, and modern-warfare all match the same pack. Tab completion offers team IDs followed by the names of every content pack that defines at least one class.

Examples:

/tryclass list
/tryclass list us
/tryclass list Modern Warfare
/tryclass mw_assault
/tryclass clear

clear and list are matched as subcommands before the class argument. A class whose ID is literally clear or list therefore cannot be selected by name; use the team or content pack listing to inspect it, and /teams class <class> inside a round to select it.

/tryteam wears the armour a team issues, outside of a round. It is the companion of /tryclass: a team contributes the armour a player spawns in, so this puts on exactly the pieces the team defines. /flantryteam is an exact alias. All forms require Operator permission. /tryteam <team> and /tryteam clear act on the executing player and cannot be run from the console; /tryteam list can.

No team is actually joined: no round state, score, or team membership changes, and the carried inventory is left alone. Only the four armour slots are written.

All four armour slots are written, including the ones the team leaves empty, so switching from one team to another never leaves a piece of the previous uniform behind. A team that issues no armour at all therefore empties the armour slots and says so.

/tryteam and /tryclass are designed to be used together and neither undoes the other:

• /tryteam writes only the armour slots; /tryclass writes only the carried items plus the armour slots its class actually defines.
• Applying a class after a team lets the class override the pieces it defines and keeps the team pieces in the remaining slots, which is the order a real spawn applies them in.
• Applying a team after a class replaces the whole uniform with the team's, since every slot is written.

/tryteam us
/tryclass us_assault
/tryclass clear
/tryteam clear

/tryteam list prints one line per team:

shortname - Team Name (3 class(es), 4 armour piece(s)) [Content Pack]

The team name is drawn in the team's own TextColour. As in /tryclass list, the name at the start of the line is the name to type, and a team that had to be given an alias shows the pack's own spelling in parentheses (see Shortnames shared by two content packs).

/teams list teams prints the same teams in a shorter form and needs no operator permission; use it when only the IDs and names are wanted.

The optional filter is a content pack name, matched loosely: case, spaces, underscores, and hyphens are ignored. Tab completion offers the name of every content pack that defines at least one team.

Examples:

/tryteam list
/tryteam list Modern Warfare
/tryteam us
/tryteam clear

As with /tryclass, clear and list are matched as subcommands before the team argument, so a team whose ID is literally clear or list cannot be selected by name.

Nothing stops two content packs from giving a player class, a team, a loadout pool, or a reward box the same ShortName. When that happens, both definitions are kept and both stay usable; the later one is simply reachable under a different ID.

The first pack to load keeps the plain shortname. Every later pack that reuses it gets an _2, _3, and so on suffix, exactly as colliding item shortnames already do:

assault      Assault  [Modern Warfare]   loaded first, keeps the plain name
assault_2    Assault  [WW2 Pack]         same ShortName, aliased on load

Each alias is reported in the log as it is created, for example:

Detected conflict for player class id 'assault': ... Creating id alias 'assault_2' in [WW2 Pack]

What this means in practice:

• Commands, saved rounds, and stats use the unique name. /tryclass <class>, /teams class <class>, /teams join <team>, /teams setloadoutpool <id>, and /teams admin round add ... all expect the name the corresponding list command prints, which is the unique one. Tab completion only ever offers unique names.
• References inside a content pack keep meaning that pack's own content. A team's AddClass assault line resolves against its own pack first, so a team always gets its own class no matter which pack happened to load first, and pack authors never need to know about the alias.
• Load order decides which definition keeps the plain name, so an alias can move between packs when packs are added or removed. Where that matters, such as in a round configuration on a server, prefer to check /teams list teams after changing the installed packs.
• Two definitions of one shortname inside a single pack are treated as a mistake in that pack rather than a collision between packs: the later file is ignored with a warning, which is how duplicate item shortnames have always been handled.

Permission: Operator; executor: Player

Prints how the real-world physics system resolved the driveable the player is riding, or the driveable item held in either hand. The main hand is checked first. Output is visible only to the executing player.

The report explains why a vehicle is on legacy or derived physics:

• Active mode, vehicle category, the effective speed scale for that category, and realisticAircraftReferenceSpeedScale
• Every authored Real* value, in its authored units
• Whether each propulsion profile is complete, and which keys are missing if not
• Resolved values, or the legacy source driving propulsion instead
• Drive type, and whether it was explicit or inferred from Tank and FourWheelDrive
• Reverse, slope, and draft overrides, or the legacy values still in force
• The movement safety clamp and wheel probe distance
• Geometry derived from the collision box and wheel positions
• Authored hull, turret, and per-part armour in nominal millimetres and slope degrees
• Whether normalized health was requested and enabled, its derived total HP, and per-part allocations

Example:

/vehiclephysics

See Realistic Vehicle Physics and Vehicle Armour and Damage for the parameters themselves.

Content-pack tooling for placing driveable muzzles: where a vehicle's shells and bullets are spawned from. Use it when rounds appear somewhere other than the end of the barrel that fires them. Every command below targets the driveable the player is riding, or the driveable item held in either hand, with the main hand checked first.

Coordinates are in the units and convention of a type file: model pixels, Y up, lateral axis as authored. A value reported here can be pasted into a definition unchanged. These are not world coordinates, so unlike most commands on this page they do not accept Minecraft's relative ~ notation; use the nudge forms for a relative move.

The keys these commands stand in for — ShootPointPrimary, ShootPointSecondary, BarrelPosition and GunOrigin — are described in Config Reference.

A moved point is not a preview. It replaces the real value on the loaded type, so it follows turret traverse and elevation, follows the vehicle as it moves and rolls, and the weapon genuinely fires from it. Firing at a candidate point and watching where the tracer leaves the model is the check worth making before writing a value down.

Overrides apply to every driveable of that type and last until reset or until the game is restarted. Nothing is written to disk — the point of the tooling is to find a value that you then edit into the type file yourself.

Press F10 (default) to toggle the mod's debug rendering, which draws a dot and a direction vector at every shoot point and passenger gun. The toggle needs operator permission, the same as the commands.

The gap between a white marker and the coloured one beside it is the correction the definition needs. Debug Rendering lists every debug marker, including shot, impact and hitbox colours.

Overrides are mirrored to every player on the server, because the markers are drawn from each client's own copy of the type. This is developer tooling on a permission level 2 command: use it on a test server or in singleplayer, not on a live one.

Permission: Operator; executor: Player

Reports every shoot point and GunOrigin of the target, each with the value its type file authors, the value measured from the loaded model where one can be measured, the difference between them, and a ready-to-paste type-file line. It also names the file and content pack to edit.

=== tiger shoot points ===
type-file units; edit Tiger.txt in Wolff's Germany WW2 Pack
-- primary (SHELL) --
  [0] turret  0.0 34.0 0.0
        measured barrel 90.0 27.5 0.0   delta 90.0 -6.5 0.0
        ShootPointPrimary 0.0 34.0 0.0 turret
-- secondary (GUN) --
  [0] turret maschinengewehr34  8.0 20.0 0.0
        measured barrel 90.0 27.5 0.0   delta 82.0 7.5 0.0
        ShootPointSecondary 8.0 20.0 0.0 turret maschinengewehr34
-- passenger guns --
  (none)

Read that as: the height is roughly right and the forward coordinate is 90 pixels — about five and a half blocks — short, because the author placed it at the turret pivot instead of the muzzle. That is the shell spawning inside the tank.

Measured values come from the model geometry the client draws: the forward face of the furthest-reaching section of barrelModel for the driveable's own weapons, and of the registered gun model for a passenger gun.

Three limits are worth knowing before you trust a measured value.

• Only one barrel is measured per vehicle, so every point in both weapon banks is compared against the main armament. The line says measured barrel for that reason. In the example above the secondary is a coaxial machine gun mounted beside the main gun, so its delta is meaningless — the measurement describes the cannon, not the coaxial. Place a coaxial by eye with nudge.
• Aircraft cannot be measured at all. Planes draw their fixed guns as part of the fuselage and wings, with nothing in the geometry marking a muzzle, so the measured line is simply absent and plane ShootPointPrimary lines are placed by eye. The registered gun of a plane's passenger seat is measured normally.
• A dedicated server has no model geometry. The command still reports authored values and still moves points; the measured lines are replaced by a note.

If a measured line is missing in singleplayer for a vehicle that should have one, look at the vehicle first: measurement reads the model the client has loaded, which for an item you have never placed may not be cached yet.

A gun whose model draws several barrels, such as a bomber's twin turret or a Flakvierling, fires from each barrel in turn. list prints them under the point or seat as offsets from it, in type-file pixels:

  seat 3 PassengerGun3  23.0 62.9 0.0
        fires from 2 measured barrels in turn: (0.0 0.0 4.0), (0.0 0.0 -4.0)

The barrels are measured while the packs load, on the server as on each client, for every content pack, including those in the mods folder. The authored point or GunOrigin is not moved for that: the barrels are spread round it. A point on one of the barrels stands for that barrel; any other point stands for the middle of the mount. Nothing is added to the type file, and the rate of fire, ammunition use and damage are unchanged: each shot just leaves from the next barrel.

This applies to every seat gun with several barrels, and to the primary bank when all of its points stand on one spot and none is an AddGun. A primary bank that repeats the same point, as some packs do by writing BarrelPosition twice, still fires once per point per shot, as in legacy Flan's; each copy starts on a different barrel, so those shots leave from different tubes. A bank whose points stand apart was placed by its author and keeps those points.

Permission: Operator; executor: Player

Moves one shoot point of that weapon bank. index is the position shown by list, counting from 0. The mount the point is attached to is left alone, so a point that belongs to an AddGun keeps its gun.

Permission: Operator; executor: Player

As above, but the coordinates are added to the point's current position. This is the form to use when walking a point onto the barrel a pixel at a time.

Permission: Operator; executor: Player

Moves the firing origin of a passenger gun. Seats are numbered from 1; the driver's weapons use the primary and secondary shoot-point banks. The seat must mount a gun.

Passenger weapons are authored with GunOrigin rather than ShootPoint, so the confirmation and paste-ready line use that name. The firing path lifts GunOrigin by the legacy mounted-gunner offset of 1.35 blocks; measured values reported by list already account for it.

GunOrigin is the muzzle with the gun in its rest pose. When the model's pivot for that gun is known, the round's origin is turned round the pivot with the gun as it aims, so a GunOrigin on the barrel tip stays on it at every aim. list prints the pivot as gun pivot, in the same units; a GunOrigin placed on the pivot fires from one fixed point. On a dedicated server the pivot comes from the gunner's own client, and until one has reported it the origin stays fixed, as in legacy Flan's.

Permission: Operator; executor: Player

As above, relative to the passenger gun's current GunOrigin.

Permission: Operator; executor: Player

Appends a new shoot point to that weapon bank, for a definition that declares none to move. part is a driveable part short name such as turret or leftWing, and defaults to core.

Permission: Operator; executor: Player

Moves every point that list can measure onto its measured value in one step, so the suggestions can be tried in game and undone with reset. Each passenger gun with a measured muzzle takes it as its GunOrigin. The measured barrel is applied only when the primary bank has exactly one point and it is not an AddGun: only one barrel is measured, so applying it anywhere else would pull a coaxial or a twin barrel onto the main gun's muzzle. The secondary bank is never changed. Skipped points are listed, and each moved point prints its paste-ready type-file line.

list, apply and reset also work on an AA gun or sentry you ride, hold as an item, or look at from within 8 blocks, as long as you are not also in or holding a driveable. list shows each Barrel line beside the model's measured muzzle, converted into a Barrel line, and apply writes those in, kept to the hundredth of a pixel. The muzzle is the centre of the barrel's front face, the same point the red and yellow markers show.

The model's muzzles already fire once a client has reported them, so the Barrel lines are only the fallback, shown by the magenta markers in Debug Rendering. The suggested line matches the model with the gun level. Once the model is known, Barrel lines elevate around the model's barrel pivot, as its barrels do, so a line that matches at rest keeps matching at every elevation. Without a model (the fallback) there is no pivot, so they elevate around the gun's base.

Permission: Operator; executor: Player

Restores every shoot point and GunOrigin of the target to the values its type file authors.

Permission: Operator; executor: Player

Compatibility alias for /flandebug shootpoint seat <seat> <x> <y> <z>.

Permission: Operator; executor: Player

Compatibility alias for /flandebug shootpoint nudge seat <seat> <dx> <dy> <dz>.

Permission: Operator; executor: Player

Shorthand for the legacy BarrelPosition key: moves primary shoot point 0, and creates it on the turret when the definition declares no primary point at all.

Fixing the tank from the list output above:

/flandebug shootpoint list
/flandebug barrelposition 90 27.5 0
/flandebug shootpoint nudge primary 0 -2 0 0
/flandebug shootpoint list

Ride the tank with F10 rendering on, put the yellow marker on the end of the barrel, fire a round to confirm the tracer leaves the muzzle, then take the ShootPointPrimary line from the final list and replace the vehicle's BarrelPosition with it. Run /flandebug shootpoint reset afterwards, or restart, so the loaded type stops differing from its file.

For the tracked content packs, the shootPointSync Gradle task does what apply does for every vehicle, plane, mecha and AA gun at once, and writes the result into the source .txt definitions:

gradlew shootPointSync [-Pwrite] [-Pfilter=<text>] [-PreportFile=<path>]

It builds each model outside the game, measures it as list does, and applies the same rules as apply: the measured barrel replaces a primary bank of one plain point (an authored offset keeps its root and takes the difference), each measured seat gun sets its GunOrigin, and each measured AA gun barrel sets its Barrel line. A missing GunOrigin or Barrel line is added. Only the numbers change; spacing, comments, line endings and encoding are kept.

Without -Pwrite nothing is written. -Pfilter keeps definitions whose <source set>: <pack>/definitions/<folder>/<file> name contains the text, such as /aaguns/ or 44_Tiger. The task never fails the build. What it cannot measure or place goes into the report, build/reports/shootPointSync/shoot-point-sync.md by default. The report opens with the values most worth checking by hand. A large move alone counts for little there; what ranks high are signs that the measurement may be wrong: a gun far from its gunner seat or on the other side of the hull, a muzzle on its own aim pivot, barrels measured on top of each other, a main gun that measures short or off centre, and points the tool had to leave alone.

Permission: Operator; executor: Player

Temporarily turns vehicle collision off or on for the executing player. The argument is the collision state: false lets the player pass completely through driveable collision hulls, and true makes the hulls solid for them again. With no argument, the command toggles the current state.

The bypass affects only physical contact with driveables. Their shaped hulls no longer stop, carry, separate, push, squash, or deal collision damage to that player. Blocks and ordinary entities remain solid, and vehicle interaction and projectile hits are unchanged. The state follows the player through respawns and dimension changes, but is cleared on disconnect or server restart.

Permission: Operator; executor: Any

As above, for the selected players. Without a state, each target is toggled individually, so a selector covering players in different states flips each of them. Targets other than the executor are told their new state.

Permission: Operator; executor: Any

Turns vehicle collision off or on for every entity. With false, players, mobs, dropped items and other loose entities all pass through driveable hulls; true restores it. Vehicles still collide with each other, since that contact is not resolved through hulls. Without a state, the command toggles the current setting.

This is a separate switch from the per-player setting: while all is false, every player passes through hulls whatever their own setting, and setting it back to true restores each player's own setting. It is cleared on server restart, and players who join while it is false receive it.

Examples:

/flandebug vehiclecollision
/flandebug vehiclecollision false
/flandebug vehiclecollision player Steve false
/flandebug vehiclecollision player @a true
/flandebug vehiclecollision all
/flandebug vehiclecollision all false

Permission: Operator

Lists or removes spawned Flan driveables and placed guns. This includes vehicles, planes, mechas, AA guns, and deployed guns. Removal is an administrative cleanup: removed AA and deployed guns do not drop their gun or ammunition items. Occupied entities are skipped, including driveables with a rider in any seat. The command reports how many were skipped. Operators can use remove force to remove occupied entities deliberately; this dismounts their riders.

Scopes:

The optional category narrows the selection. If it is omitted, the command uses all.

Accepted forms:

/flansmodultimate entities list radius <blocks> [category]
/flansmodultimate entities remove radius <blocks> [category]
/flansmodultimate entities list dimension <dimension> [category]
/flansmodultimate entities remove dimension <dimension> [category]
/flansmodultimate entities list world [category]
/flansmodultimate entities list <radius <blocks>|dimension <dimension>|world> include_unloaded [category]
/flansmodultimate entities remove world [category]
/flansmodultimate entities remove force <radius <blocks>|dimension <dimension>|world> [category]

Examples:

# Find every supported entity within 100 blocks
/flansmodultimate entities list radius 100

# Remove only nearby deployed guns
/flansmodultimate entities remove radius 50 deployed_guns

# Deliberately remove nearby deployed guns even while ridden
/flansmodultimate entities remove force radius 50 deployed_guns

# List planes in the Overworld
/flansmodultimate entities list dimension minecraft:overworld planes

# Include planes saved in unloaded Overworld chunks
/flansmodultimate entities list dimension minecraft:overworld include_unloaded planes

# Remove all AA guns in the Nether
/flansmodultimate entities remove dimension minecraft:the_nether aa_guns

# Remove all loaded mechas across the server
/flansmodultimate entities remove world mechas

List output includes the entity category, content-pack short name, runtime entity ID, coordinates, and dimension. Detail output is limited to the first 100 matches to avoid flooding chat; the final summary still reports the complete number of matches and a category breakdown.

Minecraft only keeps entities in loaded chunks active. By default, all three scopes report currently loaded entities. Add include_unloaded immediately after the scope to scan saved entity region files in the background and combine their unloaded entries with current loaded entities. This does not load chunks or change the world. The command reports the result when the scan finishes; large worlds may take longer, and it reports unreadable region data if the count may be incomplete. Unloaded entries show saved coordinates instead of a runtime entity ID. The radius scope is unsuitable for the dedicated-server console unless the command source has an intentional position and dimension.

• Commands that call for the executing player (/defaultammo, /rearm, /flandebug, /tryclass, /tryteam, several player teams commands, and the two operator-kit commands) fail from the dedicated-server console. /tryclass list and /tryteam list are the forms of those two that do not need a player.
• /fmparticle uses the command source's position and dimension, making it suitable for command blocks. Explicit coordinates are recommended from the server console.
• Success messages for administrative mutations are broadcast to operators according to Minecraft's normal command-feedback rules.

/flandebug htibox edits the damageable part boxes of vehicles, planes and mechas. /flandebug hitbox is an alias. Requires operator permission level 2 and a player: ride the driveable (including a passenger seat), or hold its item in either hand. A ridden driveable takes priority. Press F10 to see the debug hitboxes.

Part names have tab completion. There is one box per existing part name; use generic0 through generic9 for additional boxes. New arbitrary part names, rotated boxes and collision-mesh editing are not supported.

Positions and dimensions are model pixels, exactly as in SetupPart, including plane-facing conversion. Positions are the box corner, not its centre. Dimensions must be positive and at most 1024 pixels; coordinates and accumulated nudges must stay within �1024 pixels. Added HP must be positive and at most 1,000,000.

Edits affect every instance of the selected type, including existing and newly spawned driveables. The server controls edits and synchronizes the geometry to connected clients and players joining later. They last until reset or the session ends. No content-pack files are written. Existing damage fractions and destroyed states are preserved; removing geometry does not destroy the structural part. Reset restores geometry, not damage sustained during testing. Armour configuration and realistic health scaling are not recalculated by these commands.

For example, while holding the vehicle item:

/flandebug htibox list
/flandebug htibox set core -16 0 -32 32 24 64
/flandebug htibox nudge core 0 2 0
/flandebug htibox add generic0 100 -8 24 -8 16 8 16
/flandebug htibox remove generic0
/flandebug htibox reset

Copy the printed SetupPart geometry into the pack definition to keep the result. With realistic health scaling enabled, the listed HP is the runtime scaled value; retain the definition's original authored HP weight when copying geometry. These commands edit damageable part boxes; movement collision meshes and vanilla entity bounding boxes have separate behavior.

Permission: Operator; executor: Player

Gives the direct ingredients for one recipe operation of the held Flan item. The main hand takes priority; the off hand is used when the main hand holds no Flan item. Supports guns, ammunition, armour, parts, vehicles, planes, mechas, and other content-pack items with crafting or cooking recipes. Full inventories drop the remaining ingredients at the player's position.

Vehicle assembly includes the required number of compatible default engines. Part-box and gun/armour-box recipes take priority over crafting-table recipes; boxes from the item's own pack are preferred, then sorted by short name. Loaded crafting-table recipes are preferred over cooking recipes and sorted by recipe ID. For ingredient alternatives or tags, one matching item is given per occupied recipe slot. Quantities cover one operation, even if it produces multiple items. Ingredients are not recursively broken down into raw materials.