There are plugins enabling per-world, per-region, per-player and permissible markets with unique and specific prices. There are also plugins creating dynamic markets, where prices fluctuate after every transaction, using their own unique algorithms. Yet there are even more plugins dealing with item hoppers, special pickaxes, auto-sell chests, etc, all either using their own single static prices for the items they transact, or depending on a specific shop plugin.
In order to avoid forcing server administrators into using a single static market, creating conflicting prices or maintaining redundant pricing databases, we've needed an abstraction layer through which all of these plugins may communicate with one another other.
If you’re a setup specialist or server owner, installing plugins that implement and call Broker means you get to use Broker’s configuration to prioritize which you want used for price management and transactions. Getting all of your plugins accessing the same price database becomes possible. Using one plugin for spawners and another for everything else, becomes possible. You’re in control, as you should be.
If you’re the developer of a plugin storing or managing prices, having a Broker implementation allows other plugins to fetch your prices and transact, without knowing about your plugin. You’re instantly supported by all plugins using Broker.
If you’re the developer of a plugin needing to buy or sell things, calling Broker means that you’re not limiting server owners to the one or two shop plugins you’re willing to hard-code support for, nor are you limiting them to a basic static price file which potentially conflicts with other installed plugins. Calling broker means you instantly support whatever price managing plugin they already have installed.
Broker currently comes with default implementation for 10 different ItemStack Brokers:
Meaning that if you’re a caller, right off the bat, you support all of the above plugins.
Contributions providing more defaults are welcome, but if you are the maintainer of a plugin, please provide and register your Broker implementation within your own project rather than a PR. If your project changes, being able to update your implementation within the same version ensures there’s no incompatibilities between your plugin and the installed Broker plugin, and also just makes the whole project more maintainable. The goal is for Broker to eventually be able to remove all of its defaults.
If you know a plugin that you want to use Broker or have a Broker implementation, do respond with their name, and I’ll handle the rest.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
