Spigot BlockLocker 1.10.2

Protect chests, doors, etc. using signs. UUID compatible.

  1. rutgerkok submitted a new resource:

    BlockLocker - Protect chest, doors, etc. using signs. UUID compatible.

    Read more about this resource...
  2. Will you add support to Factions in future updates?
  3. Yes. I will add support for each group plugin that people request support for, so Factions is now on the todo list. Currently the plugin contains all features I'm using myself.
    • Like Like x 1
  4. rutgerkok updated BlockLocker with a new update entry:

    BlockLocker v1.0

    Read the rest of this update entry...
  5. Is there group locking? like how deadbolt has that. Like you only need one sign to lock all connecting furnance and other stuff. same thing with connecting chest (Normal Chest, trapchest side by side). Example of deadbolt config for the group locking:
    # Allows trapdoors to link with each other vertically
    vertical_trapdoors: true

    # Allows furnaces to act like chests, one sign for all connected blocks
    group_furnaces: true

    # Allows dispensers to act like chests, one sign for all connected blocks
    group_dispensers: true

    # Allows cauldrons to act like chests, one sign for all connected blocks
    group_cauldrons: true

    # Allows enchantment tables to act like chests, one sign for all connected blocks
    group_enchantment_tables: true

    # Allows brewing stands to act like chests, one sign for all connected blocks
    group_brewing_stands: true
    Also will it convert my 1.7 deadbolt sign if the first sign line is like this [Lock]
  6. Also be nice to have a towny support
  7. There is currently only group locking for chests and trapped chests. How far should protections extend for furnaces etc.? Is a few blocks enough?

    If you were using [Lock] instead of [Private] in Deadbolt, edit the plugins/BlockLocker/config.yml file and set private: '[Lock]' in the tag section of the file.

    I'll add Towny support.
  8. When i say group locking i mean not permissions group locking. What i mean is that when a chest is touching another trapchest side by side you only need one sign to lock both of those chest. So lets say both the trapchest and chest are touching each other and they r side by side. I place a sign on the trapchest and it say [Lock] at the top but this time i put a sign on the trapchest and it say [More users] because both of the chest are connected by one [Lock] Sign. I sent a private message to you because this might be confusing a bit. Im really bad a explain this :/
    #8 thu2468, Feb 3, 2015
    Last edited: Feb 3, 2015
  9. This plugin is free and open source.

    What I meant: if you have placed funaces like this:


    And attach a sign to the block on the left, should all furnaces get protected? And what if there are 200 furnaces in a row? Should the server search all furnaces for a sign, possibly loading new chunks? There should obviously be some limit, otherwise griefers can easily abuse this. If I set the limit at 5 blocks (so signs more than 5 blocks away aren't detected), would that be enough?
  10. Oh i see, maybe 16 or put it in a server config where we can decide how long it goes? because that how long a chunk is not sure how deadbolt does it but here the source
    Cant you make it so that it only check if the chunk is loaded and not make it load chunks?

    Can you also do this for alternating chest and trapchest? When you only need one sign on the left too
  11. Looking forwards for this updated. because deadbolt is now broke as of now qq with the name changing happening today
  12. I changed my Minecraft name from rutgerkok to Rutger. (My last name is no longer part of my username.) From what I observed:

    • Old chests (and doors, furnaces, etc.) with UUIDs on them recognize me, but don't update the name displayed on the sign. I will add this very soon.
    • Old chests without UUIDs are converted to use UUID, I can use the chest again after conversion. This only works because my old name is still in the name-to-uuid cache. I will add a feature very soon so that it looks up the new UUIDs based on old usernames (luckily Mojang has a web API for this).
    • I will add support for Towny and linked containers. About linking chests: I think it looks weird (a sign protecting another chest that is visually disconnected), but I can add this too. I will add this (Towny and linking) after I have added the features from the first and second bullet points, which is much more important to add now.
  13. Thank you ^^ <3 i needed that 3rd feature because that how deadbolt work and need a conversion from that thanks!!
  14. rutgerkok updated BlockLocker with a new update entry:

    BlockLocker v1.0.1

    Read the rest of this update entry...
  15. Nice. Nice update is the towny patch and storage block next to each other with one lock sign feature?
  16. Not yet. I wanted to have this update out as soon as possible. I'm currently working on adding Towny support.
  17. We're having some issues over on the Lockette side of the fence with name changes. I've been using the UUID version of Lockette for a few weeks now, @rutgerkok would you predict any issues switching from Lockette (storing UUIDs in metadata) to BlockLocker? What about now that some people have changed their name and some of the signs haven't updated with new names?

    Will it use the metadata-stored UUIDs and update the signs with them, or assume there is no UUID stored at all and lookup for each attempted access where names don't match.?
  18. I'm currently trying to find out where Lockette stores the UUIDs, it's not the sign NBT data where Bukkit metadata is stored. At this point, I'm even wondering if Lockette stores the UUID at all. I tried Googling where Bukkit stores metadata, but I couldn't find anything. Maybe it's a NBT tag in the chunk file?

    Anyways, BlockLocker will just relookup the player uuid (it assumes no UUID is stored at all). Even if a player has already changed their name BlockLocker is still able to look up the UUID using Mojangs name history API.

    Name lookups are cached, never on the server thread, avoided for online players and avoided for obviously invalid usernames. In other words: the relookup is unfortunate, but not the worst thing.

    I wouldn't predict any issues, but I would review both configuration files from BlockLocker (config.yml and translations-en.yml) so that you know that same blocks are protected. You can also remove the color code from the [Private] tag in the translations-en.yml if you don't want all [Private] tags turning blue. (I find it very useful myself to see which protections are converted to UUIDs, and it also matches the color scheme on my server for signs with behaviour, so that's why it's still the default. The default will change to black in version 1.1 though, as that seems to be what most people are expecting from the default settings.)
    • Like Like x 1
  19. rutgerkok updated BlockLocker with a new update entry:

    BlockLocker v1.1

    Read the rest of this update entry...
  20. Ok cool. So would it convert player name that already change their name? Like let say i changed my name from thu2468 to Thu and than add this plugin in. Would it detect thu2468 is my old name and convert it.