ContainerDedication
Players can make containers dedicated to only allow approved items.
ContainerDedication
With this plugin, a player can decide to make a chosen container (chest, furnace, hopper, etc) become dedicated to only a limited list of item types. That container will reject attempts to put unapproved items into it, and if it's a hopper, it will also refuse to "suck" entities out of the world into it if they're not approved item types. The filtering can be controlled on a whitelist basis ( reject everything not explicitly approved) or on a blacklist basis (allow everything not explicitly disapproved).
This plugin is something I wanted on a server I run and I didn't find anything like it so I decided to learn a bit of the Bukkit API and make my own plugin to do it.
The original intent of this plugin was to make donation hoppers triggering redstone comparator mechanisms only when the material being thrown in the hopper is the right type of item. It has a few other uses as well, including making complex sorting machines that push out material into boxes along the way as they fall down a cascade of chests and hoppers.
Examples of use:
A player wants to make a chest that refuses to hold anything other than diamond tools.
- Player types:
/dedicate next disallow
- Player places a chest.
- Player holds a diamond pick in hand and looks at chest.
- Player types:
/dedicate allow
- Player holds a diamond sword in hand and looks at chest.
- Player types:
/dedicate allow
- Player holds a diamond axe in hand and looks at chest.
- Player types:
/dedicate allow
- Player holds a diamond shovel in hand and looks at chest.
- Player types:
/dedicate allow
- Player wants to verify that it's set up right, so player types:
/dedicate info
while still looking at chest, giving the information shown in the image below:
A player wants to make a hopper that allows anything in it other than sand:
- Player types
/dedicate next allow
- Player places the hopper.
- Player holds sand in hand and looks at hopper.
- Player types:
/dedicate disallow
- Player types :
/dedicate info
and gets the information shown in the screenshot below:
Command list
This main page is getting too long, so go here for the full command-line usage on its own separate page:
Permissions
containerdedication.next
- Player is allowed to use the/dedicate next
command. Note that players are only allowed to change the filter list for containers that they have previously placed with/dedicate next
(can't change other people's containers), so denying this permission also effectively stops the use of the other commands as well.containerdedication.reload
- Player can use the/dedicate reload
command.
Security and anti-griefing
If you are using a zone protection or anti-grief plugin of some sort, permission to place blocks does effectively become a prerequisite to editing a container's filter rules because of how ContainerDedication requires a container be placed by the same player as the player who's trying to alter its filter rules. If there's a zone of the world map in which you cannot build or destroy blocks, then you can't mess with a container's dedication filter there either since doing so would require breaking and re-placing it the container block. So while this plugin has no specific block protection or anti-grief capabilities, it works well in partnership with plugins that do.
Known behaviors and quirks
This main page is getting too long, so this list has been moved to a separate page here:
Please be aware that if you want to make any redstone mechanisms using the features of this plugin you should read that page and understand it.
IDEAS FOR MECHANISMS YOU CAN BUILD USING THIS
- Make a donation chute that requires putting a diamond in the chute to trigger a redstone mechanism: You make a dedicated hopper that only sucks up diamonds and nothing else, then put a redstone comparator against it that will send a brief pulse when the hopper has inventory in it for a moment.
- Make an item sorter out of a chain of hoppers and doublechests: Put two Dedicated hoppers underneath a doublechest such that their spigots dump in opposite directions. Put a chest on each destination spigot. If you configure the dedicated hoppers such that they have exactly the opposite filtering rules from each other (for example, hopper 1 allows everything except redstone, while hopper 2 DISallows everything except redstone) then this arrangement makes it so that items you put in the doublechest get sorted into the two boxes according to the rules of the hoppers. If the destination chests are themselves doublechests, you can build more hoppers under them to do the same thing again, chaining this process along to make a thing that works like a coin sorter at a bank.
Config YAML file
If you want to risk editing the config.yml file directly to create your own dedicated rules behind the scenes without having to fiddle with items in your inventory, or if you want to write software to automatically produce the configurations, you may find this description of the confg.yml file handy:
TO-DO list and known bugs
- Maybe some people would like to have a furnace that refuses to smelt into a disallowed output item. Can this be controlled by a setting the player chooses?
- There is no current way to change ownership of a chest other than to break it and have someone else place it. Perhaps there needs to be some type of 'give ownership to other' command.
- Maybe a container should be checked when its whitelist/blacklist changes, and if it has existing items in it that have become disallowed by the change, it should eject them out into the world as floating entities? I'm not sure if this is good or bad behavior.
- Put source on GitHub.
Hi nice idea.
Are you still working in 1.16 ??
I Didn't expect this to still work x.x
At least it works for what i need it for so that's cool
@Dunbaratu
I hope this gets updated man . I love the idea ..
In a few weeks I'll look into making an update to this plugin using 1.7.x. From the sound of it, 1.7.x might require that I change a significant amount of the code because 1.7.x prefers to handle the material ID's using the item names rather than the numerical IDs, which in turn may affect also how I store things in memory.
Watch this space. I'll wait until the next bukkit 1.7.x developer release comes out before I start working on it. It's still too alpha at the moment for my tastes.
So apparently when I added support for the exact damage values it introduced a bug on how non-damage value items worked. Fixed in 1.0.2 (soon to appear).
I wish it was possible to make scripts that re-run regression tests of the plugin for previous behaviors each time I make a change. But as this is a GUI program that's not really an option. The only option is to manually play the game and spend hours trying everything again for a mere one line change of code.
I made an error on permissions such that only Op's could use the plugin!
PLEASE GET 1.0.2 update once it becomes available
If anyone using version 0.3.3, or version 1.0.0 (for cb 1.6.2 users) has had problems getting command permissions to work, I apologise. In versions 0.3.3 and 1.0.0, the only players who could use the plugin properly were players with server Op status. Everyone else would get permission denied errors regardless of how you had your permissions set up. This was not intentional. There is a new version just uploaded that is currently in the review queue that will fix this. (The review process typically takes 1-2 days and is outside my control, so check back here again in 1-2 days after the timestamp of this post for a new version).
I thought I was being conscientious by mentioning the command's permission node in to my plugin.yml file. But I didn't realize that mentioning it there tells Bukkit to perform its own permissions check that can deny the command before my own code sees the command. This is what had happened in version 0.3.3 and 1.0.0 and I didn't notice that the permissions code I'd tested in previous versions wasn't working anymore with those versions.
@CommodoreAlpha
The bukkit reviewers have finally released my update from last Saturday. It should be available for download now. Be warned that I compiled it for craftbukkit 1.6.2. If you want a version for 1.5.2 let me know and I can recompile it for you and give it to you unofficially but I probably won't be hosting it on bukkitdev.
@CommodoreAlpha
I have just uploaded a beta version with the changes described in it. Once it's reviewed and available please give it a try and see if it does what you wanted. It will be called version 1.0.0.
(On a side note, I should warn you that I'm compiling with 1.6.2 now. I'm not going to continue supporting 1.5 now that the 1.6.2 beta has been out a while and seems pretty good.)
When first run, it will convert the existing config.yml file to the new format it needs if you have an old file from older versions.
Also, I didn't bother implementing the "dmg" versions of the commands. They were redundant and unnecessary when I looked into it further. So the new commands are just this:
Also, rather than attempting to implement the messy complex scenario where there exist BOTH exact rules and 'better/worse' rules, I made it so that each item type can only have one of the following choices:
What you can't do is have a combination of both exact rules and better/worse rules for the same item type (i.e. accept wool if it is exactly 3, or greater than 8. )
The exact match rule does allow you to build a list of exact matches, though (accept wool if it's 1, 3, or 7 ).
@CommodoreAlpha
I have an idea for how I cold do it. Let me try a few things over the next couple of days.
@Dunbaratu
I understand that the default value should include all damage values, simply because that is the more intuitive option.
But yes, your example commands to how it can be implemented are perfect (both the "exact" argument and the "dmg better/worse" argument).
As for saving the data and configuration files, most plugins that support damage values specify the damage value of an item (within the configuration) like so: "ID:DV" (DV is Damage Value). For example, if I wanted orange wool, most plugins would let you write in something like this: "35:1".
In most cases, for such plugins, if you specified something like "35" it will assume all damage values, and if you wrote something like "35:2" it will specify wool with only the damage value of "2". In other words, specifying damage value is completely optional. You could use the same idea to prevent backwards-compatibility issues.
@CommodoreAlpha
Okay thanks for the explanation. So basically it seems like "damage" was a thing that probably was actually damage once upon a time but then in later versions of minecraft more stuff was added and to avoid changing the data format, they re-used 'damage' for other purposes.
Hmm. I could do that, but there needs to be different command options for it I think. I think the default value should still be to apply a change to all items of the type you're holding like it does now. Otherwise it would get really annoying if, for example, you hold a diamond pick that's been damaged to 92%, use it to make a rule, and it makes a rule that ONLY applies to objects damaged at exactly 92% no more no less.
Also, using the wool example, I think the default a player would expect is "I'm talking about all wool here, not just the specific color of wool I happen to be holding."
Tell me what you think about this proposed change:
Where you used to say:
and
you would now have an option to add an extra argument:
This means "I only mean to apply the rule to this PRECISE item I'm holding." i.e. not all wool, but white wool explicitly, or not just any diamond pickaxe, but specifically only 100% undambed pickaxes like the one I'm carrying.
Or, optionally you could say this:
This is meaningful for use with damage values that are actually damage and not colors and such. So it would mean, for example, "allow items of this type that are this good or better" or "this good or worse".
Does that seem like it would work for you? I could implement this I think. The only hard part is how to save the data in the config file for it while still making it backward compatible with data already present from earlier versions (that's vital for my own server).
@Dunbaratu
I'm sorry for not clarifying earlier. "LWC" is a popular plugin that protects blocks on a block-by-block basis. It allows players to "own" a block and thus protect it from others.
And about "damage values", I'm referring to the "data value" of an item. For the purposes of this comment, "damage values" and "data values" are the same thing. Anyhow, let me explain what I mean by "damage values". Items have IDs; for example, the ID of "WOOL" is 35. They can also have "damage values" which are essentially extra data on the item. For instance, "WOOL" with the damage value of 1 is orange-coloured. "WOOL" with the damage value of 2 is magenta-coloured. And so on.
The purpose of an item's damage value differs between items. For tools, it's used to determined how damaged an item might be. For logs, wool, and the like, they're used to determine which "variant" of the item it is (colour, texture, etc.).
However, many items don't use damage values, like diamonds, or cobblestone. Thus, there is no difference between, say, an emerald with a damage value of "0", and an emerald with a damage value of "1". Some servers use the "unused" damage values on these items to create new variants of these items.
Uh, so yes, filtering based on any item's damage value. Tools aren't the only thing that can have this "damage value"; all items can have them.
@Fluxty
I was thinking about how to implement your suggestion about players being disallowed from putting some items in any chest anywhere but then I thought of an easy exploit to get around it if it was implemented, which almost makes it not worth doing it's so obvious to a player how to circumvent it:
Let's say you're a player who is globally disallowed from putting gold ingots in any chest anywhere in the game. So instead you place a hopper against the chest, and THROW the ingots onto the hopper (with the "Q" key), rather than placing them directly into the box or into the hopper. The hopper sucks the items out of the world and IT puts them in the chest for you.
Once an item is thrown out into the world, the game "forgets" who threw it. Utterly forgets. Any floating item on the ground is owned by nobody. So I don't know of a way to prevent this exploit if I was to implement what you say. (and unless I can think of a way to prevent it, there's no point in working on implementing the suggestion.)
Have you got any ideas how that could be prevented? I'd love to come up with a good way around that.
I tried the 1.5.2-compiled code on a 1.6.2 server and all seems well. So in the next version I'll be recompiling it to use the 1.6.2 library instead, and probably dropping support for the 1.5.x version once I do, as I don't want to maintain two branches.
I just had an idea and tested it out on my test server: You can make a coin sorter type mechanism with this (dump lots of stuff into the top hopper, and if falls through a series of hoppers and chests that cause different things to sort out into different destination chests). See the new edited description for how, under "IDEAS FOR MECHANISMS..."
@Fluxty
re: permission node to globally disable certain items across all containers. Yes, the way the code is written this should be in principle rather simple to implement. One worry I have though, is that I have no idea how to go about testing complex permissions logic given that Mojang won't let me be logged in as two different people at the same time without buying two different accounts. And I hear that in the 1.6 client, this is even harder to work around. That makes it hard to see if permissions logic is working right.
@CommodoreAlpha
re: damage values: Do you mean filtering based on how damaged a tool is? I'm not sure if that's what you meant since you gave WOOL and DIAMOND as examples, so I'm afraid I just don't understand what you're asking for.
re: ender chests Although I've had a lot of years writing Java code in general, this is my first plugin for bukkit and I still only understand the small subset of the the Bukkit API that I needed to write this. So you'll have to let me know what the acronym "LWC" means.
Could you support damage values on items, such as "WOOL:12" or "DIAMOND:4"?
As for ender chests, you could possibly support them with an optional hook into LWC. Basically, you check who "owns" the enderchest via LWC, then put items into their enderchest inventory. This is just an idea though; I'm not interested in enderchest support at all.
Any way you can enchance this plugin to have a permission node that globally disables certain items from being placed in any container by default?
As an example, the permission could look like: containerdedication.disable.<itemID>
This way, certain groups cannot store certain items in any container by default.