Padlocks and Keys: Locking and Moving Blocks with Inventories
Since the introduction of chests, there have been two constant problems in Minecraft: Thieving players and chests full of random items you don't want to move. To help with both these problems, I have a few connected suggestions, which are listed below. (For the purposes of this suggestion a block or a block's inventory being "locked" means a padlock has been applied to it, not that the inventory is necessarily completely inaccessible.)
Part 1: The Basics
1) Adding padlocks and keys for locking blocks with inventories.
2) You use the padlock and key on a block with an inventory by shift-right-clicking with a padlock, locking the inventory and giving you just the key.
3) Players without the key, droppers, and hoppers then can't access the inventory until you unlock it again by shift-right-clicking on the block with the same key, giving you the padlock and key back. You don't open the inventory this way. You can still open the inventory by holding the key in your hand and right-clicking normally without unlocking it.
4) You can break a locked block like any other block, but it doesn't drop its contents.
5) You can pick up this block and place it elsewhere, with the inventory still inside. But you can only hold it in your off-hand slot and can't place it in any other inventory.
6) Double chests need to be locked on both sides in order to stop people opening them. Locked chests won't connect to any chests they are placed next to, or which are placed beside them.
7) Locked blocks can be broken open by placing them in an anvil and paying an amount of xp levels depending on how filled the inventory is, similar to how comparators calculate their output, with the percentages of how full each slot is added up used to calculate the levels needed.
The basic idea to this isn't new, but it has always been plagued with problems, to which the solutions have always been complex, unintuitive and inelegant. When conceiving this idea I swore to make solutions that were none of those. I think I have succeeded, but judge for yourselves.
One thing to note, however, is that while I set out to help with the above problems, I don't simply want to solve them. Protecting your items from other players and cleaning up are part of the game, I feel, but the methods available are often time-consuming, frustrating and impractical for the day-to-day routine.
As you might know, Minecraft already has a locking mechanic, but only in the commands. I tried to keep my suggestion as similar to this mechanic as possible, as this would aid in keeping it simple, but some things were changed because they would have made things more complex or unworkable if I had kept them. I am not, however, suggesting this command be removed - my suggestion and this command can easily work side-by-side.
For those who are interested I'll now explain each point in more detail and explain the thought-processes behind them.
1) Padlocks
Why padlocks? Well, because, as a new feature, I decided the simplest way to add it was as an extra item, instead of overhauling the GUIs of each storage block. This, and to make locking an investment (however small). It also gives an easy way to link locked inventories to their keys and makes them reusable.
Though all of these things might apply if I had just suggested a key, having just a key would mean running into problems regarding explaining why different keys fit the same container, but the container could only be unlocked using the key it was locked with, and would circumnavigate the cost of locking a block because you could use the same key multiple times (it's either that or limiting the key to locking only one block, in which case the function would be exactly the same as the padlock and key, but you couldn't tell which key had been used already). The cost for locking each block is important, I feel, because having locking containers should be an investment, not a standard thing everybody always does.
You craft a padlock with two iron nuggets and an iron ingot, as shown here:
2) Locking an Inventory
As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama. The padlock and key item then changes into a key item:
This change is similar to the change when you right-click with a map. However, unlike with a map, the new item is only ever called "Key". The link to the block is stored as NBT data. While the lock mechanic through commands uses renamed items in hand to let the player open locked inventories, implementing this into my suggestion would have been difficult or make little intuitive sense, since then the keys would always need to be renamed, either through randomisation, in which case you couldn't rename it again yourself to your liking (such as "Bedroom Chest Key" or "Enderpearl Dispenser Key"), the renaming would need to happen upon either crafting or applying the padlock and key (a task I would prefer to leave in the proverbial hands of the anvil, the ownership of which shouldn't be necessary for using padlocks and keys) or any not-renamed key would fit any not-renamed padlock-on-an-inventory, as well as any item renamed "Key", which would defeat the purpose of the entire operation (and preventing this would require an anvil, with the same problems as before). The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
One important part to this is that if you do rename a padlock and key or a key, if you lock or unlock an inventory with it, the name remains the same.
3) Inaccessability of Inventories
I tried to limit the impact of this suggestion to just what it set out to do, to make sure it didn't infringe on other mechanics too much and become less useful. As such, while players, hoppers and droppers can't access the inventory (the latter two since otherwise other players could still mess with the inventory of locked blocks outside of how the player who locked it intended them to), the function of the block outside of that should stay the same. Dispensers should still dispense items, shoot arrows and potions and put on armour, hoppers should still push and pull items in and out of other (unlocked) inventories, and furnaces should still smelt. This means that players can't disable arrow traps by stealing the arrows, for one thing.
Regarding hoppers, this could mess with some complex redstone circuits that rely on items being pulled out of one hopper while that hopper tries to push the same item into a different inventory than the hopper that is pulling (people who care will understand that). In that case I'd suggest just not locking the top hopper. There is no workaround I can think of that is simple enough not to require a GUI of sorts, unfortunately.
4) Breaking a Locked Container
In order to prevent thieves from simply busting open a locked container, something that is far easier in Minecraft than in real life, either the container needs to be made unbreakable (or simply a lot harder to break), which allows for easy griefing by placing locked containers everywhere in someone's base, or it needs to drop without dropping the contents, something for which the shulker boxes were invented and which would be, frankly, overpowered and make shulker boxes useless. Between the pressure of this dichotomy is where these types of suggestions often break. But I think I've found an intuitive workaround: See the next section.
5) Only Holding it in your Off-hand
My workaround is to let locked containers be broken and picked up, which also lets you more easily rearrange and remove chests that are in the way without making you worry about removing and rehousing the contents.
But you can only pick it up (!) in your off-hand, and you can't place it in your or any other inventory. Think of it as jamming it under your left (or right, for you lefties) arm. This has a number of uses:
1) You can only pick up one at a time, which along with not being able to store them in other inventories helps prevent shulker boxes from becoming useless.
2) Your actions are limited until you put it down, since the off-hand right-click replaces the left hand one until the off-hand is emptied. So no torches or block-placing for you until you put it down (though you can still use buttons and such).
3) Thieves can only make off with one storage block at a time. This also means vandals need to work harder when destroying entire storage rooms, either letting each chest despawn or having to dispose of each chest one by one. This one is more in your favour.
Despite all this, if this is implemented I am positive locked chests will be used like backpacks, but this is ok, I think, because all other options for with-player item transport such as mules/donkeys, shulker boxes and ender chests are in many ways superior to carrying a locked chest around, so won't be skipped in favour of this.
One thing to note is that you can lock shulker boxes, and locking them doesn't override the fact they can be stored in any inventory slot (besides other shulker boxes). Because anything else would be silly.
I thought a great deal about how to lock double chests. Before I talk about what I decided on, let me list all the ways of solving this problem I dismissed:
1) You can't have one side locked and the other unlocked.
2) You can't have the padlock split between the chests if you break one. How on earth would that work?
3) You can't have the padlock stay on the half that isn't broken, while the other half breaks and spills its contents, or vice versa have the padlock stay on the broken half while unlocking the other half.
4) You can't have the entire chest drop as a new type of double-block/item, since that would over-complicate things dramatically (having an entirely new type of item/block, having a new mechanic to place a two block wide object).
5) You can't have the double chest be broken entirely and having it split up into two items, for the reasons for rejecting or 2) or 4).
6) You can't have the padlock just drop or break when the chest is broken, because, duh.
What I settled on was admittedly a little unsatisfactory, but the only way I could think of bar stopping double chests being lockable at all.
In order to lock a double chest, therefore, you need to padlock one half and then the other before the inventory is inaccessible. Before this, the half you padlocked is considered "locked", and will drop as a locked chest when broken, but remains accessible as long as the chest it is connected to is unlocked. Only when the other half is locked does the double chest say "chest is locked". If only one half of a double chest is locked and the unlocked half is broken, the half that is locked and hasn't been broken becomes inaccessible.
If one half of a completely locked double chest is unlocked, the inventory becomes accessible again, even though the other half is still considered "locked".
If one half of a completely locked double chest is broken, that half drops as a locked chest, while the other half stays both put and locked.
Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
While this is the only part of my suggestion that seems unrealistic and forces you to use two padlocks and keys, I decided that it was either that or not make double chests lockable at all, which wouldn't be satisfactory either, so I went with the route that didn't limit the player's freedom ingame.
7) Breaking Locks
I decided on letting players break open locked containers for two reasons: Keys can be lost, so making entire inventories completely inaccessible might be excessively frustrating, and stealing is fun, as long as not every random schmuck with a pickaxe can do it. Rogues who plan out heists and know exactly what chest to make off with shouldn't be completely thwarted, as long as they are prepared to sacrifice some xp levels (read: time) to do it. Base protection should be for thieves as well as vandals, and, while padlocks and keys can help against greed, I don't think they should be the be all end all.
What happens to a locked block when it is unlocked is simple: It becomes unlocked, nothing else. The padlock is "removed", though there is no "broken padlock" item which the player recieves, so the key becomes useless. You receive the newly unlocked block in the rightmost slot of the anvil, while any items that were in its inventory drop to the ground around you.
I decided on the anvil because what better place to literally break a lock and what better to force a player to sacrifice than levels? Levels are relatively costly, can scale, can be spent and are already somewhat abstract with no basis in reality. Any item wouldn't scale, or make sense (you wouldn't need more lockpicks to open a full chest than for an empty one, for example, and if you did, why?), and a tool could never be expensive enough and make some modicum of sense.
Through back and forth with ScotsMiser I decided on copying a system already in the game in order to calculate the amount of levels a player would need to spend, namely, the way comparators calculate their redstone output. This was to approximate the xp cost to how valuable the inventory might be, and make sure chests full of (possibly enchanted) tools were not cheaper to open than chests full of dirt. While the system is a little complicated in how it calculates the amount, all this calculation is done by the game, and players needn't be confronted with it - only with the end result, which is why I deemed it a good idea.
How this system works is follows: The amount of xp levels a player needs to pay to open a block's inventory is determined by calculating to what percentage each slot of that inventory is filled, adding these percentages up, then rounding up to the next xp level.
A couple of examples:
1) A hopper has one slot filled with 64 blocks of cobblestone. 64 is the maximum amount blocks of cobblestone stack up to, so it is a full stack, 100% filled, or 1 stack. The rest of the slots are empty, so have 0 stacks. Since a hopper has five slots, it calculates 1 + 0 + 0 + 0 + 0 = 1 xp level. You need to pay 1 xp level to break open the hopper.
2) A hopper has one slot filled with 64 blocks of cobblestone (1 stack), one slot filled with 16 eggs and one slot with a hoe. The eggs only stack up to 16, so it is also a full stack (1 stack), and the hoe doesn't stack, so it also counts as 1 stack. The other two slots are empty (0 stacks). To break open this hopper you need 1 + 1 + 1 + 0 + 0 = 3 xp levels.
3) A hopper has one slot filled with 64 cobblestone (1 stack) and one slot filled with 32 cobblestone (50% filled, or 0.5 stacks). The rest of the five slots are empty (0 stacks). The xp levels are first calculated by adding 1 + 0.5 + 0 + 0 + 0 = 1.5, which is then rounded up to 2 xp levels.
4) A hopper has one slot filled with 64 cobblestone (1 stack), one slot filled with 4 eggs (25% of a stack, or 0.25 stacks) and one slot with a hoe (1 stack). The rest of the slots are empty (0 stacks). You calculate 1 + 0.25 + 1 + 0 + 0 = 2.25, which is then rounded up to 3 xp levels you would need to pay.
The maximum amount that it is possible to pay with this system is 27 xp levels, when breaking open a chest or shulker box.
This was part 1 of my suggestion. Part 2 will cover all the features that could be added in addition to the above, but are not part of the core suggestion.
Part 2: Everything Else
Locking doors
Being able to lock doors (and trapdoors, and fence gates) is the natural thing to think of after being able to lock chests and inventories, however, there is less reason for it to exist than the above - after all, the schmuck with a (pick)axe can just tunnel through or around. That said, there are still a number of ideas why I think locking doors (as in, not being able to move the door from one state to the other without the key) is still a good feature to implement:
1) It would work well for adventure maps in adventure mode, since then the schmuck actually needs a pickaxe, and might not have one. Actually having a key item removes the hassle for mapmakers to program something that would be bog-standard in most adventure games.
2) You could control villagers more easily, without having to block doors with blocks. For the aesthetically minded dict- I mean, caretaker.
3) Being able to lock iron doors and trapdoors in an open or closed position gives builders more options - this would mean locking a door, trapdoor or fence gate would stop redstone opening it.
4) If nothing else, it might give you a few extra seconds to prevent someone entering... somewhere.
Locking Mobile Inventories
The next natural thing to think of after locking door is locking all the mobile inventories on minecarts and animals. This would work exactly like locking block-inventories: Shift-right-click on the minecart or animal with the padlock to lock the inventory, right-click with the key in hand to open the inventory and shift-right-click again to unlock the inventory. Killing the animal or destroying the minecart drops the still locked inventory block (chest or dispenser).
The only thing that would deviate from this is the furnace minecart. Since it doesn't technically have an inventory you can access I would be fine with just excluding it fro this suggestion, but you could technically lock it to prevent coal being added. I don't know why anyone would want that, but hey, might as well strive for completion. (Note: I don't actually want this. I just don't want to redo the image I made above.)
Keyrings
Now come the suggestions with are to do with extra convenience. You might have noticed that, since every key takes up on slot of your inventory, you wouldn't want to lock very many inventories (or doors, trapdoors and fence gates). I noticed this too. Aren't we are smart bunch of people? But I have thought of a solution: Keyrings!
Keyrings are for keys what sand and ball-pits are for kids: Places/things you can put them so you can go off and enjoy the finer things in life. (Disclaimer: Please don't abandon your kids.) Keyrings let you combine multiple keys (and their NBT data) into one item. There's no upper limit to the amount of keys you can put on it.
Keyrings are crafted using four iron nuggets, like so:
Keys are then added to it by crafting them together with the keyring:
Right-clicking on the inventory (or door, trapdoor or fence gate) with the keyring will open that inventory (or door, trap- I'll stop) as long as the key that locked that... object is on the keyring. Shift-right-clicking removes the padlock from the object and the key from the keyring, placing the combined item in another slot of your inventory. This is also the only way of removing specific keys from the keyring - no other method besides a GUI would let you specify what key to remove.
The other method of removing keys would be doing so one by one, in a crafting grid. Keys would be removed in the order they were put on the keyring, or depending on where they were on the list of keys in the NBT data:
Since every key would retain its NBT value, it would also keep the name it had, if it had been named in an anvil.
Copying keys
The second suggestion to do with convenience would be being able to make copies of keys. Just like with maps and with books, keys are things that might benefit from having copies made. From having multiple keys in case you lose one, to communal chests (or giving your friends the ability to access your chests).
As the above image shows, copying keys would be similar to how maps and books are copied. You craft your key with one to eight iron nuggets, and one to eight keys are created while the original is returned to your inventory. This can also be done using the padlock.
These copies are all named "Copy of Key", with "Key" being replaced by the name if you had renamed it. Instead of as with books, however, this can only be done with the original - none of the copies can be crafted with iron nuggets. This limits the damage that can be done by rogue copies.
What's interesting about the copies is that they can't be used to unlock stuff. You can use them to open the things their originals have locked, but shift-right-clicking with them on the locked object is no different from right-clicking. This fact means you can feel safer giving your friends these keys, and means you might want to carry around a copy of a key instead of the original, in case you die and lose it.
Keyrings would accept copies of keys, though the only way to remove them would be to painstakingly uncraft them. You could technically add multiple copies as well as the original to a keyring, but this wouldn't change its function.
This was my suggestion. Feel free to critique it! (Not that I could stop you.) And feel free to suggest additions or changes of your own.
Changelog:
05.09.18 Explicitely stated the fact you can open locked blocks with the key in hand without removing the lock.
06.09.18 Added changelog.
06.09.18 Added the problems with the current offhand.
11.09.18 Changed how to calculate how many xp levels are necessary to break open locked inventories on an anvil. Cleared up confusion on other parts.
26.02.19 Added multiple possible additions to the core idea.
While I was expecting the worst going in, I am happy to say this is well thought out to almost every detail! A vanilla locking system would greatly improve storage and security (not to mention, your system is better than the plugins I've experienced) and it would be amazing to move around chests without the items dropping.
Thank you so much for your support and feedback! I'm glad my work payed off.
Despite me harping on about mirroring the lock using commands, I forgot to explicitly mention I would keep its most distinguishing feature: Opening the container using right-click when holding the key without unlocking it. I've explicitly mentioned it now.
This is kinda like an ender chest combined with a Shulker Box.
I may support this as a cheap alternative; however, this makes the game easier than it should.
It does have aspects of both, if used in that way, though I'm sure I'd prefer either to having to carry a locked chest around. It's too unwieldy for anything else. It's not even practical for caving, since you couldn't place torches, unless you were prepared to throw it down every time. Unless you put it down in a temporary base, then filled it up and took it with you afterwards...
Hm. Well, it certainly helps. I can't really say if it would make things too easy. What would be too easy? I'd say making the experience less engaging by making it less challenging, and not replacing that by adding other challenges, and the system does offer those. I'm not sure how to test this without actually testing it by playing.
You cannot currently access your off-hand slot while using an anvil. That said, I don't know of any gameplay reason for this, since you can swap easily, so it might be subject to change.
Thanks for pointing that out. I didn't know that. In fact, I might almost consider it an oversight, a bug. I'll have a look on the bug tracker and maybe report it.
I wouldn't call it a bug, because it's not an error. It's a missing feature. They would need time to implement it, and the only thing it would improve is making your padlocks work.
Not necessarily. Being able to access your entire inventory in a crafting or storage block is a benefit by itself, even if padlocks were never implemented. You can't access the offhand slot on chests (any kind), furnaces, crafting benches, or enchanting tables, which is inconvenient, albeit only slightly so. So saying that the only benefit to fixing that is this idea would work is disingenuous.
As for the idea as a whole, I like it. I don't typically play MC online so it won't effect me but it seems like a good idea.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
There are some additions/changes I think might be worthwhile:
duplicate and master keys: the ability to make duplicate keys, preferably with a distinction between duplicate and master keys– and with the ability of the holder of the master to 'rekey' the lock.
I suspect this would require recording the player ID number [or equivalent] in the NBT data for each padlock, but would extend the utility of the item considerably.
WRT unlocking costs:
As presented a 54-slot chest with 'some' diamonds and 53 seeds could cost between 2 and 54 levels to 'pick' using an anvil (2&27 levels if only half chests are considered).
The following involves quite a bit more calculations, but these would only need to be done when a chest is 'picked' on an anvil (a comparatively uncommon event one should think):
each slot should be checked for the degree to which it is filled and the sum of these should represent the level cost to 'pick'
16 eggs in one slot and 16 eggs spread across 16 slots would thus incure the same cost.
This would require more effort by the owner to impose a maximal cost, but would avoid padlocked chest "always" costing 27 or 54 levels to open. [Keeping my_cool_stuff plus a stack of seeds/cobble in a chest would make imposing maximal 'picking' cost trivial.]
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
WRT double chests; given the new placement mechanics, two half chests (27 slot) can occupy the same space as a double chest (54 slot) so allowing only the 27-slot model to be padlocked would be less of an issue. This would impact using the padlock as a way of moving loaded chest, but would make the interface simpler.
As I read it, one is required to use a padlock on each of the half chests that comprise a double chest. I see no easy way to do this as – for at least an instant – there will be one side padlocked and one side not. This would seem to mean the the game would need to be programmed to allow a window in which to add the second padlock: this window might be subject to undesirable use.
A possible work-around would be to permit only half-chests to be padlocked, but allow two half chests to join IFF both half chest keys (or master keys if the above addition is made) had been created by the same player. [This would seem to require recording player UUID or similar with each padlock and key NBT data; how much complexity that would add is unclear to me.]
While I like the ideas presented (with or without the suggested changes/additions), the proposal as a whole strikes me as solving an issue some players experience. As such, I would prefer this to be available as a mod [& it is most unfortunate that MS/Mj has not seen fit to modularize a numvber of their additions] than written into vanilla. My assupmtion is that the extensions of the game proposed here would entail at least some overhead, which the current performance difficulties strongly advise against.
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
I wouldn't call it a bug, because it's not an error. It's a missing feature. They would need time to implement it, and the only thing it would improve is making your padlocks work.
Badprenup answered more or less how I would have, so I won‘t repeat what they said. I‘m just going to state what I found in the bug tracker. As of now, it seems like the offhand slot not being accessable in any inventories is intended, as an extension of the armour slots not being accessable either. https://bugs.mojang.com/browse/MC-84410?jql=text%20~%20%22offhand%20horse%22
However, I agree with Badprenup that there‘s no reason it couldn‘t be accessable, especially as it functions almost exactly like an inventory slot anyway, except for the fact that items on the ground aren’t picked up by the offhand. That‘s also important for this, but has been confirmed as a bug. https://bugs.mojang.com/browse/MC-84849?jql=project%20%3D%20MC%20AND%20text%20~%20offhand
What I‘m going to do is make a small suggestion and link to this one and back.
My thanks! You‘ve put quite some thought into possible additions, which means my idea stirred you creatively, which is a nice compliment.
There are some additions/changes I think might be worthwhile: duplicate and master keys: the ability to make duplicate keys, preferably with a distinction between duplicate and master keys– and with the ability of the holder of the master to 'rekey' the lock.
I suspect this would require recording the player ID number [or equivalent] in the NBT data for each padlock, but would extend the utility of the item considerably.
That does sound worthwhile, though I‘m not sure I know what you mean by „rekey“. I‘m guessing you mean „taking the padlock off“, so I‘ll assume you mean that, because that seems a logical extention of what you‘re proposing. To craft it, I suppose copying how written books are copied would be the optimal method, crafting the original key with one or more iron nuggets.
If this suggestion is ever implemented, you can be sure I‘d add this to the possible additions suggestion. Or maybe even now - I‘m hankering to make an extra thread for all the possible but not necessary additions to this suggestion.
WRT unlocking costs:
As presented a 54-slot chest with 'some' diamonds and 53 seeds could cost between 2 and 54 levels to 'pick' using an anvil (2&27 levels if only half chests are considered).
The following involves quite a bit more calculations, but these would only need to be done when a chest is 'picked' on an anvil (a comparatively uncommon event one should think):
each slot should be checked for the degree to which it is filled and the sum of these should represent the level cost to 'pick'
16 eggs in one slot and 16 eggs spread across 16 slots would thus incure the same cost.
This would require more effort by the owner to impose a maximal cost, but would avoid padlocked chest "always" costing 27 or 54 levels to open. [Keeping my_cool_stuff plus a stack of seeds/cobble in a chest would make imposing maximal 'picking' cost trivial.]
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
You‘re talking about a system similar to how comparators calculate their output. I thought of doing that too, but the reason I decided against it is because either 1) you‘d need to assign a maximum amount of levels that can be spent (just like redstone travels a maximum of 15 blocks; 30 levels spring to mind), of which the percentage that needs to be paid is calculated as being equal to the percentage of how full the inventory is, or 2) you’d need to assign an amount of levels to each filled slot, with the percentage of how much the slot is filled being equal to the percentage of the amount of levels the slot is worth.
For example, if you‘d take suggestion 1), a chest with two slots filled and one slot half-full (with 32 stone or 8 eggs) would cost (2.5/27)*30 = 2.77777777.... (2.5 slots filled, 27 maximum slots, 30 maximum levels) or, rounding up, 3 levels to open. A hopper with the sme amount of slots filled, however, would cost (2.5/5)*30 = 15 levels to open; this despite the items and the amount of items being the same. This discrepency is fine with comparators, who only want to figure out how full the inventory is, but with padlocks I really think either the actual amount of items, or at least the amount of different items/slots should define the cost.
In which case you might say to take idea 2) instead, however, in that case you‘d need to assign at least 2 levels per slot (any lower and it would be the alternative I decided on, and would ignore percentages) which would make a chest with every slot filled more than halfway cost a whopping 2*27 = 54 levels to open. (2 levels per slot, 27 maximum slots.) That‘s too much for one chest, since each additional level takes more xp than the last to reach. Having to pay 27 levels twice would be trivial compared to having to pay 54 levels at once.
There is perhaps a third option, and while it is more complicacted to implement, it‘s perhaps a suitable compromise. You‘d take idea 1), and make sure the maximum number of levels to spend is equal to the amount of slots the inventory of the block you‘re breaking open. So a hopper would need a maximum of 5 levels and a chest would need a maximum of 27. So in both cases two and a half slots filled would equal 2.5 levels, or, because of rounding, three levels to spend. What do you think? It would be easy to understand, I think, which is the main thing.
WRT double chests; given the new placement mechanics, two half chests (27 slot) can occupy the same space as a double chest (54 slot) so allowing only the 27-slot model to be padlocked would be less of an issue. This would impact using the padlock as a way of moving loaded chest, but would make the interface simpler.
As I read it, one is required to use a padlock on each of the half chests that comprise a double chest. I see no easy way to do this as – for at least an instant – there will be one side padlocked and one side not. This would seem to mean the the game would need to be programmed to allow a window in which to add the second padlock: this window might be subject to undesirable use.
A possible work-around would be to permit only half-chests to be padlocked, but allow two half chests to join IFF both half chest keys (or master keys if the above addition is made) had been created by the same player. [This would seem to require recording player UUID or similar with each padlock and key NBT data; how much complexity that would add is unclear to me.]
Well, how I imagined it was that a double chest with one side locked would function exactly like a double chest that hadn't been locked yet. And could stay half-locked indefinitely. It would only become fully locked when the other side was locked too, and be openable again if one side was unlocked. If it was half-locked and the locked half was broken, it would drop a locked chest. Breaking the other side would just break the chest and spill items everywhere.
What do you mean with "undesirable use"? I wouldn't go down the route of storing player-data, though; that would overcomplicate things for players. I suppose I could add a poll asking if people prefer beng able to lock double chests, or only single chests, if we can't clear this up between us.
What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think.
While I like the ideas presented (with or without the suggested changes/additions), the proposal as a whole strikes me as solving an issue some players experience. As such, I would prefer this to be available as a mod [& it is most unfortunate that MS/Mj has not seen fit to modularize a numvber of their additions] than written into vanilla. My assupmtion is that the extensions of the game proposed here would entail at least some overhead, which the current performance difficulties strongly advise against.
Well, the problem of not wanting to move chests that are in the way but are full of random items that you don't want to sort through is one that most players experience, I think. The other one, people stealing from you, is one enough other players experience that most public servers have plugins to help prevent it. It's impossible to have additions that everybody will use - some people only play to build with redstone in creative, or to fish; you can't please everybody.
I'm not such what you mean with the performance difficulties and overhead. Do you mean RAM? I hardly think one extra item and one or two new(ish) blockstates/NBT tags will add to that.
Thank you for your input. You've given me a lot to think about.
duplicate and master keys: the ability to make duplicate keys, preferably with a distinction between duplicate and master keys– and with the ability of the holder of the master to 'rekey' the lock.
I suspect this would require recording the player ID number [or equivalent] in the NBT data for each padlock, but would extend the utility of the item considerably.
quote=Malloon
That does sound worthwhile, though I‘m not sure I know what you mean by „rekey“. I‘m guessing you mean „taking the padlock off“, so I‘ll assume you mean that, because that seems a logical extention of what you‘re proposing. To craft it, I suppose copying how written books are copied would be the optimal method, crafting the original key with one or more iron nuggets.
By 'rekey', I mean to change the key which will open the padlock with the old key becoming invalid.
My thought was that (assuming copies of a key could be made) A & B might each hold a copy of the key with the master key for that chest kept ->somewhere safe<-. If the copy of the key held by either A or B were to be lost or stolen, possesion of the master key would allow new keys to be issued and the old keys to be made invalid.
On reflection, padlocks are cheap enough that adding rekeying functionality is likely not worth the additional complexity it would introduce.
I agree that adapting the book copying code would likely be useful. Under that assumption the master key would be the equivalent of the "Original" written book (crafted as part of the padlock item) and duplicate keys would be equivalent to "Copy of Copy" (to prevent the duplicate keys being copied).
This would extend the utiliy of the item as members of a team {each holding a "Copy of Copy" key} could each access the team conatainers (eg to reload their shared base arrow traps) without passing a key back and forth.
It would also make the padlock item more powerful as one could carry a copied key and keep the master key ->somewhere safe<-. Were one to die such that the copied keys were lost, one could then make new copies of the keys rather than needing to break into one's own containers.
– – – – –
quote=ScotsMiser
WRT unlocking costs:
each slot should be checked for the degree to which it is filled and the sum of these should represent the level cost to 'pick'.
quote=Malloon
There is perhaps a third option, and while it is more complicacted to implement, it‘s perhaps a suitable compromise. You‘d take idea 1), and make sure the maximum number of levels to spend is equal to the amount of slots the inventory of the block you‘re breaking open. So a hopper would need a maximum of 5 levels and a chest would need a maximum of 27. So in both cases two and a half slots filled would equal 2.5 levels, or, because of rounding, three levels to spend. What do you think? It would be easy to understand, I think, which is the main thing.
An example of great minds thinking alike; this option appears to be essentially the system I was attempting to describe.
eg. A chest with a stack of diamonds and 12 eggs would cost 1.75 levels [or 2] to unlock whether the contents were arranged as 1 stack of diamonds + 12/16ths stack eggs + (25x0) OR 1 stack of diamonds + 12x1/16th stack eggs + (13x0).
I'd thought of retaining the fraction and charging a fractional level, but charging a full level for any residual fraction is simpler.
– – – – –
quote=ScotsMiser
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
I've looked back through your posts and I'm still unclear as to whether there are any circumstances under which one would be able to place a double chest (54-slot) [or any other container with >39 slots] on an anvil: the above comment is relevant only if this is possible.
– – – – –
quote=ScotsMiser
WRT double chests; given the new placement mechanics, two half chests (27 slot) can occupy the same space as a double chest (54 slot) so allowing only the 27-slot model to be padlocked would be less of an issue. This would impact using the padlock as a way of moving loaded chest, but would make the interface simpler.
As I read it, one is required to use a padlock on each of the half chests that comprise a double chest. I see no easy way to do this as – for at least an instant – there will be one side padlocked and one side not. This would seem to mean the the game would need to be programmed to allow a window in which to add the second padlock: this window might be subject to undesirable use.
A possible work-around would be to permit only half-chests to be padlocked, but allow two half chests to join IFF both half chest keys (or master keys if the above addition is made) had been created by the same player. [This would seem to require recording player UUID or similar with each padlock and key NBT data; how much complexity that would add is unclear to me.]
quote=Malloon
Well, how I imagined it was that a double chest with one side locked would function exactly like a double chest that hadn't been locked yet. And could stay half-locked indefinitely. It would only become fully locked when the other side was locked too, and be openable again if one side was unlocked. If it was half-locked and the locked half was broken, it would drop a locked chest. Breaking the other side would just break the chest and spill items everywhere.
What do you mean with "undesirable use"? I wouldn't go down the route of storing player-data, though; that would overcomplicate things for players. I suppose I could add a poll asking if people prefer beng able to lock double chests, or only single chests, if we can't clear this up between us.
What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think.
Reading the above exchange and considering it in combination with the following quotes from your OP [numbering mine],
[1] As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama.
The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
[2] My workaround is to let locked containers be broken and picked up
[3] Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
I don't think I understand some of the details of how you intend locked and half-locked double chests to work.
As I currently understand it, half-chests (27-slot) under your proposal would have one of three states:
normal chest [default chest with behavior as at present]
unlocked chest [padlock has been applied, but the chest is unlocked] [I had not fully considered the behavior of this state (and stilll have some questions)]
locked chest [padlock has been applied and the chest is locked]
I read [2] to mean that only a locked chest could be broken and picked up (an unlocked chest would simply break and drop an unlocked chest item and its contents).
Your comment "What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think" suggests to me that you intend any chest with a padlock applied to be able to be picked up with its contents because of [3] (the last part of which implies a way to have a placable unlocked chest [ie with a padlock applied, but in an unlocked state])
The alternative would seem to be that a shared access locked chest could only be created by first placing an empty unlocked chest next to another unlocked chest (either full or empty). [This would not be nearly so useful.]
I am unclear which option you intend.
I see a possible difficulty in that [3] may require the connectedness of a locked chest to be based on its prior state so that unlocking half of a double chest does not cause the still locked half to seperate.
If a thief were to break half of a locked double chest, and place their own unlocked chest next to it [this is the sort of thing I meant by "undesirable use"]– the remaining half of the locked double chest needs to recognize that it should not connect, but if the owner of one half of a shared double chest were to unlock 'his half' the connection should remain.
Stated another way, it seems to me that the locked chest behaviors you wish to implement require that the rules for a half chest connecting be distinct from the rules for it remaining connected. (The new [1.13] placement rules may obviate this concern, but I still think in terms of old [1.12] mechanics.)
Something related about which I am unclear:
When one breaks into a locked container using an anvil, does the base container and its contents drop around the anvil? This would seem to be necessary as one could otherwise remove a full container [without padlock] from the anvil.
In the following quote, your OP seems to use 'unlocked' to mean the container is restored to a normal item of its type without a padlock. ["What happens to a locked block when it is unlocked is simple: It becomes unlocked, nothing else. The padlock is "removed", though there is no "broken padlock" item which the player recieves, so the key becomes useless."]
quote=Malloon
Well, the problem of not wanting to move chests that are in the way but are full of random items that you don't want to sort through is one that [i]most [/i]players experience, I think. The other one, people stealing from you, is one enough other players experience that most public servers have plugins to help prevent it. It's impossible to have additions that everybody will use - some people only play to build with redstone in creative, or to fish; you can't please everybody.
I'm not such what you mean with the performance difficulties and overhead. Do you mean RAM? I hardly think one extra item and one or two new(ish) blockstates/NBT tags will add to that.
I agree about most players finding a (limited) ability to move containers with the contained items would be useful.
Also that thieving is common enough in SMP play that a universal (partial) solution written into vanilla would decrease the need for mods (and increase the commonality of play experience).
WRT prefering to see this as a mod rather than a vanilla addition, I see two types of concerns…
The first of these is ongoing
While I would probably use this aspect of he proposal myself, I am sure there are those who will feel it "breaks MC" [probably based on similar trains of though to those that that precipitate similar reactions to ender chests and shulkers]. Certainly, the utility of the proposal would lessen a 'thing' [ie the annoyance of moving chests of items] that may be considered part of the inventory management/storage organization constraints.
I am unclear how strongly this proposed mitigation would effect overall gameplay and would like the proposal to be given a trial as a mod before becoming vanilla standard.
I also have some concerns about fixing a social problem [thieving] through programming. I have seen a number of MC servers that take the position that, as they have provided a way for one to lock one's chests etc. it is the victim who is to blame if items are stolen from an unlocked chest. I find this attitude sufficiently unpleasant that adding something that might futher it spread to the vanilla game is hard to support. That this proposal actually provides a mechanic that allows stealing (although at some expense) is in its favor. I would nonetheless like to see some 'field-tests' of the ideas in mod form before such are made standard.
My second sort of concern is [hopefully] temporary.
Any additional content will increase the computational demands of a program, and — given that currently 1.13 is effectively unplayable for a number of users due to "performance difficulties" no additions should be made until this critical issue is fixed.
Despite the computational resources required by this suggestion being [likely] but a straw, that argument has apparently been used with far too great a frequency in the rush to release 1.13. [Not to mention longstanding issues with block placement glitches, the lighting engine, and entity glitches on chunk loading.]
Fixing what content has already been added needs [IMO] to be prioritized over further expansion.
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
Edit: Holy broken BBcode Batman! I have no idea what just happened. It should be fixed now, though.
By 'rekey', I mean to change the key which will open the padlock with the old key becoming invalid. My thought was that (assuming copies of a key could be made) A & B might each hold a copy of the key with the master key for that chest kept ->somewhere safe<-. If the copy of the key held by either A or B were to be lost or stolen, possesion of the master key would allow new keys to be issued and the old keys to be made invalid.
On reflection, padlocks are cheap enough that adding rekeying functionality is likely not worth the additional complexity it would introduce.
Ah, now I understand. I agree that would overcomplicate things.
I agree that adapting the book copying code would likely be useful. Under that assumption the master key would be the equivalent of the "Original" written book (crafted as part of the padlock item) and duplicate keys would be equivalent to "Copy of Copy" (to prevent the duplicate keys being copied).
This would extend the utiliy of the item as members of a team {each holding a "Copy of Copy" key} could each access the team conatainers (eg to reload their shared base arrow traps) without passing a key back and forth.
It would also make the padlock item more powerful as one could carry a copied key and keep the master key ->somewhere safe<-. Were one to die such that the copied keys were lost, one could then make new copies of the keys rather than needing to break into one's own containers.
Hm, yes. For my part, I'm sold: that all does seem really useful. But I feel additions should always be incremental, so as not to change the game up too much in one go. I'd consider this part of the second load of additions I'd support.
An example of great minds thinking alike; this option appears to be essentially the system I was attempting to describe.
eg. A chest with a stack of diamonds and 12 eggs would cost 1.75 levels [or 2] to unlock whether the contents were arranged as 1 stack of diamonds + 12[/sup]/16[/sub]ths[/sup] stack eggs + (25x0) OR 1 stack of diamonds + 12x1[/sup]/16[/sub]th[/sup] stack eggs + (13x0).
I'd thought of retaining the fraction and charging a fractional level, but charging a full level for any residual fraction is simpler.
And I completely agree. In hindsight I might actually prefer this way. I'll change it in the OP.
quote=ScotsMiser
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
I've looked back through your posts and I'm still unclear as to whether there are any circumstances under which one would be able to place a double chest (54-slot) [or any other container with >39 slots] on an anvil: the above comment is relevant only if this is possible.
You can't; it shouldn't. I thought I was clear enough, but I'm probably blinded by the curse of knowledge. While I know I should make it clearer, I'm still hoping for a better way to be proposed. I'll clear it up for you down below, though.
Reading the above exchange and considering it in combination with the following quotes from your OP [numbering mine],
[1] As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama.
The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
[2] My workaround is to let locked containers be broken and picked up
[3] Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
To clear things up, I considered a block inventory to be "locked" if the padlock was applied to it. Opening the inventory while you hold the key no more "unlocks" the inventory than, under the current version of minecraft, opening a locked inventory with the correctly named item "unlocks" it. Adding or removing a padlock is analagous to applying the command /data merge block {Lock:""} with either something or nothing between the quotation marks.
I don't think I understand some of the details of how you intend locked and half-locked double chests to work.
As I currently understand it, half-chests (27-slot) under your proposal would have one of three states:
normal chest [default chest with behavior as at present]
unlocked chest [padlock has been applied, but the chest is unlocked] [I had not fully considered the behavior of this state (and stilll have some questions)]
locked chest [padlock has been applied and the chest is locked]
The second state doesn't exist: an invertory is either locked, or unlocked. But chests do have other states that coexist with these:
1. Connected to unlocked chest.
2. Not connected to unlocked chest.
And these as well:
a. Connected to locked chest.
b. Not connected to locked chest.
Bear in mind that "connected" is not the same as "next to".
Due to how the game works, state 1. and a. cannot exist at the same time, but 1. and b., 2. and a. and 2. and b. can. If you combine these three states, you get 8 different possibilities, of which only six are possible:
1) Unlocked, 1., a. - Impossible, irrelevant.
2) Unlocked, 1., b. - Can open; One half of a double chest.
3) Unlocked, 2., a. - Can open; "Unlocked" supercedes all states. The locked chest it is connected to is also openable, because of 6).
4) Unlocked, 2., b. - Can open; A normal chest.
5) Locked, 1., a. - Impossible, irrelevant.
6) Locked, 1., b. - Can open; State 1. supercedes state "locked". A locked chest connected to an unlocked chest can be opened.
7) Locked, 2. a. - Can't open; One half of a locked double chest.
8) Locked, 2., b. - Can't open; A locked chest.
I read [2] to mean that only a locked chest could be broken and picked up (an unlocked chest would simply break and drop an unlocked chest item and its contents).
That is correct.
Your comment "What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think" suggests to me that you intend any chest with a padlock applied to be able to be picked up with its contents because of [3] (the last part of which implies a way to have a placable unlocked chest [ie with a padlock applied, but in an unlocked state])
I did not mean to imply that. The sharing of a chest would not extend to picking them up and placing them again with them automatically connecting.
The alternative would seem to be that a shared access locked chest could only be created by first placing an empty unlocked chest next to another unlocked chest (either full or empty). [This would not be nearly so useful.]
I am unclear which option you intend.
This is what I intended. Not nearly as useful, but far less complicated - the sharing of double chests by way of two players each padlocking one half is a nice extra that results from how this idea works, but isn't a core feature. As such, I don't want to add stuff or change stuff around to better accomodate it.
I see a possible difficulty in that [3] may require the connectedness of a locked chest to be based on its prior state so that unlocking half of a double chest does not cause the still locked half to seperate.
That wouldn't happen because the state of "connectedness" between chests is unrelated to them being locked or not - they're the same chests. A chest being locked does prevent another chest from connecting to it, but more on that below.
If a thief were to break half of a locked double chest, and place their own unlocked chest next to it [this is the sort of thing I meant by "undesirable use"]– the remaining half of the locked double chest needs to recognize that it should not connect, but if the owner of one half of a shared double chest were to unlock 'his half' the connection should remain.
This is exactly what I'm trying to avoid here too, and my solution is just to not let [i]any [/i]chest which is placed connect to a locked chest, or let a locked chest which is placed connect to any other chest. Since this only happens/is determined on placement, locking and unlocking should have no effect on connections.
Stated another way, it seems to me that the locked chest behaviors you wish to implement require that the rules for a half chest connecting be distinct from the rules for it remaining connected. (The new [1.13] placement rules may obviate this concern, but I still think in terms of old [1.12] mechanics.)
Yes, you are correct: chests already connected follow the current rules, while a locked chest being placed or that has a another chest placed next to it prevents connecting entirely due to it being locked. This is similar to if you placed a trapped chest next to a normal chest - they don't connect either.
Something related about which I am unclear:
When one breaks into a locked container using an anvil, does the base container and its contents drop around the anvil? This would seem to be necessary as one could otherwise remove a full container [without padlock] from the anvil.
Thank you for reminding me - I should have stated this. The base container doesn't drop, but the contents does.
In the following quote, your OP seems to use 'unlocked' to mean the container is restored to a normal item of its type without a padlock. ["What happens to a locked block when it is unlocked is simple: It becomes unlocked, nothing else. The padlock is "removed", though there is no "broken padlock" item which the player recieves, so the key becomes useless."]
That's always how I used it.
I agree about most players finding a (limited) ability to move containers with the contained items would be useful.
Also that thieving is common enough in SMP play that a universal (partial) solution written into vanilla would decrease the need for mods (and increase the commonality of play experience).
That's all I need.
While I would probably use this aspect of he proposal myself, I am sure there are those who will feel it "breaks MC" [probably based on similar trains of though to those that that precipitate similar reactions to ender chests and shulkers]. Certainly, the utility of the proposal would lessen a 'thing' [ie the annoyance of moving chests of items] that may be considered part of the inventory management/storage organization constraints.
I am unclear how strongly this proposed mitigation would effect overall gameplay and would like the proposal to be given a trial as a mod before becoming vanilla standard.
There's not much I can say to that except shrugging. The people who believe it "breaks MC" will need to argue in spite of ender chests and shulker boxes, like you said, and for the most part I think they're part of the crowd that will never be happy if something changes. Minecraft has to, to keep the playerbase alive, so I'm not overly concerned with them.
Regarding having it as a mod first, it wouldn't be my first choice, since I think I've thought through all the possibilities and come up quite positive, but because my first choice is direct implementation into the game I'll still welcome it with great enthusiasm. A mod would increase visibility, too, which is a plus.
I also have some concerns about fixing a social problem [thieving] through programming. I have seen a number of MC servers that take the position that, as they have provided a way for one to lock one's chests etc. it is the victim who is to blame if items are stolen from an unlocked chest. I find this attitude sufficiently unpleasant that adding something that might futher it spread to the vanilla game is hard to support. That this proposal actually provides a mechanic that allows stealing (although at some expense) is in its favor. I would nonetheless like to see some 'field-tests' of the ideas in mod form before such are made standard.
-.- I had a whole paragraph written here that's been consumed by corrupted BBcode. Boiling down what I said: I don't know how how much this will affect this, but public servers can try and curb bad behaviour with laws enforced by moderators, or with extra security tools given to players. Good moderators are worth their weight in gold, though, and are as such hard to come by, and some servers may decide not to ban stealing in favour of just giving the players tools to prevent it. While my suggestion may make giving the tools to players easier, I'm fairly certain servers whose moderators and admins are too overworked or lazy would just have used plugins anyway, and their enforcement of any stealing laws would be less than commendable anyway.
My idea does make the [i]gameplay feature [/i]of stealing, as I consider it, less frustrating, because it makes it easy for players to make it harder for thieves.
My second sort of concern is [hopefully] temporary.
Any additional content will increase the computational demands of a program, and — given that currently 1.13 is effectively unplayable for a number of users due to "performance difficulties" no additions should be made until this critical issue is fixed.
Despite the computational resources required by this suggestion being [likely] but a straw, that argument has apparently been used with far too great a frequency in the rush to release 1.13. [Not to mention longstanding issues with block placement glitches, the lighting engine, and entity glitches on chunk loading.]
Fixing what content has already been added needs [IMO] to be prioritized over further expansion.
Agreed, but that's such a deepseated issue that it shouldn't really be relevant to my suggestion, but rather to suggestions as a whole. Keep mentioning it, so people are aware, but please support or not support individual suggestions without regard to this, otherwise support/no support becomes useless in discerning how well suggestions are recieved.
_ _ _ _ _ _ _ _ _ _ _ _ _
Regarding datapacks - I looked into them and it doesn't seem like adding this would be possible using them.
quote=Malloon"
To clear things up, I considered a block inventory to be "locked" if the padlock was applied to it. Opening the inventory while you hold the key no more "unlocks" the inventory than, under the current version of minecraft, opening a locked inventory with the correctly named item "unlocks" it. Adding or removing a padlock is analagous to applying the command /data merge block {Lock:""} with either something or nothing between the quotation marks."
I think this is the crux of what I was not missing.
As I read the above paragraph, a chest/container would either have a padlock applied [locked] or not [normal or unlocked].
Accessing the inventory using a key would not change that state, meaning there is no way to have a chest with a padlock applied but the inventory openly accessible.
[I had thought a key holder could exit the inventory leaving the chest in a state where a non-keyholder could access the inventory, but leaving the padlock in place.]
Reading back I found this "The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it." I had taken that to mean than access without unlocking was an option, not a requirement.
Clarifying that using a key to access the inventory of a container automatically leaves it in a locked state and that padlock removal is a distinct action might help avoid confusion. [I was thinking of a padlocked chest as being like a locking door (eg the exterior door to a house) can be unlocked then opened and closed and arbitrary number of times before being relocked vs a normal chest (which whould be analogous to the usual interior doors which do not have locks).]
If my new interpretation is correct, it does simplify matters and obviates a number of the concerns I had raised.
I can't find an explicit mention on rereading, but can a keyholder remove a padlock?
This would mean keys perform two distinct functions:
access – which does not affect the locked/unlocked state, and
unlocking – which removes the padlock (& returns the item to the player? ) [Would unlocking/removing a padlock automatically access the inventory, or would that be a separate action?]
RE doing it first as a mod. I'm rather conservative about change and I remain convinced some thousands (or tens of thousands) of users playing with (and trying to exploit) an idea from some months are more likely to find any corner cases needing modification than armchair analysis. [It also strikes me as 'politically' far easier to change something in a mod than in vanilla.]
Assuming no damning problems are found, this is something I'd eventually like to see added. [Assuming the 1.13.performance issues can be fixed… which is likely to be done by third parties (ie optifine) even if MS/Mj doens't do the job as they ought. Waiting on this remains, however, extremely irritating. ]
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
quote=Malloon"
To clear things up, I considered a block inventory to be "locked" if the padlock was applied to it. Opening the inventory while you hold the key no more "unlocks" the inventory than, under the current version of minecraft, opening a locked inventory with the correctly named item "unlocks" it. Adding or removing a padlock is analagous to applying the command /data merge block {Lock:""} with either something or nothing between the quotation marks."
I think this is the crux of what I was not missing.
As I read the above paragraph, a chest/container would either have a padlock applied [locked] or not [normal or unlocked].
Accessing the inventory using a key would not change that state, meaning there is no way to have a chest with a padlock applied but the inventory openly accessible.
Correct! You either have to remove the padlock or loan the person the key.
[I had thought a key holder could exit the inventory leaving the chest in a state where a non-keyholder could access the inventory, but leaving the padlock in place.
Yes, that wouldn't be possible.
Reading back I found this "The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it." I had taken that to mean than access without unlocking was an option, not a requirement.
Clarifying that using a key to access the inventory of a container automatically leaves it in a locked state and that padlock removal is a distinct action might help avoid confusion. [I was thinking of a padlocked chest as being like a locking door (eg the exterior door to a house) can be unlocked then opened and closed and arbitrary number of times before being relocked vs a normal chest (which whould be analogous to the usual interior doors which do not have locks).]
Ah, I see where the confusion came from. Yes, I will clarify that.
If my new interpretation is correct, it does simplify matters and obviates a number of the concerns I had raised.
It definitely seems to be.
I can't find an explicit mention on rereading, but can a keyholder remove a padlock?
Yes. (Assuming the idea of a masterkey/copies of that key is added, only the masterkey would be able to).
This would mean keys perform two distinct functions:
access – which does not affect the locked/unlocked state, and
unlocking – which removes the padlock (& returns the item to the player? ) [Would unlocking/removing a padlock automatically access the inventory, or would that be a separate action?]
Exactly! Thank you for posing these questions! It's made me realise I should have been clearer. "Access" is exactly as you describe. "Unlocking" is also right, almost - it would remove the padlock and turn the key used to do so back into a padlock and key ("giving" the padlock back), but it wouldn't access the inventory. That would be a seperate action.
RE doing it first as a mod. I'm rather conservative about change and I remain convinced some thousands (or tens of thousands) of users playing with (and trying to exploit) an idea from some months are more likely to find any corner cases needing modification than armchair analysis. [It also strikes me as 'politically' far easier to change something in a mod than in vanilla.]
That strikes me as a very fair assessment.
Assuming no damning problems are found, this is something I'd eventually like to see added. [Assuming the 1.13.performance issues can be fixed… which is likely to be done by third parties (ie optifine) even if MS/Mj doens't do the job as they ought. Waiting on this remains, however, extremely irritating. ]
Padlocks and Keys: Locking and Moving Blocks with Inventories
Since the introduction of chests, there have been two constant problems in Minecraft: Thieving players and chests full of random items you don't want to move. To help with both these problems, I have a few connected suggestions, which are listed below. (For the purposes of this suggestion a block or a block's inventory being "locked" means a padlock has been applied to it, not that the inventory is necessarily completely inaccessible.)
Part 1: The Basics
1) Adding padlocks and keys for locking blocks with inventories.
2) You use the padlock and key on a block with an inventory by shift-right-clicking with a padlock, locking the inventory and giving you just the key.
3) Players without the key, droppers, and hoppers then can't access the inventory until you unlock it again by shift-right-clicking on the block with the same key, giving you the padlock and key back. You don't open the inventory this way. You can still open the inventory by holding the key in your hand and right-clicking normally without unlocking it.
4) You can break a locked block like any other block, but it doesn't drop its contents.
5) You can pick up this block and place it elsewhere, with the inventory still inside. But you can only hold it in your off-hand slot and can't place it in any other inventory.
6) Double chests need to be locked on both sides in order to stop people opening them. Locked chests won't connect to any chests they are placed next to, or which are placed beside them.
7) Locked blocks can be broken open by placing them in an anvil and paying an amount of xp levels depending on how filled the inventory is, similar to how comparators calculate their output, with the percentages of how full each slot is added up used to calculate the levels needed.
The basic idea to this isn't new, but it has always been plagued with problems, to which the solutions have always been complex, unintuitive and inelegant. When conceiving this idea I swore to make solutions that were none of those. I think I have succeeded, but judge for yourselves.
One thing to note, however, is that while I set out to help with the above problems, I don't simply want to solve them. Protecting your items from other players and cleaning up are part of the game, I feel, but the methods available are often time-consuming, frustrating and impractical for the day-to-day routine.
As you might know, Minecraft already has a locking mechanic, but only in the commands. I tried to keep my suggestion as similar to this mechanic as possible, as this would aid in keeping it simple, but some things were changed because they would have made things more complex or unworkable if I had kept them. I am not, however, suggesting this command be removed - my suggestion and this command can easily work side-by-side.
For those who are interested I'll now explain each point in more detail and explain the thought-processes behind them.
1) Padlocks
Why padlocks? Well, because, as a new feature, I decided the simplest way to add it was as an extra item, instead of overhauling the GUIs of each storage block. This, and to make locking an investment (however small). It also gives an easy way to link locked inventories to their keys and makes them reusable.
Though all of these things might apply if I had just suggested a key, having just a key would mean running into problems regarding explaining why different keys fit the same container, but the container could only be unlocked using the key it was locked with, and would circumnavigate the cost of locking a block because you could use the same key multiple times (it's either that or limiting the key to locking only one block, in which case the function would be exactly the same as the padlock and key, but you couldn't tell which key had been used already). The cost for locking each block is important, I feel, because having locking containers should be an investment, not a standard thing everybody always does.
You craft a padlock with two iron nuggets and an iron ingot, as shown here:
2) Locking an Inventory
As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama. The padlock and key item then changes into a key item:
This change is similar to the change when you right-click with a map. However, unlike with a map, the new item is only ever called "Key". The link to the block is stored as NBT data. While the lock mechanic through commands uses renamed items in hand to let the player open locked inventories, implementing this into my suggestion would have been difficult or make little intuitive sense, since then the keys would always need to be renamed, either through randomisation, in which case you couldn't rename it again yourself to your liking (such as "Bedroom Chest Key" or "Enderpearl Dispenser Key"), the renaming would need to happen upon either crafting or applying the padlock and key (a task I would prefer to leave in the proverbial hands of the anvil, the ownership of which shouldn't be necessary for using padlocks and keys) or any not-renamed key would fit any not-renamed padlock-on-an-inventory, as well as any item renamed "Key", which would defeat the purpose of the entire operation (and preventing this would require an anvil, with the same problems as before). The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
One important part to this is that if you do rename a padlock and key or a key, if you lock or unlock an inventory with it, the name remains the same.
3) Inaccessability of Inventories
I tried to limit the impact of this suggestion to just what it set out to do, to make sure it didn't infringe on other mechanics too much and become less useful. As such, while players, hoppers and droppers can't access the inventory (the latter two since otherwise other players could still mess with the inventory of locked blocks outside of how the player who locked it intended them to), the function of the block outside of that should stay the same. Dispensers should still dispense items, shoot arrows and potions and put on armour, hoppers should still push and pull items in and out of other (unlocked) inventories, and furnaces should still smelt. This means that players can't disable arrow traps by stealing the arrows, for one thing.
Regarding hoppers, this could mess with some complex redstone circuits that rely on items being pulled out of one hopper while that hopper tries to push the same item into a different inventory than the hopper that is pulling (people who care will understand that). In that case I'd suggest just not locking the top hopper. There is no workaround I can think of that is simple enough not to require a GUI of sorts, unfortunately.
4) Breaking a Locked Container
In order to prevent thieves from simply busting open a locked container, something that is far easier in Minecraft than in real life, either the container needs to be made unbreakable (or simply a lot harder to break), which allows for easy griefing by placing locked containers everywhere in someone's base, or it needs to drop without dropping the contents, something for which the shulker boxes were invented and which would be, frankly, overpowered and make shulker boxes useless. Between the pressure of this dichotomy is where these types of suggestions often break. But I think I've found an intuitive workaround: See the next section.
5) Only Holding it in your Off-hand
My workaround is to let locked containers be broken and picked up, which also lets you more easily rearrange and remove chests that are in the way without making you worry about removing and rehousing the contents.
But you can only pick it up (!) in your off-hand, and you can't place it in your or any other inventory. Think of it as jamming it under your left (or right, for you lefties) arm. This has a number of uses:
1) You can only pick up one at a time, which along with not being able to store them in other inventories helps prevent shulker boxes from becoming useless.
2) Your actions are limited until you put it down, since the off-hand right-click replaces the left hand one until the off-hand is emptied. So no torches or block-placing for you until you put it down (though you can still use buttons and such).
3) Thieves can only make off with one storage block at a time. This also means vandals need to work harder when destroying entire storage rooms, either letting each chest despawn or having to dispose of each chest one by one. This one is more in your favour.
Despite all this, if this is implemented I am positive locked chests will be used like backpacks, but this is ok, I think, because all other options for with-player item transport such as mules/donkeys, shulker boxes and ender chests are in many ways superior to carrying a locked chest around, so won't be skipped in favour of this.
One thing to note is that you can lock shulker boxes, and locking them doesn't override the fact they can be stored in any inventory slot (besides other shulker boxes). Because anything else would be silly.
Currently, this part of the suggestion is compromised because of a bug. https://bugs.mojang.com/browse/MC-84849?jql=project = MC AND text ~ offhand This should be able to be resolved, though.
6) Locked Double Chests
I thought a great deal about how to lock double chests. Before I talk about what I decided on, let me list all the ways of solving this problem I dismissed:
1) You can't have one side locked and the other unlocked.
2) You can't have the padlock split between the chests if you break one. How on earth would that work?
3) You can't have the padlock stay on the half that isn't broken, while the other half breaks and spills its contents, or vice versa have the padlock stay on the broken half while unlocking the other half.
4) You can't have the entire chest drop as a new type of double-block/item, since that would over-complicate things dramatically (having an entirely new type of item/block, having a new mechanic to place a two block wide object).
5) You can't have the double chest be broken entirely and having it split up into two items, for the reasons for rejecting or 2) or 4).
6) You can't have the padlock just drop or break when the chest is broken, because, duh.
What I settled on was admittedly a little unsatisfactory, but the only way I could think of bar stopping double chests being lockable at all.
In order to lock a double chest, therefore, you need to padlock one half and then the other before the inventory is inaccessible. Before this, the half you padlocked is considered "locked", and will drop as a locked chest when broken, but remains accessible as long as the chest it is connected to is unlocked. Only when the other half is locked does the double chest say "chest is locked". If only one half of a double chest is locked and the unlocked half is broken, the half that is locked and hasn't been broken becomes inaccessible.
If one half of a completely locked double chest is unlocked, the inventory becomes accessible again, even though the other half is still considered "locked".
If one half of a completely locked double chest is broken, that half drops as a locked chest, while the other half stays both put and locked.
Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
While this is the only part of my suggestion that seems unrealistic and forces you to use two padlocks and keys, I decided that it was either that or not make double chests lockable at all, which wouldn't be satisfactory either, so I went with the route that didn't limit the player's freedom ingame.
7) Breaking Locks
I decided on letting players break open locked containers for two reasons: Keys can be lost, so making entire inventories completely inaccessible might be excessively frustrating, and stealing is fun, as long as not every random schmuck with a pickaxe can do it. Rogues who plan out heists and know exactly what chest to make off with shouldn't be completely thwarted, as long as they are prepared to sacrifice some xp levels (read: time) to do it. Base protection should be for thieves as well as vandals, and, while padlocks and keys can help against greed, I don't think they should be the be all end all.
What happens to a locked block when it is unlocked is simple: It becomes unlocked, nothing else. The padlock is "removed", though there is no "broken padlock" item which the player recieves, so the key becomes useless. You receive the newly unlocked block in the rightmost slot of the anvil, while any items that were in its inventory drop to the ground around you.
I decided on the anvil because what better place to literally break a lock and what better to force a player to sacrifice than levels? Levels are relatively costly, can scale, can be spent and are already somewhat abstract with no basis in reality. Any item wouldn't scale, or make sense (you wouldn't need more lockpicks to open a full chest than for an empty one, for example, and if you did, why?), and a tool could never be expensive enough and make some modicum of sense.
Through back and forth with ScotsMiser I decided on copying a system already in the game in order to calculate the amount of levels a player would need to spend, namely, the way comparators calculate their redstone output. This was to approximate the xp cost to how valuable the inventory might be, and make sure chests full of (possibly enchanted) tools were not cheaper to open than chests full of dirt. While the system is a little complicated in how it calculates the amount, all this calculation is done by the game, and players needn't be confronted with it - only with the end result, which is why I deemed it a good idea.
How this system works is follows: The amount of xp levels a player needs to pay to open a block's inventory is determined by calculating to what percentage each slot of that inventory is filled, adding these percentages up, then rounding up to the next xp level.
A couple of examples:
1) A hopper has one slot filled with 64 blocks of cobblestone. 64 is the maximum amount blocks of cobblestone stack up to, so it is a full stack, 100% filled, or 1 stack. The rest of the slots are empty, so have 0 stacks. Since a hopper has five slots, it calculates 1 + 0 + 0 + 0 + 0 = 1 xp level. You need to pay 1 xp level to break open the hopper.
2) A hopper has one slot filled with 64 blocks of cobblestone (1 stack), one slot filled with 16 eggs and one slot with a hoe. The eggs only stack up to 16, so it is also a full stack (1 stack), and the hoe doesn't stack, so it also counts as 1 stack. The other two slots are empty (0 stacks). To break open this hopper you need 1 + 1 + 1 + 0 + 0 = 3 xp levels.
3) A hopper has one slot filled with 64 cobblestone (1 stack) and one slot filled with 32 cobblestone (50% filled, or 0.5 stacks). The rest of the five slots are empty (0 stacks). The xp levels are first calculated by adding 1 + 0.5 + 0 + 0 + 0 = 1.5, which is then rounded up to 2 xp levels.
4) A hopper has one slot filled with 64 cobblestone (1 stack), one slot filled with 4 eggs (25% of a stack, or 0.25 stacks) and one slot with a hoe (1 stack). The rest of the slots are empty (0 stacks). You calculate 1 + 0.25 + 1 + 0 + 0 = 2.25, which is then rounded up to 3 xp levels you would need to pay.
The maximum amount that it is possible to pay with this system is 27 xp levels, when breaking open a chest or shulker box.
This part of the suggestion is as of now not possible, because the offhand doesn't show up when accessing blocks such as anvils. This would need to be tweaked, and the suggestion for it is here: https://www.minecraftforum.net/forums/minecraft-java-edition/suggestions/48925-small-suggestions?page=666#c13908
This was part 1 of my suggestion. Part 2 will cover all the features that could be added in addition to the above, but are not part of the core suggestion.
Part 2: Everything Else
Locking doors
Being able to lock doors (and trapdoors, and fence gates) is the natural thing to think of after being able to lock chests and inventories, however, there is less reason for it to exist than the above - after all, the schmuck with a (pick)axe can just tunnel through or around. That said, there are still a number of ideas why I think locking doors (as in, not being able to move the door from one state to the other without the key) is still a good feature to implement:
1) It would work well for adventure maps in adventure mode, since then the schmuck actually needs a pickaxe, and might not have one. Actually having a key item removes the hassle for mapmakers to program something that would be bog-standard in most adventure games.
2) You could control villagers more easily, without having to block doors with blocks. For the aesthetically minded dict- I mean, caretaker.
3) Being able to lock iron doors and trapdoors in an open or closed position gives builders more options - this would mean locking a door, trapdoor or fence gate would stop redstone opening it.
4) If nothing else, it might give you a few extra seconds to prevent someone entering... somewhere.
Locking Mobile Inventories
The next natural thing to think of after locking door is locking all the mobile inventories on minecarts and animals. This would work exactly like locking block-inventories: Shift-right-click on the minecart or animal with the padlock to lock the inventory, right-click with the key in hand to open the inventory and shift-right-click again to unlock the inventory. Killing the animal or destroying the minecart drops the still locked inventory block (chest or dispenser).
The only thing that would deviate from this is the furnace minecart. Since it doesn't technically have an inventory you can access I would be fine with just excluding it fro this suggestion, but you could technically lock it to prevent coal being added. I don't know why anyone would want that, but hey, might as well strive for completion. (Note: I don't actually want this. I just don't want to redo the image I made above.)
Keyrings
Now come the suggestions with are to do with extra convenience. You might have noticed that, since every key takes up on slot of your inventory, you wouldn't want to lock very many inventories (or doors, trapdoors and fence gates). I noticed this too. Aren't we are smart bunch of people? But I have thought of a solution: Keyrings!
Keyrings are for keys what sand and ball-pits are for kids: Places/things you can put them so you can go off and enjoy the finer things in life. (Disclaimer: Please don't abandon your kids.) Keyrings let you combine multiple keys (and their NBT data) into one item. There's no upper limit to the amount of keys you can put on it.
Keyrings are crafted using four iron nuggets, like so:
Keys are then added to it by crafting them together with the keyring:
Right-clicking on the inventory (or door, trapdoor or fence gate) with the keyring will open that inventory (or door, trap- I'll stop) as long as the key that locked that... object is on the keyring. Shift-right-clicking removes the padlock from the object and the key from the keyring, placing the combined item in another slot of your inventory. This is also the only way of removing specific keys from the keyring - no other method besides a GUI would let you specify what key to remove.
The other method of removing keys would be doing so one by one, in a crafting grid. Keys would be removed in the order they were put on the keyring, or depending on where they were on the list of keys in the NBT data:
Since every key would retain its NBT value, it would also keep the name it had, if it had been named in an anvil.
Copying keys
The second suggestion to do with convenience would be being able to make copies of keys. Just like with maps and with books, keys are things that might benefit from having copies made. From having multiple keys in case you lose one, to communal chests (or giving your friends the ability to access your chests).
As the above image shows, copying keys would be similar to how maps and books are copied. You craft your key with one to eight iron nuggets, and one to eight keys are created while the original is returned to your inventory. This can also be done using the padlock.
These copies are all named "Copy of Key", with "Key" being replaced by the name if you had renamed it. Instead of as with books, however, this can only be done with the original - none of the copies can be crafted with iron nuggets. This limits the damage that can be done by rogue copies.
What's interesting about the copies is that they can't be used to unlock stuff. You can use them to open the things their originals have locked, but shift-right-clicking with them on the locked object is no different from right-clicking. This fact means you can feel safer giving your friends these keys, and means you might want to carry around a copy of a key instead of the original, in case you die and lose it.
Keyrings would accept copies of keys, though the only way to remove them would be to painstakingly uncraft them. You could technically add multiple copies as well as the original to a keyring, but this wouldn't change its function.
This was my suggestion. Feel free to critique it! (Not that I could stop you.) And feel free to suggest additions or changes of your own.
Changelog:
05.09.18 Explicitely stated the fact you can open locked blocks with the key in hand without removing the lock.
06.09.18 Added changelog.
06.09.18 Added the problems with the current offhand.
11.09.18 Changed how to calculate how many xp levels are necessary to break open locked inventories on an anvil. Cleared up confusion on other parts.
26.02.19 Added multiple possible additions to the core idea.
While I was expecting the worst going in, I am happy to say this is well thought out to almost every detail! A vanilla locking system would greatly improve storage and security (not to mention, your system is better than the plugins I've experienced) and it would be amazing to move around chests without the items dropping.
Full Support.
A detailed suggestion that provides high-quality workarounds for most problems with this type of suggestion. Support.
I'm a Whovian squid who likes drawing.
I'm also quite nerdy with an interest in game developing and the concept of a fourth spatial dimension.
All hail chickens.
Wow! What a neat idea. I think it is implementable in 1.13 using datapack.
FULL SUPPORT
I'm a programmer. I use C/C++, BASIC, Assembly, and Python. If i sound too technicial, that's because it's the way i think.
My Suggestions
Thank you so much for your support and feedback! I'm glad my work payed off.
Despite me harping on about mirroring the lock using commands, I forgot to explicitly mention I would keep its most distinguishing feature: Opening the container using right-click when holding the key without unlocking it. I've explicitly mentioned it now.
It does have aspects of both, if used in that way, though I'm sure I'd prefer either to having to carry a locked chest around. It's too unwieldy for anything else. It's not even practical for caving, since you couldn't place torches, unless you were prepared to throw it down every time. Unless you put it down in a temporary base, then filled it up and took it with you afterwards...
Hm. Well, it certainly helps. I can't really say if it would make things too easy. What would be too easy? I'd say making the experience less engaging by making it less challenging, and not replacing that by adding other challenges, and the system does offer those. I'm not sure how to test this without actually testing it by playing.
Thanks for pointing that out. I didn't know that. In fact, I might almost consider it an oversight, a bug. I'll have a look on the bug tracker and maybe report it.
Interesting. I might have a go at that.
-
View User Profile
-
View Posts
-
Send Message
ModeratorNot necessarily. Being able to access your entire inventory in a crafting or storage block is a benefit by itself, even if padlocks were never implemented. You can't access the offhand slot on chests (any kind), furnaces, crafting benches, or enchanting tables, which is inconvenient, albeit only slightly so. So saying that the only benefit to fixing that is this idea would work is disingenuous.
As for the idea as a whole, I like it. I don't typically play MC online so it won't effect me but it seems like a good idea.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Well thought-out and well presented.
There are some additions/changes I think might be worthwhile:
duplicate and master keys: the ability to make duplicate keys, preferably with a distinction between duplicate and master keys– and with the ability of the holder of the master to 'rekey' the lock.
I suspect this would require recording the player ID number [or equivalent] in the NBT data for each padlock, but would extend the utility of the item considerably.
WRT unlocking costs:
As presented a 54-slot chest with 'some' diamonds and 53 seeds could cost between 2 and 54 levels to 'pick' using an anvil (2&27 levels if only half chests are considered).
The following involves quite a bit more calculations, but these would only need to be done when a chest is 'picked' on an anvil (a comparatively uncommon event one should think):
each slot should be checked for the degree to which it is filled and the sum of these should represent the level cost to 'pick'
16 eggs in one slot and 16 eggs spread across 16 slots would thus incure the same cost.
This would require more effort by the owner to impose a maximal cost, but would avoid padlocked chest "always" costing 27 or 54 levels to open. [Keeping my_cool_stuff plus a stack of seeds/cobble in a chest would make imposing maximal 'picking' cost trivial.]
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
WRT double chests; given the new placement mechanics, two half chests (27 slot) can occupy the same space as a double chest (54 slot) so allowing only the 27-slot model to be padlocked would be less of an issue. This would impact using the padlock as a way of moving loaded chest, but would make the interface simpler.
As I read it, one is required to use a padlock on each of the half chests that comprise a double chest. I see no easy way to do this as – for at least an instant – there will be one side padlocked and one side not. This would seem to mean the the game would need to be programmed to allow a window in which to add the second padlock: this window might be subject to undesirable use.
A possible work-around would be to permit only half-chests to be padlocked, but allow two half chests to join IFF both half chest keys (or master keys if the above addition is made) had been created by the same player. [This would seem to require recording player UUID or similar with each padlock and key NBT data; how much complexity that would add is unclear to me.]
While I like the ideas presented (with or without the suggested changes/additions), the proposal as a whole strikes me as solving an issue some players experience. As such, I would prefer this to be available as a mod [& it is most unfortunate that MS/Mj has not seen fit to modularize a numvber of their additions] than written into vanilla. My assupmtion is that the extensions of the game proposed here would entail at least some overhead, which the current performance difficulties strongly advise against.
Badprenup answered more or less how I would have, so I won‘t repeat what they said. I‘m just going to state what I found in the bug tracker. As of now, it seems like the offhand slot not being accessable in any inventories is intended, as an extension of the armour slots not being accessable either. https://bugs.mojang.com/browse/MC-84410?jql=text%20~%20%22offhand%20horse%22
However, I agree with Badprenup that there‘s no reason it couldn‘t be accessable, especially as it functions almost exactly like an inventory slot anyway, except for the fact that items on the ground aren’t picked up by the offhand. That‘s also important for this, but has been confirmed as a bug. https://bugs.mojang.com/browse/MC-84849?jql=project%20%3D%20MC%20AND%20text%20~%20offhand
What I‘m going to do is make a small suggestion and link to this one and back.
Thank you!
My thanks! You‘ve put quite some thought into possible additions, which means my idea stirred you creatively, which is a nice compliment.
That does sound worthwhile, though I‘m not sure I know what you mean by „rekey“. I‘m guessing you mean „taking the padlock off“, so I‘ll assume you mean that, because that seems a logical extention of what you‘re proposing. To craft it, I suppose copying how written books are copied would be the optimal method, crafting the original key with one or more iron nuggets.
If this suggestion is ever implemented, you can be sure I‘d add this to the possible additions suggestion. Or maybe even now - I‘m hankering to make an extra thread for all the possible but not necessary additions to this suggestion.
You‘re talking about a system similar to how comparators calculate their output. I thought of doing that too, but the reason I decided against it is because either 1) you‘d need to assign a maximum amount of levels that can be spent (just like redstone travels a maximum of 15 blocks; 30 levels spring to mind), of which the percentage that needs to be paid is calculated as being equal to the percentage of how full the inventory is, or 2) you’d need to assign an amount of levels to each filled slot, with the percentage of how much the slot is filled being equal to the percentage of the amount of levels the slot is worth.
For example, if you‘d take suggestion 1), a chest with two slots filled and one slot half-full (with 32 stone or 8 eggs) would cost (2.5/27)*30 = 2.77777777.... (2.5 slots filled, 27 maximum slots, 30 maximum levels) or, rounding up, 3 levels to open. A hopper with the sme amount of slots filled, however, would cost (2.5/5)*30 = 15 levels to open; this despite the items and the amount of items being the same. This discrepency is fine with comparators, who only want to figure out how full the inventory is, but with padlocks I really think either the actual amount of items, or at least the amount of different items/slots should define the cost.
In which case you might say to take idea 2) instead, however, in that case you‘d need to assign at least 2 levels per slot (any lower and it would be the alternative I decided on, and would ignore percentages) which would make a chest with every slot filled more than halfway cost a whopping 2*27 = 54 levels to open. (2 levels per slot, 27 maximum slots.) That‘s too much for one chest, since each additional level takes more xp than the last to reach. Having to pay 27 levels twice would be trivial compared to having to pay 54 levels at once.
There is perhaps a third option, and while it is more complicacted to implement, it‘s perhaps a suitable compromise. You‘d take idea 1), and make sure the maximum number of levels to spend is equal to the amount of slots the inventory of the block you‘re breaking open. So a hopper would need a maximum of 5 levels and a chest would need a maximum of 27. So in both cases two and a half slots filled would equal 2.5 levels, or, because of rounding, three levels to spend. What do you think? It would be easy to understand, I think, which is the main thing.
Well, how I imagined it was that a double chest with one side locked would function exactly like a double chest that hadn't been locked yet. And could stay half-locked indefinitely. It would only become fully locked when the other side was locked too, and be openable again if one side was unlocked. If it was half-locked and the locked half was broken, it would drop a locked chest. Breaking the other side would just break the chest and spill items everywhere.
What do you mean with "undesirable use"? I wouldn't go down the route of storing player-data, though; that would overcomplicate things for players. I suppose I could add a poll asking if people prefer beng able to lock double chests, or only single chests, if we can't clear this up between us.
What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think.
Well, the problem of not wanting to move chests that are in the way but are full of random items that you don't want to sort through is one that most players experience, I think. The other one, people stealing from you, is one enough other players experience that most public servers have plugins to help prevent it. It's impossible to have additions that everybody will use - some people only play to build with redstone in creative, or to fish; you can't please everybody.
I'm not such what you mean with the performance difficulties and overhead. Do you mean RAM? I hardly think one extra item and one or two new(ish) blockstates/NBT tags will add to that.
Thank you for your input. You've given me a lot to think about.
quote=ScotsMiser
duplicate and master keys: the ability to make duplicate keys, preferably with a distinction between duplicate and master keys– and with the ability of the holder of the master to 'rekey' the lock.
I suspect this would require recording the player ID number [or equivalent] in the NBT data for each padlock, but would extend the utility of the item considerably.
quote=Malloon
That does sound worthwhile, though I‘m not sure I know what you mean by „rekey“. I‘m guessing you mean „taking the padlock off“, so I‘ll assume you mean that, because that seems a logical extention of what you‘re proposing. To craft it, I suppose copying how written books are copied would be the optimal method, crafting the original key with one or more iron nuggets.
By 'rekey', I mean to change the key which will open the padlock with the old key becoming invalid.
My thought was that (assuming copies of a key could be made) A & B might each hold a copy of the key with the master key for that chest kept ->somewhere safe<-. If the copy of the key held by either A or B were to be lost or stolen, possesion of the master key would allow new keys to be issued and the old keys to be made invalid.
On reflection, padlocks are cheap enough that adding rekeying functionality is likely not worth the additional complexity it would introduce.
I agree that adapting the book copying code would likely be useful. Under that assumption the master key would be the equivalent of the "Original" written book (crafted as part of the padlock item) and duplicate keys would be equivalent to "Copy of Copy" (to prevent the duplicate keys being copied).
This would extend the utiliy of the item as members of a team {each holding a "Copy of Copy" key} could each access the team conatainers (eg to reload their shared base arrow traps) without passing a key back and forth.
It would also make the padlock item more powerful as one could carry a copied key and keep the master key ->somewhere safe<-. Were one to die such that the copied keys were lost, one could then make new copies of the keys rather than needing to break into one's own containers.
quote=ScotsMiser
WRT unlocking costs:
each slot should be checked for the degree to which it is filled and the sum of these should represent the level cost to 'pick'.
quote=Malloon
There is perhaps a third option, and while it is more complicacted to implement, it‘s perhaps a suitable compromise. You‘d take idea 1), and make sure the maximum number of levels to spend is equal to the amount of slots the inventory of the block you‘re breaking open. So a hopper would need a maximum of 5 levels and a chest would need a maximum of 27. So in both cases two and a half slots filled would equal 2.5 levels, or, because of rounding, three levels to spend. What do you think? It would be easy to understand, I think, which is the main thing.
An example of great minds thinking alike; this option appears to be essentially the system I was attempting to describe.
I'd thought of retaining the fraction and charging a fractional level, but charging a full level for any residual fraction is simpler.
quote=ScotsMiser
There MAY also be an issue with anvils and double chests with 'pick' costs of >39 levels: there would need to be some rework of the anvil mechanics could in any case, so this may be fairly simple to avoid.
I've looked back through your posts and I'm still unclear as to whether there are any circumstances under which one would be able to place a double chest (54-slot) [or any other container with >39 slots] on an anvil: the above comment is relevant only if this is possible.
quote=ScotsMiser
WRT double chests; given the new placement mechanics, two half chests (27 slot) can occupy the same space as a double chest (54 slot) so allowing only the 27-slot model to be padlocked would be less of an issue. This would impact using the padlock as a way of moving loaded chest, but would make the interface simpler.
As I read it, one is required to use a padlock on each of the half chests that comprise a double chest. I see no easy way to do this as – for at least an instant – there will be one side padlocked and one side not. This would seem to mean the the game would need to be programmed to allow a window in which to add the second padlock: this window might be subject to undesirable use.
A possible work-around would be to permit only half-chests to be padlocked, but allow two half chests to join IFF both half chest keys (or master keys if the above addition is made) had been created by the same player. [This would seem to require recording player UUID or similar with each padlock and key NBT data; how much complexity that would add is unclear to me.]
quote=Malloon
Well, how I imagined it was that a double chest with one side locked would function exactly like a double chest that hadn't been locked yet. And could stay half-locked indefinitely. It would only become fully locked when the other side was locked too, and be openable again if one side was unlocked. If it was half-locked and the locked half was broken, it would drop a locked chest. Breaking the other side would just break the chest and spill items everywhere.
What do you mean with "undesirable use"? I wouldn't go down the route of storing player-data, though; that would overcomplicate things for players. I suppose I could add a poll asking if people prefer beng able to lock double chests, or only single chests, if we can't clear this up between us.
What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think.
Reading the above exchange and considering it in combination with the following quotes from your OP [numbering mine],
[1] As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama.
The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
[2] My workaround is to let locked containers be broken and picked up
[3] Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
I don't think I understand some of the details of how you intend locked and half-locked double chests to work.
As I currently understand it, half-chests (27-slot) under your proposal would have one of three states:
I read [2] to mean that only a locked chest could be broken and picked up (an unlocked chest would simply break and drop an unlocked chest item and its contents).
Your comment "What locking double chest does allow is for two players could lock a double-chest together that both of them could access, which is nice, I think" suggests to me that you intend any chest with a padlock applied to be able to be picked up with its contents because of [3] (the last part of which implies a way to have a placable unlocked chest [ie with a padlock applied, but in an unlocked state])
The alternative would seem to be that a shared access locked chest could only be created by first placing an empty unlocked chest next to another unlocked chest (either full or empty). [This would not be nearly so useful.]
I am unclear which option you intend.
I see a possible difficulty in that [3] may require the connectedness of a locked chest to be based on its prior state so that unlocking half of a double chest does not cause the still locked half to seperate.
If a thief were to break half of a locked double chest, and place their own unlocked chest next to it [this is the sort of thing I meant by "undesirable use"]– the remaining half of the locked double chest needs to recognize that it should not connect, but if the owner of one half of a shared double chest were to unlock 'his half' the connection should remain.
Stated another way, it seems to me that the locked chest behaviors you wish to implement require that the rules for a half chest connecting be distinct from the rules for it remaining connected. (The new [1.13] placement rules may obviate this concern, but I still think in terms of old [1.12] mechanics.)
Something related about which I am unclear:
When one breaks into a locked container using an anvil, does the base container and its contents drop around the anvil? This would seem to be necessary as one could otherwise remove a full container [without padlock] from the anvil.
quote=Malloon
Well, the problem of not wanting to move chests that are in the way but are full of random items that you don't want to sort through is one that [i]most [/i]players experience, I think. The other one, people stealing from you, is one enough other players experience that most public servers have plugins to help prevent it. It's impossible to have additions that everybody will use - some people only play to build with redstone in creative, or to fish; you can't please everybody.
I'm not such what you mean with the performance difficulties and overhead. Do you mean RAM? I hardly think one extra item and one or two new(ish) blockstates/NBT tags will add to that.
I agree about most players finding a (limited) ability to move containers with the contained items would be useful.
Also that thieving is common enough in SMP play that a universal (partial) solution written into vanilla would decrease the need for mods (and increase the commonality of play experience).
WRT prefering to see this as a mod rather than a vanilla addition, I see two types of concerns…
The first of these is ongoing
While I would probably use this aspect of he proposal myself, I am sure there are those who will feel it "breaks MC" [probably based on similar trains of though to those that that precipitate similar reactions to ender chests and shulkers]. Certainly, the utility of the proposal would lessen a 'thing' [ie the annoyance of moving chests of items] that may be considered part of the inventory management/storage organization constraints.
I am unclear how strongly this proposed mitigation would effect overall gameplay and would like the proposal to be given a trial as a mod before becoming vanilla standard.
I also have some concerns about fixing a social problem [thieving] through programming. I have seen a number of MC servers that take the position that, as they have provided a way for one to lock one's chests etc. it is the victim who is to blame if items are stolen from an unlocked chest. I find this attitude sufficiently unpleasant that adding something that might futher it spread to the vanilla game is hard to support. That this proposal actually provides a mechanic that allows stealing (although at some expense) is in its favor. I would nonetheless like to see some 'field-tests' of the ideas in mod form before such are made standard.
My second sort of concern is [hopefully] temporary.
Any additional content will increase the computational demands of a program, and — given that currently 1.13 is effectively unplayable for a number of users due to "performance difficulties" no additions should be made until this critical issue is fixed.
Despite the computational resources required by this suggestion being [likely] but a straw, that argument has apparently been used with far too great a frequency in the rush to release 1.13. [Not to mention longstanding issues with block placement glitches, the lighting engine, and entity glitches on chunk loading.]
Fixing what content has already been added needs [IMO] to be prioritized over further expansion.
Edit: Holy broken BBcode Batman! I have no idea what just happened. It should be fixed now, though.
Ah, now I understand. I agree that would overcomplicate things.
Hm, yes. For my part, I'm sold: that all does seem really useful. But I feel additions should always be incremental, so as not to change the game up too much in one go. I'd consider this part of the second load of additions I'd support.
And I completely agree. In hindsight I might actually prefer this way. I'll change it in the OP.
You can't; it shouldn't. I thought I was clear enough, but I'm probably blinded by the curse of knowledge. While I know I should make it clearer, I'm still hoping for a better way to be proposed. I'll clear it up for you down below, though.
To clear things up, I considered a block inventory to be "locked" if the padlock was applied to it. Opening the inventory while you hold the key no more "unlocks" the inventory than, under the current version of minecraft, opening a locked inventory with the correctly named item "unlocks" it. Adding or removing a padlock is analagous to applying the command /data merge block {Lock:""} with either something or nothing between the quotation marks.
The second state doesn't exist: an invertory is either locked, or unlocked. But chests do have other states that coexist with these:
1. Connected to unlocked chest.
2. Not connected to unlocked chest.
And these as well:
a. Connected to locked chest.
b. Not connected to locked chest.
Bear in mind that "connected" is not the same as "next to".
Due to how the game works, state 1. and a. cannot exist at the same time, but 1. and b., 2. and a. and 2. and b. can. If you combine these three states, you get 8 different possibilities, of which only six are possible:
1) Unlocked, 1., a. - Impossible, irrelevant.
2) Unlocked, 1., b. - Can open; One half of a double chest.
3) Unlocked, 2., a. - Can open; "Unlocked" supercedes all states. The locked chest it is connected to is also openable, because of 6).
4) Unlocked, 2., b. - Can open; A normal chest.
5) Locked, 1., a. - Impossible, irrelevant.
6) Locked, 1., b. - Can open; State 1. supercedes state "locked". A locked chest connected to an unlocked chest can be opened.
7) Locked, 2. a. - Can't open; One half of a locked double chest.
8) Locked, 2., b. - Can't open; A locked chest.
That is correct.
I did not mean to imply that. The sharing of a chest would not extend to picking them up and placing them again with them automatically connecting.
This is what I intended. Not nearly as useful, but far less complicated - the sharing of double chests by way of two players each padlocking one half is a nice extra that results from how this idea works, but isn't a core feature. As such, I don't want to add stuff or change stuff around to better accomodate it.
That wouldn't happen because the state of "connectedness" between chests is unrelated to them being locked or not - they're the same chests. A chest being locked does prevent another chest from connecting to it, but more on that below.
This is exactly what I'm trying to avoid here too, and my solution is just to not let [i]any [/i]chest which is placed connect to a locked chest, or let a locked chest which is placed connect to any other chest. Since this only happens/is determined on placement, locking and unlocking should have no effect on connections.
Yes, you are correct: chests already connected follow the current rules, while a locked chest being placed or that has a another chest placed next to it prevents connecting entirely due to it being locked. This is similar to if you placed a trapped chest next to a normal chest - they don't connect either.
Thank you for reminding me - I should have stated this. The base container doesn't drop, but the contents does.
That's always how I used it.
That's all I need.
There's not much I can say to that except shrugging. The people who believe it "breaks MC" will need to argue in spite of ender chests and shulker boxes, like you said, and for the most part I think they're part of the crowd that will never be happy if something changes. Minecraft has to, to keep the playerbase alive, so I'm not overly concerned with them.
Regarding having it as a mod first, it wouldn't be my first choice, since I think I've thought through all the possibilities and come up quite positive, but because my first choice is direct implementation into the game I'll still welcome it with great enthusiasm. A mod would increase visibility, too, which is a plus.
-.- I had a whole paragraph written here that's been consumed by corrupted BBcode. Boiling down what I said: I don't know how how much this will affect this, but public servers can try and curb bad behaviour with laws enforced by moderators, or with extra security tools given to players. Good moderators are worth their weight in gold, though, and are as such hard to come by, and some servers may decide not to ban stealing in favour of just giving the players tools to prevent it. While my suggestion may make giving the tools to players easier, I'm fairly certain servers whose moderators and admins are too overworked or lazy would just have used plugins anyway, and their enforcement of any stealing laws would be less than commendable anyway.
My idea does make the [i]gameplay feature [/i]of stealing, as I consider it, less frustrating, because it makes it easy for players to make it harder for thieves.
Agreed, but that's such a deepseated issue that it shouldn't really be relevant to my suggestion, but rather to suggestions as a whole. Keep mentioning it, so people are aware, but please support or not support individual suggestions without regard to this, otherwise support/no support becomes useless in discerning how well suggestions are recieved.
_ _ _ _ _ _ _ _ _ _ _ _ _
Regarding datapacks - I looked into them and it doesn't seem like adding this would be possible using them.
quote=Malloon"
To clear things up, I considered a block inventory to be "locked" if the padlock was applied to it. Opening the inventory while you hold the key no more "unlocks" the inventory than, under the current version of minecraft, opening a locked inventory with the correctly named item "unlocks" it. Adding or removing a padlock is analagous to applying the command /data merge block {Lock:""} with either something or nothing between the quotation marks."
I think this is the crux of what I was not missing.
As I read the above paragraph, a chest/container would either have a padlock applied [locked] or not [normal or unlocked].
Accessing the inventory using a key would not change that state, meaning there is no way to have a chest with a padlock applied but the inventory openly accessible.
[I had thought a key holder could exit the inventory leaving the chest in a state where a non-keyholder could access the inventory, but leaving the padlock in place.]
Reading back I found this "The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it." I had taken that to mean than access without unlocking was an option, not a requirement.
Clarifying that using a key to access the inventory of a container automatically leaves it in a locked state and that padlock removal is a distinct action might help avoid confusion. [I was thinking of a padlocked chest as being like a locking door (eg the exterior door to a house) can be unlocked then opened and closed and arbitrary number of times before being relocked vs a normal chest (which whould be analogous to the usual interior doors which do not have locks).]
If my new interpretation is correct, it does simplify matters and obviates a number of the concerns I had raised.
I can't find an explicit mention on rereading, but can a keyholder remove a padlock?
This would mean keys perform two distinct functions:
access – which does not affect the locked/unlocked state, and
unlocking – which removes the padlock (& returns the item to the player? ) [Would unlocking/removing a padlock automatically access the inventory, or would that be a separate action?]
RE doing it first as a mod. I'm rather conservative about change and I remain convinced some thousands (or tens of thousands) of users playing with (and trying to exploit) an idea from some months are more likely to find any corner cases needing modification than armchair analysis. [It also strikes me as 'politically' far easier to change something in a mod than in vanilla.]
Assuming no damning problems are found, this is something I'd eventually like to see added. [Assuming the 1.13.performance issues can be fixed… which is likely to be done by third parties (ie optifine) even if MS/Mj doens't do the job as they ought. Waiting on this remains, however, extremely irritating.
]
Correct! You either have to remove the padlock or loan the person the key.
Yes, that wouldn't be possible.
Ah, I see where the confusion came from. Yes, I will clarify that.
It definitely seems to be.
Yes. (Assuming the idea of a masterkey/copies of that key is added, only the masterkey would be able to).
Exactly! Thank you for posing these questions! It's made me realise I should have been clearer. "Access" is exactly as you describe. "Unlocking" is also right, almost - it would remove the padlock and turn the key used to do so back into a padlock and key ("giving" the padlock back), but it wouldn't access the inventory. That would be a seperate action.
That strikes me as a very fair assessment.
Amen to that.