ContainerDedication

logo for project

Players can make containers dedicated to only allow approved items.

ContainerDedication

Container Dedication

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.

  1. Player types: /dedicate next disallow
  2. Player places a chest.
  3. Player holds a diamond pick in hand and looks at chest.
  4. Player types: /dedicate allow
  5. Player holds a diamond sword in hand and looks at chest.
  6. Player types: /dedicate allow
  7. Player holds a diamond axe in hand and looks at chest.
  8. Player types: /dedicate allow
  9. Player holds a diamond shovel in hand and looks at chest.
  10. Player types: /dedicate allow
  11. 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:

Resulting chat window

A player wants to make a hopper that allows anything in it other than sand:

  1. Player types /dedicate next allow
  2. Player places the hopper.
  3. Player holds sand in hand and looks at hopper.
  4. Player types: /dedicate disallow
  5. Player types :/dedicate info and gets the information shown in the screenshot below:

screenshot of chat window after /dedicate info

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.

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of crunkazcanbe crunkazcanbe Jan 27, 2014 at 11:33 UTC - 0 likes

    @Dunbaratu: Go

    I hope this gets updated man . I love the idea ..

    BFAK:90867779,97854a7fad88c8a67415d0c0c85e58ff5a9026e39e7a74376640b56add0f514e http://files.enjin.com/520074/site_logo/banner2.gif

  • Avatar of Dunbaratu Dunbaratu Dec 16, 2013 at 12:11 UTC - 0 likes

    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.

    BFAK:90794910,a201633422b3d00da3d7a4fc9716c620b9f00b377d98eff6d6c9769231968680

  • Avatar of Dunbaratu Dunbaratu Aug 27, 2013 at 21:15 UTC - 0 likes

    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.

  • Avatar of Dunbaratu Dunbaratu Aug 26, 2013 at 07:58 UTC - 0 likes

    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.

    Last edited Aug 27, 2013 by Dunbaratu
  • Avatar of Dunbaratu Dunbaratu Aug 20, 2013 at 08:56 UTC - 0 likes

    @CommodoreAlpha: Go

    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.

    Last edited Aug 20, 2013 by Dunbaratu
  • Avatar of Dunbaratu Dunbaratu Aug 18, 2013 at 02:59 UTC - 0 likes

    @CommodoreAlpha: Go

    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:

    /dedicate [dis]allow exact
    /dedicate [dis]allow better
    /dedicate [dis]allow worse
    

    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:

    • Item is always treated the same regardless of damage value.
    • Exact matches.
    • better/worse matches.

    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 ).

    Last edited Aug 18, 2013 by Dunbaratu
  • Avatar of Dunbaratu Dunbaratu Aug 17, 2013 at 03:56 UTC - 0 likes

    @CommodoreAlpha: Go

    I have an idea for how I cold do it. Let me try a few things over the next couple of days.

  • Avatar of CommodoreAlpha CommodoreAlpha Aug 16, 2013 at 21:36 UTC - 0 likes

    @Dunbaratu: Go

    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.

    Sure, I'd love to include my server IP here. But it's under construction, and I wouldn't want to get sued for players wandering inside and getting hit by a random beam of steel floating about. And no, I doubt plugins would make very good lawyers either. I've never seen a plugin that forced you to sign a contract do so well.

  • Avatar of Dunbaratu Dunbaratu Aug 16, 2013 at 06:47 UTC - 0 likes

    @CommodoreAlpha: Go

    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:

    /dedicate allow
    

    and

    /dedicate disallow
    

    you would now have an option to add an extra argument:

    /dedicate allow exact (or) /dedicate allow dmg exact
    
    /dedicate disallow exact (or) /dedicate disallow dmg exact
    

    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:

    /dedicate allow dmg worse
    
    /dedicate allow dmg better
    
    /dedicate disallow dmg worse
    
    /dedicate disallow dmg better
    

    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).

  • Avatar of CommodoreAlpha CommodoreAlpha Aug 16, 2013 at 04:21 UTC - 0 likes

    @Dunbaratu: Go

    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.

Facts

Date created
Jul 24, 2013
Categories
Last update
Aug 27, 2013
Development stage
Release
License
GNU General Public License version 3 (GPLv3)
Curse link
ContainerDedication
Downloads
1,709
Recent files

Authors