Mineflayer

# Mineflayer Mineflayer keeps a player on a Minecraft server that is not a person — and it does it two ways. Locally, it registers a fake player through the exact code path a real login uses, so the server itself cannot tell the difference. Remotely, it sends a bot to **another** server over a real client connection, and that server needs no plugin installed. Both join under a freshly generated name and a random UUID, every single time. ## The local fake player `/mineflayer m start` - **Same entry point as real players.** Registered through `PlayerList.placeNewPlayer`, the same path a genuine login uses. It shows up in `Bukkit.getOnlinePlayers()`, raises the player count by one, appears in the tab list, and keeps the server out of its idle state. - **Unkickable by design.** Three independent layers, because the server has more than one way to remove a player and no single layer covers them all: 1. *Prevention.* Every server-side watchdog that ends in a disconnect is reset twice a second — the keepalive timeout, the client-load timeout, the idle timeout (`player-idle-timeout`) and the flight checks. A timer that never reaches its limit never kicks. 2. *Blocking.* `PlayerKickEvent` is cancelled at `MONITOR` priority, which is the single funnel for `/kick`, bans, plugin calls and every anti-cheat built on the Bukkit API. The priority is deliberate: nothing gets the last word after this. 3. *Recovery.* If something removes the player anyway — an NMS-level disconnect that fires no cancellable event — it is re-registered **on the very next tick**, and it never gives up. A failing rejoin slows down instead of stopping, because the reasons a join fails are almost always temporary. Bans and whitelists do not stop the recovery layer: `placeNewPlayer` never consults `canPlayerLogin`. Verified by inspecting the server jar, not assumed. - **No body, and untouchable by commands.** Spectator mode, plus `invulnerable` and `collidable = false` set explicitly and re-applied twice a second. Damage, teleports and game-mode changes out of spectator are all refused, and **any command naming the player** — from a player, the console or a command block — is cancelled, except this plugin's own, which is the one intended way out. One deliberate exception: a selector command like `/kill @a` is *not* cancelled. Breaking the server for its real players to shield one fake one is the wrong trade, and it isn't needed — the individual effects are already refused above. - **Nothing that gives it away cheaply.** A plausible steady latency is reported instead of zero, since a ping of exactly zero is the clearest tell that no real connection stands behind a player. ## The remote bot `/mineflayer m connectto <ip> <port> start` Sends a bot to a **different server**, which needs no plugin and gets no special treatment. It is not a local registration — it is a real client connection: the plugin opens a socket and speaks the Minecraft protocol the way any client does, through Handshake → Login → Configuration → Play. The target just sees an ordinary player join, which is exactly why nothing has to be installed on it. Scope is **connect and stay**: it answers keepalive and ping, confirms transitions, reconnects on its own, and relays the target's chat into your console. It does not move, build or fight. Every automatic kick path is closed: | Path | What the bot does | | --- | --- | | `player-idle-timeout` | `player_input` every 15 ticks | | Client-load timeout | `player_loaded` on entering play | | Keepalive timeout | answers `keep_alive` and `ping` | | Flight checks | `move_player_status_only` every second, on-ground | | Repeated death | auto-respawn on `set_health ≤ 0` or a combat kill | | Resource-pack refusal | accepts and reports it loaded, in both phases | | Non-vanilla client detection | `minecraft:brand = vanilla`, default client settings | The idle timeout is the detail that matters most, and answering keepalive is not enough for it: per the server jar, nothing resets `lastActionTime` except a real position change or a `player_input` packet. `player_input` is used specifically because it resets the timer **without claiming any position**, so it cannot fail a movement or flight check. **Reconnect.** If the bot settles on the target and is then removed — kicked, restarted, dropped — it comes straight back with no wait at all. Anything that never settled backs off from one second to thirty and **never stops trying**. The two are told apart by session length, which is necessary: a target that kicks on sight also reaches the play phase for a moment, and without that distinction the plugin would reconnect forever at network speed. **Handoff.** The local fake player steps aside when the remote bot successfully joins, and comes back on `stop`. The order is deliberate — the local player is never taken down before the remote join is confirmed, so a re