You basicly register Chests which can only be opened by an item that is defined as key to the chest.
The chests are reusable because they get filled in the moment someone opens the chest with a key.
Chests are identified by their name so you cannot use a name twice.
If you open a chest you lose one of the keys in case you got multiple ones.
Wildcard Permissions are avilable for chestaccess and nokey
CMDs:
/LCH || Is the main CMD and will show you the child CMDs you can use
/LCH edit or e || Will toggle the editmode. Don't forget to disable it!
/LCH getkey or gk or key or k <Amount> | <ChestName> || If you only provide <Amount> you will need to punch the registered chest
/LCH info or i || You will need to punch the chest you want more information about
/LCH register or reg or r <ChestName> || Will register a new chest by the name <ChestName>
/LCH save or s <ChestNames|ALL> || You can provide names of chests or the word all to save all registered chests
/LCH random or rand <Mode> <Amount> <Reuse> <AllowEmpty> || More infos below this post
Random Modes:
Infos to the CMD:
<Mode> := An Integer between 0 and 2, while 0 means that no mode is selected other Modes are explained below
<Amount> := An Integer that should be smaller than your items inside the chest as long as reuse is false.
How many Items will selected
<Reuse> := An Boolean (true or false). If you allow to reuse itemstacks they might be added multiple
times to the list of selected items
<AllowEmpty> := An Boolean (true or false). If you allow to use empty slots of the Chest(Some may refer to it as air)
some the list of selected items may add these
Mode “1”:
If you have a chest with n itemstacks in it every stack would have the chance of 1/n to be selected
If you set allowEmpty to true the chance for every stack including the empty ones is 1/27
Mode “2”:
If you have a chest with n_x itemstacks each with a random quantity q_x and the sum of all q_x shall be named q_all than the chance to select a specific itemstack would be chance := q_x / q_all
Example: A(30), B(10), C(5), D(3), E(2)
A would have a chance of 3/5 to be selected
B a chance of 1/5 and so on
As soon as I got a bit more time I might rewrite this definition
Known Bugs:
Double chests cannot be used. Reason: I don’t know how to access the carriers of the double chest inventory.
To access a double chest inventory, you would ask for Keys.CONNECTED_DIRECTIONS, and then check the chests in those directions.
Notes on the plugin
Multiple game states exist for a reason. It’s not a good idea to only register things after the server has finished starting. For instance, configuration stuff is accessible during GamePreInitializationEvent. In fact, commands are supposed to be registered during GameInitializationEvent; otherwise, if the server starts/stops multiple times, or never starts at all (such as a singleplayer/LAN world), then the features will never work.
The CommandSpec API is recommended over directly implementing CommandSource. Especially since it does argument parsing for you, which you seem to be spending a good chunk of code doing manually.
CommandResult.success() should not be returned if the command wasn’t, y’know, successful. If it failed, CommandException should be thrown. This can also be automatically done for permissions with CommandContext#checkPermission(CommandSource).
The only case where any of your supplied arguments will be null is if they’re manually called by another plugin, which doesn’t happen. Also, null-checking is built in to Kotlin with the ? operator.
Rather than saving chest data using Configurate, consider using a custom DataManipulator. This results in the data also being written to NBT, so it becomes part of the world instead of located within your config folder. It also means that your data won’t only save on server shutdown. Same deal as CommandSpec - sorta reinventing the wheel.
You can use event filters; i.e. fun checkForChestAccess(event: InteractBlockEvent.Secondary, @First player: Player) {. This will get the first Player from the Cause, and unwrap the Optional, and if it’s not present, the handler won’t be called.
Miscellaneous tip: If you use Gradle instead of Maven, you can use the kapt configuration to include annotation processing and auto-generate mcmod.info for you.
Renamed some CMDs(All cmds in first post will be updated)
Implemented a random mode for the chests! ( @toxxic Done your request well I at least hope so)
ItemStacks will now remember their position inside a chest inventory!
What still needs some work:
I need to put some more love in the random mode(Like adding different random mode types)
When you use a child CMD like register an you want to find out what arguments you need to supply without looking in this thread you might be disappointed atm.
Better handling for double chests
Please test the new release as much as possible. If you find any bugs please tell me
Seems like that Forge-Sponge is a bit different than Vanilla-Sponge I will do some testing later this day.
I’m at GMT +1 so might take some time at your location.
I wasn’t able to reproduce the stopping event error.
But I should have a fix for the other error which I will release in the next update which should be released next week.
I’m looking forward to the random mode. Basically, I want it so that the player who uses the key on the chest will receive something random inside it.
