Bukkit LockettePro - UUID Support 2.9.0

High performance sign-based lock plugin, highly customizable

  1. connection_lost submitted a new resource:

    LockettePro - High performance sign-based lock plugin, highly customizable

    Read more about this resource...
  2. Awesome!

    What are your thoughts on this?:

    However if I remember right vk2gpz opted to store it in sign/chest metadata instead after that point, though I don't know why. I haven't really kept up with it and don't know if anything has changed since then regarding signs and their line length limits server-side (ie no limit server-side, as Thinkofdeath said).
    #3 Absentee23, Mar 23, 2016
    Last edited: Mar 23, 2016
  3. The issues with UUID compatibility is that it either requires a database or the thing that you mentioned, squeezing the UUID on the sign.
    I believe you don't want a sign to look like this:
    Or this...

    I do aware that signs will allow more than 16 characters since 1.8, and signs will only display the first 16 characters max. So my potential solution (not tested) is to force those messy UUID part out of the screen. Such as:
    Not sure if this will correctly do the magic or not, but UUID support will be eventually added since LockettePro is already feature-complete, and will be backward compatible with signs placed before.

    Check back for more progress later ;)
    • Like Like x 2
  4. Ah yea, see my edit with another quoted message. That's exactly what I was talking about. :)

    Little confusing starting at the reddit post about encoding them, sorry. I meant to highlight Thinkofdeath's post there.
  5. Just tested, this thing is possible:
    • Like Like x 1
  6. I use Lockette and It works great with UUIDs. It doesn't display the UUID on the sign, It just changes to the new username..
  7. Not after you reboot the server...
  8. Lockette 1.8.14? I've ran this version for several years and never had a lockette fail or have a mess up after a reboot.
  9. I cannot test this right now but it is supposed to fail if you do:
    1. Start server
    2. Lock a chest
    3. Stop the server
    4. Change username
    5. Start server
    6. Try open the chest (It should not open)
    I have looked into the source of the plugin and it appears it uses MetaData to store UUIDs. MetaData is not persistent when server reboots.

    Since I don't want to change my username, so I did performed a test on something similar. According to source of Lockette, the plugin will attempt to search for MetaData on lock signs in order to determine whether the container is locked while checking hopper minecarts. So I did something like this:
    1. Start server
    2. Lock a chest
    3. Try steal it using hopper minecart (It will fail)
    4. Stop the server
    5. Start server
    6 Try steal it again using hopper minecart (success)

    Also I also know exactly how and why the performance is awful... I used to think about pull request instead, not gonna happen, too hard.
  10. connection_lost updated LockettePro with a new update entry:

    Fix minor issues

    Read the rest of this update entry...
  11. @connection_lost One feature you could add that people would love you for is add a time limit to signs so if a player is gone for so long the sign changes to ABANDONED and can be broken just a lil suggestion to put your plugin on top

    As for your UUID & Metadata issue I would not be appose to a MYSQL & MYSQLITE databases or for those who enjoy flat files shudder you could add those or a way to make metadata more reliable lol
    #12 Fluffy, Mar 24, 2016
    Last edited: Mar 24, 2016
    • Agree Agree x 1
  12. Signs can fit more than 16 characters (but only show a maximum of 16 characters) since 1.8, UUID support is now possible by putting player's uuid at the back and it will also stay hidden. See #4 for more details.
    I'm not sure how to make the sign abandoned yet... Maybe hiding the creation time in the sign could work.
  13. Basing it off of their #getLastPlayed() time would be simple enough I suppose (check on attempted access? on chunk load?). Otherwise you'd have to store when the chest was last accessed.

    It'd be annoying as a player IMO if it were based off of last access time: have to go open every one of my chests to make sure they don't become abandoned, so the simpler solution (last played time) is better I think in this case.

    The huge advantage Lockette has over every other container protection is the fact that it doesn't need any kind of storage system, the storage is the signs. Best not to take that advantage away IMO. There are other protection plugins that do things better, but Lockette is simpler.
  14. I'd rather say putting the "last access time" in the [Private] line ;)
    No no no that's not a good idea at all.
    But using getOfflinePlayer(xxx)#anyFunction() sounds expensive...

    Options for unlocking a chests are:
    1. If the chest is expired, user can open the chest & break the sign regardless of the lock.
    2. Upon chunk is loaded, plugin will launch a task that looks for signs. If a valid expired sign is found, do something to the sign. However this method is very expensive even some of the checks could be done in another thread.
    • Like Like x 1
  15. Joining the discussion and now watching until I feel like I should add something more, and option #1 sounds good. Maybe have a message when the sign breaks notifying the player that broke it, that the lock was worn or busted. so players don't think its a bug ;)
  16. Um, after thinking about this again, I suggest the lock should be bypass-able if "the player has not been online for a while" instead of "chest is not used for a while". In this case, guess the player should receive some message next time he joins...?

    (I'll start implementing the requested features above after we come into an agreement in solution)
  17. Oh that not what you meant the with option 1? because what meant was that the player is offline for say 30 days all there cheats can be broken into. so on the same page now? :p
  18. That wouldn't really work out considering the player's locked chest locations aren't stored anywhere, it's entirely based on the sign attached to the chest. Doing that would require scanning the entire world for chests belonging to a player, every time you need to check if it has been X days since they've last joined.

Share This Page