Equip and Messages

Birth Equipment, Messages and Player Targeting

简体中文 | English

← Back to the index

This page covers the three "peripheral" configs: equip.yml decides whether a mob spawns carrying a pickaxe or blocks, message.yml decides what players actually read, and targeting.yml decides who the mob goes after first.

All three live in plugins/MobInteract/, and all three hot-reload through /mobinteract reload — no server restart needed.

1. What Each File Controls

File	Controls	When it takes effect
equip.yml	The spawn-equipment gate: whether this mob has any chance of getting a pickaxe / blocks	Rolled once, the moment the mob enters the world
message.yml	Every text sent to players (/mobinteract status / inspect / reload)	Read from the active snapshot each time a message is sent
targeting.yml	Player chase priority: switching conditions, radius, check interval	Checked every 10 ticks for mobs taken over by the plugin

One thing trips people up constantly: the two finer-grained chances are not in equip.yml.

What gets rolled	The key that actually decides the chance	Default
Pickaxe	mining.yml → tool.give.chance	0.8
Block backpack	placement.yml → backpack.chance	0.65

So tuning "how many mobs carry things" can mean touching three keys in three different files. The worked examples below sort out that nesting.

2. equip.yml: The Spawn-Equipment Gate

2.1 Only two keys exist

Key	Default	Notes
chance	0.10	Overall spawn-equipment chance (0..1); out-of-range values are clamped with a console warning
worlds.<world name>	{}	Per-world override of that chance; world names are case-insensitive, and worlds not listed keep using chance

chance: 0.10 means "at most 10% of mobs in the overworld carry anything". It only decides whether there is a chance — not whether it ends up being a pickaxe or blocks.

The file is generated automatically if missing. Even if you delete it, or delete one of its keys, the plugin still runs: a missing key is treated as chance: 0.10.

2.2 Inside the gate there are two more rolls

mob spawns
└── passes the gate: chance in equip.yml (default 0.10)
    ├── pickaxe roll: tool.give.chance in mining.yml (default 0.8)
    └── backpack roll: backpack.chance in placement.yml (default 0.65)

In other words: pass the gate first, then roll separately for the pickaxe and the backpack. The two rolls are independent — you can get one, both, or neither.

That is why the share of mobs with "pickaxe ∪ blocks" at spawn can never exceed chance. With the default configuration it is roughly:

0.10 × (0.80 + 0.65 − 0.80×0.65) ≈ 9.3%

The subtracted term is the overlap where both rolls succeed (0.80 × 0.65 = 0.52); without it those mobs would be counted twice.

2.3 Per-world overrides

chance: 0.10

worlds:
  world: 0.10
  world_nether: 0.30
  world_the_end: 0.0

• The world name is the folder name under the server directory, and it is case-insensitive (World_Nether is the same as world_nether).
• Worlds you do not list keep using the global chance above.
• 0.0 is the cleanest "no equipment at all in this world" switch — the End above.

Do not confuse this with the other kind of worlds: the worlds in equip.yml only controls the spawn-equipment chance, while worlds.whitelist / worlds.blacklist in mining.yml / placement.yml control whether mobs in that world take part in mining / placement. The first decides "do they carry tools", the second decides "even with tools, are they allowed to act".

2.4 Worked example: half the mobs should carry a pickaxe

Two formulas are enough:

pickaxe share = chance in equip.yml × tool.give.chance in mining.yml
block share   = chance in equip.yml × backpack.chance in placement.yml

Then solve backwards for chance:

You want	What to change	What you get
50% of mobs with a pickaxe	chance: 0.625, keep tool.give.chance at 0.8	pickaxe 0.625 × 0.8 = 50%, blocks 0.625 × 0.65 ≈ 40.6%
50% with a pickaxe, blocks as common as possible	chance: 1.0 + tool.give.chance: 0.5	pickaxe 50%, blocks 65%
10% with a pickaxe	chance: 0.125 + 0.8	pickaxe 10%, blocks 8.1%
Blocks only, no pickaxes	tool.give.enabled: false	blocks = chance × 0.65
Nobody carries anything	chance: 0.0	0%
Harsher Nether	worlds: {world_nether: 0.30}	Nether 30% pass the gate, overworld stays at 10%

The classic mistake: lowering both chance and tool.give.chance from 0.8 to 0.4 and expecting 40% — you actually get 0.4 × 0.4 = 16%, because the layers multiply. Before you edit, decide whether you are moving the gate or the roll inside it.

Afterwards, confirm with the "spawn equipment" line of /mobinteract status: without overrides it reads &7出生装备：&f{percent}%（全局）, and with overrides it shows the global chance plus how many worlds are overridden.

2.5 Boundaries worth knowing

• One roll per mob, fixed for its lifetime. A mob that failed the gate never gets a pickaxe later — not by picking something up, not on its first attempt to place a block.
• Already spawned mobs are unaffected. Editing equip.yml only changes mobs spawned afterwards. To equip the ones already in your world, respawn them or hand the equipment over manually.
• An occupied main hand is never overwritten. A mob already holding something will not be handed a pickaxe.
• pickup.only-equipped (on by default). Only mobs that passed the gate pick up blocks / pickaxes from the ground, so the combined "pickaxe + blocks" share is not quietly inflated by pickup.
• The gate is rolled exactly once per mob and the result sticks: a mob that failed it is never granted a backpack later on, so the share of mobs carrying blocks never quietly exceeds the value configured in equip.yml.
• To make mobs in your world build paths more often, the knob that actually matters is chance in equip.yml (plus the per-world overrides); backpack.chance only filters again inside the gate.

3. message.yml: Every Word Players See

3.1 Scope

Covered: every line of /mobinteract status (config summary, filter summaries, status words, path-building strategy, pickup, spawn equipment, runtime counters, BlockLocker state), every line of /mobinteract inspect (mob header, cooldowns, placements used, main-hand pickaxe, most recent behaviour, backpack summary and one line per backpack entry), and the success / failure replies of /mobinteract reload.

Not covered: console logs.

Missing is not fatal: a missing file is regenerated; deleting a single key falls back to the default built into the jar and warns once in the console. Nothing errors, nothing fails to start.

The bundled defaults are written in Chinese. For an English server (or any other language), just rewrite the values — nothing else needs to change.

3.2 Three writing rules

Colour codes use &. Write &7, &f, &8&m; they are converted to the Minecraft colour character when read. Only an & followed by a valid code character (0-9a-fk-or, lowercase) is converted — a lone & in body text survives untouched, so survival&creative stays as written.

Placeholders use {name}. The plugin substitutes them one by one; this is not a format string, so % can be written freely. The common ones are {label} (the command as typed, including the alias), {count}, {mob}, {worlds}, {percent}, {seconds}, {max}, {maxPerChase}, {kinds}, {total}, {id}, {type}. The comment above each key documents which ones it supports.

A list means multiple lines. Any message can be written as a YAML list and is sent line by line, in order:

command:
  status:
    header:
      - '&8&m--------&r &bMobInteract &8&m--------'
      - '&7a second line, anything you like'

Use this to split one /status line in two, or to add a divider to the header box.

3.3 The main keys

Key group	Contents
command.common.*	Shared fragments: no-permission / usage / player-only, plus the status words enabled (on) / disabled (off), on-text (on) / off-text (off), yes-text (yes) / no-text (no), none (none), forever (permanent), unmineable (not mineable), decided (decided) / undecided (undecided)
command.status.*	Every /status line: header, world-filter, mob-filter, mining, trigger, tool, placement, limits, runtime; inline fragments filter.world-all / filter.mob-all / filter.mob-default / filter.whitelist / filter.blacklist-suffix, lifetime-seconds, strategy.line / strategy.stair / strategy.stair-off / strategy.bridge, pickup.line / pickup.range, equip.global / equip.override, blocklocker
command.inspect.*	Every /inspect line: header ({mob}), no-mob, no-profile, cooldowns, placements, tool, status, backpack-none, backpack, backpack-entry (sent once per backpack entry)
command.reload.*	success (with {count}) / failed

Defaults of the keys you are most likely to touch — check these before editing:

Key	Default text	Placeholders
command.common.no-permission	&c你没有权限使用该命令。	none
command.common.usage	&e用法：/{label} <reload|status|inspect>	{label}
command.common.player-only	&c该子命令只能由玩家执行。	none
command.status.equip.global	&7出生装备：&f{percent}%（全局）	{percent}
command.status.equip.override	&7出生装备：&f{percent}% &7按世界覆盖=&f{worlds} 个	{percent}, {worlds}
command.inspect.no-mob	&e视线内没有怪物（把准星对准 16 格内的怪物再试）。	none
command.inspect.backpack	&7方块背包：&f{kinds} 种 / {total} 个	{kinds}, {total}
command.inspect.backpack-entry	&8 - &f{id} &7({type}) × {count}	{id}, {type}, {count}
command.reload.success	&aMobInteract 配置已重载（不打断进行中的行为）。已加载消息 {count} 条。	{count}
command.reload.failed	&c配置重载失败，详见控制台日志。	none

3.4 Two editing examples

Put your own server name in the reload reply:

command:
  reload:
    success: '&a[MyServer] config reloaded, &f{count} &amessages active.'

Swap the yes / no status words for ticks and crosses (status words are shared, so every boolean in /status changes at once):

command:
  common:
    yes-text: '&a✔'
    no-text: '&c✘'

3.5 Deleting a key means "back to default", not "turn it off"

• Delete a key and that line returns to the built-in default, with a one-off console warning; behaviour is unchanged.
• To stop a line from appearing, do not delete its key (deleting just restores the default) — edit the text instead.
• Never name a key after a YAML boolean. on / off / yes / no are parsed as true / false, which is exactly why the built-in status words carry a -text suffix (on-text, yes-text, …). Follow the same habit when adding your own keys.

3.6 Hot reload and the "message count"

/mobinteract reload re-reads mining.yml / placement.yml / equip.yml / targeting.yml / message.yml / update.yml together: parsing happens on the global region thread and the new snapshot replaces the old one wholesale, without interrupting mining or placement in progress.

The number in the reply is how many message entries are currently in effect ({count} in command.reload.success). If that number moves after your edit, the new file was really read; if it does not move at all, suspect broken YAML indentation, or a key that never existed.

Real failures go through command.reload.failed (&c配置重载失败，详见控制台日志。); the console has the details.

4. targeting.yml: Player Chase Priority

4.1 Five keys

Key	Default	Notes
enabled	true	Master switch
radius	16.0	Targeting radius (1..128); players are only prioritised inside it
interval-ticks	10	Check interval (1..200); 10 = twice per second
require-line-of-sight	false	Whether the player must be visible. false = the mob walks toward the player even through walls (with mining / path building, that means "break through and come at you")
keep-villager-target	true	Whether to keep the current target when no chaseable player is nearby; false = actively clear the target and focus on hunting players

4.2 What it actually changes

Every interval-ticks, a mob taken over by the plugin looks around: if a chaseable player (survival / adventure mode) is inside the radius, its target switches to the nearest player.

Rules worth remembering:

• An existing player target is never swapped. The override only fires while the current target is not a player, which stops the mob from oscillating between players.
• Creative / spectator players are not candidates. Only survival and adventure players are chased.
• Same world only. Players in another dimension are never candidates.
• Distance is measured in 3D. A player on top of a pillar or down in a hole still counts as nearest — which is why pillaring and digging mobs really do come to your height.
• It only changes "who". Vanilla pathfinding is untouched, so it never fights the mining / placement behaviours over movement.

4.3 How it relates to vanilla targeting

• Nothing vanilla is removed or replaced. A mob still attacks villagers and iron golems as before; players simply take priority when one is nearby.
• keep-villager-target: true (default) keeps the old target when no player is around, so the mob carries on with its business. false clears the target and hunts players — the "player-hunting server" setting.
• require-line-of-sight: false (default) is where the fun is: the mob walks toward you through walls, and combined with mining / path building it literally breaks through. Set it to true for something closer to vanilla behaviour.
• The "path blocked" mining trigger still reads the vanilla target: if a player is completely sealed off and out of sight, it will not fire, and trigger.configured-blocks is the fallback (see Mining).

4.4 Typical setups

What you want	How to configure it
Ordinary survival: players first, but not brutal	radius: 16.0, interval-ticks: 10, require-line-of-sight: true, keep-villager-target: true
Hardcore: chase on sight, break through walls	the defaults (require-line-of-sight: false); raising radius to around 24 is fine
Many mobs, tight on performance	interval-ticks: 20 (once per second), radius: 8.0
Mobs should only fight villagers, never be lured by players	enabled: false

5. Troubleshooting: Which Line to Check

Symptom	Check first
Mobs spawn without pickaxes	chance in equip.yml; whether worlds sets this world to 0.0; then tool.give.enabled / tool.give.chance in mining.yml
Mobs hold pickaxes but never mine	tool.require-pickaxe, and the "main-hand pickaxe" line of /mobinteract inspect
Mobs never build paths	backpack.chance, placement.enabled, placement.max-per-chase
Text edits have no effect	whether /mobinteract reload succeeded and the message count moved; YAML indentation; misspelled keys
Players walk past mobs unnoticed	enabled and radius in targeting.yml; whether the player is in creative / spectator; whether require-line-of-sight: true and the player is behind a wall
Mobs switch between players and villagers	Expected: the override only applies while the current target is not a player, and is never swapped once a player is targeted
Old mobs still carry nothing	Spawn equipment is rolled once at spawn; config edits do not affect mobs that already exist

Related pages

• Installation and upgrade
• Mining
• Placement and path building
• Backpack and pickup
• Commands and permissions
• FAQ
• Changelog