Running a Velocity network? You probably hit this limitation at some point

  • Thread starter Thread starter /u/_objz
  • Start date Start date
U

/u/_objz

Guest
Running a Velocity network? You probably hit this limitation at some point

If you are running a Velocity network, you probably ran into this at some point.

About 2 years ago I had a small Minecraft network focused on minigames. I really liked paintball for example. Since there were multiple minigames, I was running everything on a Velocity setup. So there was a lobby, a paintball server, and a few others.

At some point I hit a problem. The paintball plugin I really liked did not have proper Velocity support. It was just a normal Bukkit plugin doing its thing. That became an issue because players were not being sent back to the lobby when the game finished. The plugin simply did not have that capability.

Back then I had basically no experience running networks. But I had the idea: what if I just build something that fixes this?

So CommandBridge was born.

The original idea was simple. Since the plugin could execute a list of commands when a game finished, I thought: what if I create a command that runs /server lobby for that player on Velocity? Command + Bridge, because it bridges commands over the network.

In the very early stages I was still learning Java. This project honestly taught me most of it. I looked into native plugin messaging from Velocity and used that at first. It solved my initial problems. Then the plugin evolved. I added a small scripting system so commands were not hardcoded anymore and could even be dynamically registered and unregistered.

As the plugin got some traffic, users started using it for things I never even thought about.

For example:

  • Moderation commands like /networkreload that execute /reload on all backend servers while only running one command on the proxy.
  • Registering a command on Bukkit that sets a permission on Velocity. Why? Because many plugins cannot directly access proxy commands.

But this exposed a major issue.

Users started building workflows and more complex scripts. The old system was not capable of that. The scripting system was weak, and plugin messaging did not work if no players were online.

So v2 came.

About five months after v1, I did a complete rewrite. It introduced a much better scripting system with more capabilities. The biggest technical change: WebSockets. Velocity hosted it, and the Bukkit or Paper servers connected to it.

It worked. But it was still kind of funky. It was my first real plugin.

About a year ago I decided to rewrite everything from scratch. I literally scrapped everything, even the build setup.

Now we are at v3.

It keeps the same core idea, but technically it is completely different. The main focus was a type safe, capable scripting system, which is now mostly fully implemented.

CommandBridge now supports:

  • WebSockets as the standard mode
  • A Redis mode using a single Redis instance if you already have one

It also has a fully type safe command system using CommandAPI (huge thanks to that library). This allows full use of Minecraft’s Brigadier parser. In scripts you can define 22 different argument types. That includes suggestions for enchantments, players, positions, entity selectors, sounds, potion effects, item stacks, and more. It even supports proxying commands through /execute as ....

There is also dedicated multi proxy support. If you are running multiple proxies, one can act as the main host and the others connect as clients. Everything stays connected.

In summary:
CommandBridge connects your whole network together and makes it much easier to manage larger setups.

https://preview.redd.it/4epwuo0z7wm...bp&s=a246b8c65469e0983d1fd2d7834dc24fa6b15cce

Some features:

  • 6 platforms supported via one single jar. Just drop it in. Velocity, Paper, Folia (fully threaded), Purpur, Spigot, Bukkit. Most forks that do not change behavior significantly work as well.
  • Two transport modes: WebSocket (with TLS) and Redis.
  • Three security modes:
    • TOFU (default, secure out of the box)
    • STRICT (for more locked down setups)
    • PLAIN (not recommended)
  • WebSocket additionally supports TLS signing and HMAC.
  • Redis uses authentication for secure connections.
  • Three execution modes:
    • Console
    • Player
    • OP player (temporary op only for that execution)
  • 22 fully typed arguments via CommandAPI.
  • Built for real networks.
  • Supports Minecraft 1.20 up to 1.21.x.
  • Requires Java 21 and CommandAPI (other optional dependencies are listed on the website).

Yes, there is a dedicated website:
https://cb.objz.dev

It is also available on:


If you ever struggled with cross server commands, syncing logic between proxy and backend, or building actual workflows across your network, this is probably for you.

Any feedback, ideas, or criticism is appreciated.

Thanks for reading my little journey.

submitted by /u/_objz
[link] [comments]

Continue reading...
 
Back
Top