Перейти к содержимому
Mineforgian

CommandBridge

Connect all your servers together and bridge commands across your entire Minecraft network.

Загрузки
7K
Подписчики
30
Обновлён
25 мая 2026 г.
Лицензия
GPL-3.0-only

Опубликован 26 апреля 2024 г.

Исходный кодСообщить об ошибке

CommandBridge

CommandBridge is a cross-server command execution plugin for Minecraft networks running on Velocity. You define commands in YAML scripts on the proxy, and CB registers and dispatches them across all connected backend servers. No plugin messaging, no player-online requirements, no limitations.

A player runs /lobby on a backend, the proxy picks it up. An admin runs /alert on Velocity, every backend executes it. Commands go through instantly over WebSocket or Redis.

separator

CommandBridge

Documentation GitHub Discord

separator

How it works

Everything runs through scripts. You create a .yml file, define the command name, arguments, where it registers, and what happens when someone runs it. Drop it in the scripts folder on Velocity and you're done. CB reads, validates, and registers commands on whichever servers you specified. If something is wrong, it tells you exactly what and skips that script. The rest still loads fine.

Here is a quick example. This registers /alert on the proxy and broadcasts a message to two backends as console:

version: 4

name: example
description: An example command script - edit or replace this with your own
enabled: false
aliases: [ex]

permissions:
  enabled: true
  silent: false

register:
  - id: "client-1"
    location: VELOCITY

defaults:
  run-as: CONSOLE
  execute:
    - id: "survival-1"
      location: BACKEND
  server:
    target-required: false
    schedule-online: false
    player-arg: ""
  delay: 0s
  cooldown: 0s

args:
  - name: player
    required: true
    type: STRING
    suggestions: []

  - name: message
    required: true
    type: TEXT
    suggestions: []

commands:
  - command: "msg ${player} ${message}"

separator

Platforms

One jar works everywhere. Install the same file on Velocity and all your backends.

6 Platforms

Transport

Pick one. WebSocket is the default and works out of the box. Redis is there if you need it.

Transport

WebSocket mode: Velocity hosts the server, backends connect to it. No external dependencies. TLS built in.

Redis mode: all instances connect to your existing Redis server. Useful if your servers are behind NAT or you already run Redis for other things.

Both modes support multi-proxy setups. One Velocity runs as the primary, any additional proxies connect in client mode.

Security

Every connection is authenticated with HMAC-SHA256. Both sides prove they know the secret without ever sending it over the wire. On top of that you get TLS encryption with three modes to choose from.

Security

TOFU is the default. Velocity generates a self-signed certificate on first startup, backends pin it automatically. Zero manual certificate management, encrypted from the start.

Execution modes

Commands can run in three different contexts depending on what you need.

Execution Modes

CONSOLE runs with full permissions. PLAYER runs as the player who triggered it. OPERATOR gives temporary elevated permissions for that specific command and nothing else.

Arguments

Full argument parsing with tab completion via CommandAPI. 22 types covering everything from basic strings to Minecraft-specific types like players, locations, items, and entities.

22 Argument Types

Arguments become ${name} placeholders in your command strings. PlaceholderAPI is supported too if you need external data like player stats or economy values.

separator

Built for real networks

CommandBridge is designed for production. Commands can be rate limited per player with cooldowns from milliseconds to hours. If a player is offline when a command targets them, CB queues it and executes it when they come back, even across server restarts.

You can apply delays to individual commands, reload all scripts without restarting with /cb reload, and run multiple commands in a single script with different targets and settings each. Everything is managed from one place on the Velocity proxy.

Player presence is tracked across the entire network, including multi-proxy setups. CB knows where every player is at all times, so commands that depend on a player being on a specific server just work. No guessing, no race conditions.

Requirements

Requirements

CommandAPI is required on every server. PlaceholderAPI via PapiProxyBridge and PacketEvents are optional.

separator

Metrics

This plugin collects anonymous statistics via bStats. You can disable this in plugins/bStats/config.yml.

bStats

Ченджлог

3.3.5Релиз26.1, 26.1.1, 26.1.2 · 25 мая 2026 г.

this update fixes a placeholder bug that prevented some scheduled tasks from ever resuming, adds a configurable task-expiry timer, and redesigns the admin CLI around resources with consistent rendering across console and in-game chat.

so whats new or fixed:

scheduled tasks

  • fixed ${arg} placeholders in execute target IDs not being resolved at queue time, so affected tasks could never match a connected client and never resumed
  • new tasks.expire-after config option (seconds; default 86400, 0 disables); expired tasks are pruned on load and on the 5-minute save tick
  • tasks left over with unresolved ${...} placeholders from earlier versions are dropped on load with a warning

admin commands

  • redesigned the /cb tree by resource:
    • /cb script list | show <name> [group] | enable <name> | disable <name>
    • /cb task list | clear <id>
    • /cb client list | ping [id] | players <id>
    • /cb config show [section] | reload
  • /cb script show <name> opens a clickable section navigator (permissions, register, defaults, args, commands); pass a group to drill into just that group as a syntax-highlighted yaml card
  • /cb script enable|disable <name> edits the enabled: line of the matching yaml file in place (comments preserved) and re-pushes registrations to connected clients
  • /cb config show mirrors the same summary + sections layout; drill into a section via tab-completion or by clicking it in chat
  • every argument-taking subcommand has live tab-completion now (script names, script groups, task ids, client ids, config keys)

rendering

  • single Report builder drives every command's chat output, so kvs, section headers, bullets, list items, action buttons, and pagination look the same everywhere
  • DebugPrinter exposes generic printRecord, printRecordOverview, and printList so any record renders as the same yaml card the old /cb scripts view used

removed

  • /cb scripts, /cb tasks, /cb list, /cb ping - replaced by the resource-scoped forms above (no backwards-compat aliases on v3)
  • /cb task show <id> and /cb client show <id> - their list views already show everything useful, no point duplicating

latest commit: 76edfda

3.3.4Релиз26.1, 26.1.1, 26.1.2 · 7 мая 2026 г.

This update includes a small fix for an issue where the version was saved incorrectly, causing the launcher to always ask for an update.

latest commit: 9563e3c

3.3.3Релиз26.1, 26.1.1, 26.1.2 · 15 апреля 2026 г.

there are no big changes here:

  • fix(velocity): deprecation warning was broken on NTFS systems
  • feature: added support for the latest minecraft versions(26.1, 26.2 and below)

latest commit: d7f43a1

3.3.2Релиз1.21.9, 1.21.10, 1.21.11 · 1 апреля 2026 г.

this update adds a public developer API for third-party plugins, hardens auth security, and fixes a bunch of stability issues across the board.

so whats new:

developer API

  • new api module for third-party plugin integration, available on maven central
  • typed message channels via CommandBridgeAPI.channel(Class) with send, request, broadcast, and listen
  • delivery conditions on senders: requirePlayer(UUID) to gate on player presence, whenOnline(UUID) to queue until the player connects
  • server lifecycle events via onServerConnected and onServerDisconnected (proxy only)
  • connection state tracking via onConnectionStateChanged (all platforms)
  • player locator service for resolving which server a player is on (proxy only)
  • CommandBridgeProvider.get() and CommandBridgeProvider.get(Class) to obtain the API instance
  • proxy-only methods return Optional<Subscription> instead of raw Subscription, returning Optional.empty() on backends
  • full JDK-style JavaDocs across all API types

security

  • hardened auth flow with constant-time HMAC comparison to prevent timing attacks
  • fixed AUTH_OK race condition where messages could be sent before the client processed auth success
  • added reconnect on failed server proof verification
  • operator execution no longer grants wildcard permissions, only explicit ones

fixes

  • fixed cooldown being applied before dispatch instead of after
  • fixed MiniMessage tags in error messages not being escaped
  • fixed script reload not being thread-safe
  • fixed player join events firing for already-tracked players
  • fixed polling not being reset on shutdown
  • fixed auth check missing on config reload
  • fixed Log varargs handling for single-argument messages
  • fixed config name not being passed to ConfigManager in the velocity backend adapter
  • fixed operator permission resolution being inconsistent across platform executors
  • left-aligned all chat UI output and removed pixel-width centering
  • various null guard and stability improvements across dispatch, registration, and player tracking

internals

  • modernized codebase to java 21 idioms
  • rebuilt test suite from scratch with 136 tests across core, velocity, and backends
  • added CI test workflow and testing documentation

breaking changes:

  • RunAs and ConnectionState moved to the api package, internal duplicates removed

latest commit: d7f43a1

3.3.0Релиз1.21.9, 1.21.10, 1.21.11 · 12 марта 2026 г.

this update is mostly about migration tooling, better player resolution, and support/debug quality of life. also had some internal cleanup and an important fix for velocity running in client mode.

so whats new:

  • added /cb dump for support snapshots (sanitized upload + local file export)
  • added /cb migrate to migrate script files to the current schema
  • migration is script-only now. there was a short config migration path but that got reverted again
  • added player-arg per command for target-required and schedule-online
  • added remote uuid resolving between connected proxies (RESOLVE_UUID) + local UserCache + Mojang fallback
  • added OFFLINE_PLAYER argument type with suggestions support
  • reworked schedule-online / player tracking flow to be more reliable and added clearer warning logs when player resolution fails
  • fixed double command descriptions in command registration output
  • fixed velocity client mode startup crash (ClassNotFoundException: org.bukkit.command.CommandSender)

breaking changes:

  • scripts now require version: 4
  • older scripts must be migrated first
  • internal runtime files moved into the data/ subdirectory

latest commit: e951a9e

3.2.0Релиз1.21.9, 1.21.10, 1.21.11 · 28 февраля 2026 г.

this version brings some nice additions mostly around target-required and player tracking across proxies. the wiki has been fully rewritten for this version so make sure to check that out.

so whats new:

  • target-required per command option. this makes sure the player is actually on the target server before dispatching the command. also works when a proxy is in client mode so it checks across all connected proxies not just the local one
  • per-command cooldowns, the old pipeline cooldown stage is gone
  • player presence tracking. backends and client mode proxies now sync their player lists to the proxy. the full list only gets sent once on auth and after that only join/leave deltas get sent so you dont have to worry about huge packets even with like 30k players
  • added PLAYERS argument type for velocity
  • scripts now require version 3

breaking changes:

  • removed Server.timeout from the config
  • removed some unused config values
  • script version 3 is now required, older versions wont work anymore

latest commit: 37b29f5

3.1.0Бета1.21.9, 1.21.10, 1.21.11 · 24 февраля 2026 г.

well this is a big version jump because it has major rewrites to support a second backend. what do I mean by that? CommandBridge was(or still is) being powered by Websockets. but some users asked for the feature to implement redis. So here it is:

  • full redis support as transport layer
  • you can either use websockets or redis depends on what you select in the config

so big version because the config has major changes and the plugin architecture

3.0.1Бета1.21.9, 1.21.10, 1.21.11 · 8 февраля 2026 г.

fixed:

  • example.yml was incorrect
  • commandapi unregistration on shutdown threw exceptions

added:

  • modrinth api - update checker

Комментарии

Загружаем…