CommandBridge 3.3.2 - Stop treating your servers separately

[/u/_objz]

Running a Velocity network? You probably ran into this at some point. (you already know this catch) At some point you don’t just want to run commands across servers. You want actual logic. Data Communication between plugins. That’s where things usually fall apart. This update is mainly about that. CommandBridge now has a Developer API. The release itself also includes some fixes and internal improvements, but the API is the main focus here. Until now, everything in CommandBridge was built around scripts. That works well for a lot of use cases. But once you want to integrate your own plugin, or build more complex systems, it gets limiting. So instead of (not just) pushing scripting further, I added a proper API. https://preview.redd.it/yp6jjnt3dns...bp&s=ae418a8be558035c9d5440eea4c68eb5dc81c876 What it adds​ Send data between servers (proxy ↔ backend ↔ backend) Typed channels instead of string-based messaging Request / response system Execute commands remotely through the bridge Custom payloads (send your own data, not just commands) Listen for incoming messages in your plugin Player-aware delivery (only send if player is on the target server) Queue messages until a player joins Events for servers connecting / disconnecting Connection state tracking Player location lookup on the proxy Access to connected servers The important part is that this is not some wrapper around plugin messaging. It uses the same system CommandBridge already runs on, so it works even if: no players are online you have multiple proxies you are using WebSockets or Redis In short​ If you are developing plugins for a Velocity network, this lets you actually build systems across your entire network instead of per-server logic. Docs: https://cb.objz.dev/docs/3.3.2/developer-api/ If you try it out or build something with it, I’d be interested to hear what you do with it. submitted by /u/_objz [link] [comments]

Continue reading...