Jump to content

[SOLVED] [1.11.2] Locking a Chest - Just Need Confirmation


HalestormXV

Recommended Posts

Hey everyone, in my mod I have added in the ability for players to "lock their chest", this is mainly for SMP so that chests owned by players cannot be broken or opened unless they are the player that locked the said chest. This was a relatively simple setup, but it felt as if it was almost too simple. Can someone maybe take a look at this code and tell me if anything is wrong with it? It seems to actually work in my Dev environment, but as we know the Dev environment is the Dev Environment. I wouldn't want to push this to live and then it turns out something was wrong with it from the start.

 

Furthermore, as you can see I commented out some lines

Specifically: tileTag.setString("divinationLock_k_pname", player.getPersistentID().toString()); (in the item class)

if (!tileTag.getUniqueId("divinationLock").equals(event.getEntityPlayer().getPersistentID())) (in my chest handler)

and I had

tileTag.setUniqueID("divinationLock_k_pname", player.getPersistentID());

in my item class I think, but I may have erased it. I mainly did those to add UUID support to the item in the event the player changes their name. Is that the correct way to do it? 

 

However the UUID support question is last on the prioirty. I just need to know if the code that i have now is accurate and looks as if it can work. And yes I did do debugging of course, but sometimes a fresh set of eyes works wonders.

 

https://pastebin.com/ZcLpgh7Y  - Item Class

https://pastebin.com/PJFJzqKn - Chest Handler

Edited by HalestormXV
Link to comment
Share on other sites

Yeah it works on both but they are both Dev environment so before I push it live and then find out something is wrong (Which I know is sometimes the only way to do it) I wanted to ask here first.

 

Any thoughts on using the UUID instead of the player name? Would the setPersistentID and getPersistentID be the way to go about that?

Link to comment
Share on other sites

3 hours ago, HalestormXV said:

Any thoughts on using the UUID instead of the player name? Would the setPersistentID and getPersistentID be the way to go about that?

UUID is the way to go. Never* use a reference to an entity other than by UUID.

 

*There are exceptions, but they're rare

Edited by Draco18s

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Yeah, HalestormXV, persistent UUIDs are always the way to go. I was a little confused by your code, because it looked like in some places you were using UUIDs and in others, player names. Always use UUIDs when an entity may need to be referenced over multiple sessions. Another thing to note is that you will need to store the locked chest data in the world folder somewhere so you can reapply the locks when the server loads. I would recommend a custom NBT file.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.