Minecraft Forums

Oh, more or less an agreement! Sorry for the confusion. Any further criticisms on my part would just be nit-picking, I feel. I'm happy where we've gotten to.

That's sorted then. Thanks for responding to me!

Quote from ScotsMiser»

Bravo, Mallon on the rework.

Thank you!

I would suggest, however, having the tip of an unmoving spear do minor damage (as fist) and block movement along the shaft. [Bears and boars were notoriously able to 'walk up' spear shafts to attack the weilder, but this does not seem suited to MC combat.]
This level of damage would make it necessary to be cautious moving about with a spear 'at point', but is low enough actually killing friendlies should be rare.

I would not have the spear block movement under any circumstance; I actually did consider it myself, and indeed compared the alternative to someone running up the spear, but letting the spear block movement in addition to having longer reach would make it a better weapon than sword and axe, period. I'd wager this would be true even if is had a lower attack speed and damage than the sword. True, you could still get swarmed, but the tactic there even with sword and axe is to back up and hit them one by one, which the reach would work wonders for. In one on one, you could quite literally keep melee mobs and creepers from touching you while hitting them back.

With my suggestion, you can do something similar, namely hit them repeatedly while they are at a distance and use the knockback to keep them there, but you have to be skilled, quick, and if you hit too late once they're out of the zone where you can effectively damage them, while they can most certainly damage you. Needing the speed and skill (plus the spear going vertical) was the compromise that kept them from being overpowered.

Regarding "walking up" the spear, I don't think it's a problem. Weapons and tools noclip into blocks and mobs all the time in minecraft, so I doubt people would think this is any different.

The spear doing minor damage would also be out unless damage doesn't do any knockback (in which case you'd have the same problem of the spear easily keeping mobs back). I'm... not completely against that. Ultimately it would come down to balancing, and I guess it would help teach how the spear works. So yeah, sure, I'm for it. But no base knockback - let's have it be like a cactus.

I do not understabd from your post how you intend to adjust damage with the speed of the attacker: my ideas are below:
[Using closing speed rather than the movement speed of the attacker would be more realistic, but might be too computationally expensive.]

Player walking speed is 4.3 blocks per second
Player sprint speed is 5.6 BPS
Minimum horse is ~4.8 BPS
Average horse is ~9 BPS
Maximum horse is ~14.5 BPS [All values assume no status effects.]

Given the chunkiness of the damage (3, 4, 5, or 6 points per hit – depending on material) there isn't a lot of room to scale damage with speed.

In general, I was thinking the tiers would have a base multiplier, or power or something like that and then round. A formula I'm happy with is speed divided by 6, 3, 2.25 and 1.75, for wood/gold, stone, iron and diamond respectively. With wood, walking does 0.7 hearts of damage, rounded to 0.5, sprinting 0.93 rounded to 1, riding an average horse does 1.5 and riding a maximum horse does 2.416, so 2.5. With stone, it's walking 1.5, sprinting 2, average horse 3 and maximum horse 5. Iron, it's walking 2, sprinting 2.5, an average horse 4 and a maximum horse 6.5. With diamond it's walking 2.5, sprinting 3, average horse 5 and maximum horse 8.

Knockback would be calculated similarly.

One solution would be to have the lesser tiers (wood and stone) 'top out'. [Extending this to iron lances might also create a place for gold lances, if these – while doing the same base damage as wooden ones – the performance of gold lances continued to improve.]
Player walking speed or below would offer a simple 1 damage improvement (to 2 ) over the unmoving (fist equivalent) spear
Up to and including player sprint speed would add another damage point (to 3 the maximum for a wooden spear)
Up to, but NOT including average horse speed (9 BPS), another (to 4 the maximum for a stone spear) [Gold would do 3 or 4 (50% chance) at this tier]
From 9-12 BPS (inclusive) would do 5 damage and require a gold iron or diamond spear [Gold now does 3 or 4 (50% chance) at this tier]
At any speed above 12 maximum potential damage would be dealt [3(wood), 4(stone), 5(iron), 6(diamond), with gold doing 5 or 6 (50% chance)]
The above would require both a good horse and good equipment to achieve maximum utility from the weapon:
Top level gear would only be advantageous (other than for durability) when mounted. [Wood and stone versions will likely still be nearly unused after very early game, but I do not see a solution to this.]

I like your idea, but I like the simplicity of my formula better. I think higher tier spears should be more useful on the ground as well as on horseback as opposed to lower tier ones, and just have lower tier ones "top out" means they're useless on horseback, but offer no disadvantage (besides durability) on the ground. Ground combat should really be limited to normal attacks, which is why no sprint attack in my system does more damage than a normal strike, though I guess you could "combo" by hitting then sprinting before the spear recovers. Anybody who manages this trick is welcome to it, I think.

Effectiveness in mounted combat would also be very dependant on the quality of the mount. [Both realistic and offering a strong incentive for players wanting to use mounted combat to seek out/breed such mounts. (Nether tarvel and ice roads having removed much of the impetus to obtaining fast horses.)]

Quite! This is another reason I like this idea so much - fast horses make for a lot of damage, the fastest horse combined with a diamond spear doing a whopping 8 hearts, or 16 hitpoints. A good elytra swoop might do similar. And that's not even considering the possibility of enchantments.

Quote from Vyryftiis»

All the wordiness. Although I enjoy the fact it has sparked such thought outbreplies.

Yeeeeesssss.... I know. It's just, I've had too many times where I've left something implicit and someone missed it or misunderstood. I keep on the safe side nowadays, or try to.

Quote from Vyryftiis»

I am primarily a console player. So mouse binding means nothing to me. That doesnt mean your idea isn't a good one for PC. I have bumper buttons and triggers, hence why charging an attack was an idea of mine. The not being able to jump was because I consider a lance to be a bit OP. But for simplicoty sake sure. Let them jump!

Thank you. This was important for me, so I'm grateful you've accepted it so easily. The fact you are a console player explains quite a lot (this will come up somewhat often in the following replies), since you don't use the 1.8 combat system - which I had forgotten. I'll try and tailor my suggestions so they'll work for your combat system too, or offer a slight variant.

I struggle to understand this logic. That is history. A country comes up with a weapon that seems unstoppable at first, so the other country finds a counter. If a horseman with a lance is charging you, and all you have is a sword and shield, they can jab and stab at you with no real worry about getting hit themselves. As stated in my idea, a sword has a 0 to 1 block range. A lance would have 2 to 3. Sure you could block all day long. But you wouldnt be able to attack very well unless you are ranged. And while you are drawing your crossbow or bow, you drop your shield. That is a good opening for te horseman to stab you.

If mounted horsemen were a common threat (say, on a long existing and populated multiplayer pvp server, or if there was a common mounted mob that spawned with a spear) then you would have a good argument. If there's something common you need to counter, having a counter around would be useful. But mostly, mounted horsemen are rare, so players as a whole would generally just rely on their primary weapon (be it sword or axe), maybe include a bow, and take their chances. They wouldn't sacrifice a slot in the hotbar or even their inventory to carry around something they'll only very rarely or even never use. That would make it a dud. How many players carry around a bucket of milk, just in case they fight a witch? Practically zero - players takes their chances they'll be able to handle it without the milk, and free up an hotbar slot by doing so.

Axes are incredibly useless in my experience for anything other than chopping wood. 5 hits to kill a zombie? When I can kill one in three with a stone sword? Nah. A spear would be equivalent to an iron sword in damage. Hence the need to balance it out.

This is where we see a bit of difference - in the java edition, axes do more damage than swords (wooden axe: 7 hitpoints, wooden sword: 4). The trade off is axes use two durability each hit and recover slower; If you spam click, you do fist damage, you need to wait for the recovery bar to refill in order to do full damage. Swords have more DPS (damage per second) because they can attack faster, but axes do more damage each hit. Which you prefer depends on your playstyle. Me, I prefer the axe.

But for the console edition, we don't need to prevent the spear making the axe obsolete as a weapon, since, well, it isn't a weapon. But we do need to prevent spears from making swords less useful. To this end I think making each type of spear (yes, I know, I'll get to why I think there should be more than one later) do less damage than the sword, which it makes up for (slightly, but not really) with range. I proposed spears do 1.5, 2, 2.5 and 3 hearts of damage respectively in the java edition, and I think these amounts work for the console edition too, since swords in the console edition do half a heart more damage than swords in the java edition.

No more so than an axe. I usjally have a sword, and a bow or trident for battle. And sure I have an axe, but I only ever use it for chopping wood. See above response. Spear wouldnt be a dud. Not unless you made the trident have the range I mentioned for melee. But since it can be thrown I dont see this being implemented. It also has a similar 0 to 1 block melee range, like the sword. The tridents only advantage without enchantments, is that you can throw it. Hence, again, spear.

Eh, eh, I see what you're getting at, but the problem is spears aren't different enough compared to the sword (on foot) to make them useful enough. Tridents and bows can hit mobs and players at a very large range, far further than the spear, and are needed often to counter skeletons and creepers, which are very common mobs. Spears (as you first proposed them) are not a big enough counter to any mob or normal player and have to weaknesses you described. Hence why people would stick to swords.

I suppose you may be correct. But the only time I would see a need to do that, is when tridents are being tossed at me, or a skeleton is shooting me, or a pillager is shooting me.

Being shot at by a skeleton isn't all that rare. But besides that, the game slowing your switching would feel unfair and artificial, especially if it gets you killed. You don't want to trap players in a Mortens Fork - either die because the spear is a bad weapon against skeletons, or die because the spear won't let you switch to a bow fast enough.

Any other mob would be fended off quite easily since you have superior range for melee combat.

If is true, and I'll take your word for it, it's a problem. Why? Because fending off mobs shouldn't be easy, or at least not easier than with a sword. Even if it's only slightly more easier, you get the problem that spears will replace swords. And that shouldn't happen.

The more enemies you face the harder it gets sure, but it can be done.

In which case spears won't be used in melee, since swords can be used effectively against both single enemies and crowds - a spear being incrementally better than a sword wouldn't be enough for players to sacrifice another hotbar slot, unless... unless the spear outclasses the sword enormously against single enemies, in which case you'll have players using spears, swords and bows/tridents.

But that's a problem by itself. Normal gameplay would become easier, since spears would offer a new way of dealing with mobs. And making normal gameplay easier isn't on Mojang's to-do list. They have in fact been making the game harder. They could do that again to deal with spear wielding people, but that's a whole other... thing that would like to avoid talking about here.

Especially if we remove the need to hold down a button/key to attack. I still think then a regular spamming attack would be nice, and a "hold to power up" secondary function would be great. Now, it can be effectively used in any situation. Multiple enemies? Spam the spam attack. One or two? Charge that attack causing more damage and knockback. *gasp* the spear is now viable again!

I've already said my piece on the problems of making the spear viable. We have swords, and we should make sure we don't replace them.

Regarding the charging mechanic - "charging" up for a really big stab isn't the least intuitive thing in the world, I suppose, but there's one big problem with charging attacks: They are very imprecise. You need a slow, or at most normally moving enemy moving in a predictable direction for you to have a chance to hit, which is true of neither players riding horses (they move too fast for you to reliably hit them before they've moved in too close and after they've come into range), nor of players facing horse-riding opponents (they would jump side to side). Just try to hit mobs while riding and using a sword now - you can spam, but you'll be sure to miss most swings. You can't spam charged attacks. So I'm completely against charged attacks on weapons made to be used on horses or against horse-riding opponents.

To this I agree.

Great!

See the long winded explanation to responses above. We have similar ideas.

We do indeed.

More powerful attack. Double the damage when charged, with the addition of knockback without an enchantment.

I got that that was what it did, I just didn't see how it would be intuitive. I do now, but I have other issues with the charged attack, you you know.

I see an issue here. Will it reset to center after a certain time? How many "clicks" to get it pointed slightly left as opposed to right? Slightly up without being vertical? Will you have to cycle the clicks every time to get back to center?

I think you misunderstood. Holding the spear vertically means it is held like a staff, and points at the sky no matter where you look. Right-clicking once makes it go "horizontal", but that means it points wherever you look. You look in front of you, it points there, you look to the side, it points there, you look up, it points up, you look down, it points down, no clicking required. It follows your camera. It doesn't stay pointed in one direction unless you keep looking in that direction. No cycling of clicks needed.

As someone who has done some spear fighting in my life (training and practice obviously, I haven't been in a historical war in a phalanx killing people), I never had to move to do damage. Other than my arms and hands, maybe a lunge, and in fact, if I was running, or even walking, it was easier to get me off balance and find an opening as opposed to Just moving my arms and hands. So the whole moving to do damage is quite silly. I can better block and parry, attack and maneuver from a strong, standing, fighting stance.

You do HEMA? Cool. I've been meaning to get into that, but there's no group close to me. I do do jugger, though, have done kung fu spear fighting and watch a ton of videos on YouTube on HEMA. Spears were indeed better than swords for fighting, though I think you're underestimating the value of good footwork. Here's Lindybeige's video on the subject:

All of this is very interesting as a starting point, but we can't follow through on that entirely. Realism is good for two things: immersion, and giving players the ability to work out how things in a game work by using their already existing knowledge. It has its limits. But still, we can try to stick with it up until a point. That point is where spears would become so useful that they would replaces swords in minecraft.

If you have to try and equate minecraft's mechanics with real life, moving and doing damage with a spear would be lunging. Attacking normally with the spear (which is the primary way I would want people to attack when on the ground) would be the normal stabbing motion. moving to do damage should only become the primary method when on a horse, or while flying, since there it is too easy to miss if you had to rely on attacking normally.

Another reason to need an attack button.

I suggested one. Second to last paragraph, second line. I suggested spears can be used to attack normally if they are being held horizontally, but only at a range of three blocks.

What you are saying isn't really making sense. It would be like me pointing my sword at my pets or friendlies and them getting hit. It doesnt happen. Not unless you "attack".

Because we need a mechanic to reliably attack while riding a horse (and elytra, though that's the cherry on the cake). Having to attack normally would make you miss a lot. I suggested this type of attack because it's as close as I could get to what knights in the real world do: Hold their lance in the crook of their arm, charge and point the lance at the enemy. They don't also stab forward with the lance. The reason they do this is because trying to stab would make them miss, and the force behind a lance held by a charging knight on horseback is more than enough by itself.

Why would the spear be any different?

Because we were trying to make a weapon that is uniquely suited for fighting on horseback.

Another fun fact about me. I also did some practice fights with a sword against a spear. Against a well trained spearmen, unless I had a shield, I wasnt able to get very close to a spearmen. Not easily. And even then they just had a dagger or arming sword and stabbed my happy ass or cut me if I did get close enough. With a shield I was more easily able to counter though. I imagine the same would be in Minecraft.

I imagine a shield would be very useful against a spearman. However, since we are trying not to make swords by themselves (without a shield) less powerful than spears, we can't implement all the abilities a spear has.

Quote from Vyryftiis»

Keep in mind, the spear I am talking about when practicing was about 8feet long. It was cumbersome, running and moving too much was risky. And when I had two or more people against me. It was hard for me to be victorious. Jence my no jumping and s

No sprinting ideas.

Now. I also had experience on a short spear. About 4 to 6 feet long. I was almost unstoppable. Even against a person with a sword and shield. Granted I was able to parry their weapon, force myself in and hold their weapon, or throw them down and then stab them. None of which are things you can do in Minecraft. So. I tried to find a medium between the two. And came up with this. Though in retrospect, I agree with many of the criticisms. It should be more viable in the field. Not Just a counter weapon with mild uses in regilar combat.

Spears are awesome, I agree. Thank you for listening to my criticism. However much I may disagree with you, I very much respect someone who does that.

Quote from Vyryftiis»

There are not wood, stone, gold, iron, and diamond tridents. It is just, the trident. Simplify all of these issues you have. A spear is just a spear. With damage equal to either an iron sword, or a base trident. Just with greater range, and the ability to "knockback" an enemy with a charged attack alone, no need for an enchantment.

-Again. Get rid of the tiers. Just one type of spear with unique enchantment availabilities as well as a charged attack having knockback 2. With a base attack of an iron sword or a trident.

My last pieces of criticism for today: Tridents do indeed not have tiers. There are reasons for that, though, and it is because getting them is assumed to happen around the time people have diamonds to spare already and the ability to enchant, and to make acquiring them more interesting than just crafting them. Tridents below diamond-tier (which is what I consider the current ones to be) would be too similar to bows and arrows, not being enchanted, and having only one to spare (as opposed to multiple arrows). I'd bet good money that if wooden, stone, iron and gold tridents were introduced into the game they would mostly go unused - on land. Maybe the wooden and stone ones would get some use until the player gets a bow and some arrows, but not after. Javelins have been repeatedly rejected by Mojang for years before the trident came along, for these reasons.

But I did say on land. A lot of people don't use tridents even now, and even you admitted they were at least equal in usefulness to bows and arrows (or at least that's what I understood, pardon if I'm wrong). Where they shine is under water. There they are the weapon to use, and for good reason, since you can forget about bows and arrows. The fact they have an area where they are very useful, even if they aren't used by all players everywhere, means that they were a good addition to the game.

Spears could be implemented similarly - you could have them be found in dungeon chest along with horse armour and saddles. Have them be the weapon that shine when used while horse riding (and flying).

I don't think that's the best implementation method though. With leather horse armour becoming craftable in 1.14 java edition and saddles becoming more and more easy to get (through trading, fishing and lots of loot chests) Mojang is making riding horses easier. If players can start riding early in the game, though, you want to give them the ability to fight on horseback too - to make it even more attractive to do. But if you put spears in loot chests you have to decide if they should be early game weapons or late game. If they are early game weapons, they'll make horseriding attractive early on (at least for a while), but if you make them late game weapons you either have to make them rare, which will negate the attractiveness of fighting on horseback, or you'll make them common and give players an overpowered weapon.

I say, split the difference! I'm fine with spears not being craftable, like higher-tier horse armour, but having different tiers (with the higher ones being rarer) will make players have both early game and late game weapons for horse riding.

Edit:

Yeesh, that turned out longer than I expected. Sorry about that.

I've had an idea for a spear for a while now too, but I'm think your idea is, in a word, too complex. There are too many different mechanics and similar items. But the thing I agree on is that we need a dedicated weapon for horses.

And in my opinion, elytra, too.

Quote from Vyryftiis»

-1. A lance. Used specifically for horse combat, has a range of 2 to 3 blocks as opposed to 0 to 1block (that way you can still see the mob you are trying to hit), and for balancing, holding the "jump" key/button when a lance is equipped replaces jump with "power". The longer you hold it, the stronger the hit. Attack upon release of "power" key/button. Can only be used on horseback. Effective against Ravagers (Pillager beast).

I would not mess with the movement controls. There's no real reason holding a lance would prevent jumping. I would keep everything bound to the mouse buttons.

-2. A spear. Used to counter lances. Range of 2 to 3 blocks, replaces "jump" with "brace". The longer you hold it, the stronger you "brace". A full brace will harm the horseman and you take half the damage you normally would.

The same problem here - preventing jumping really hurts movement, and that's important in combat. Plus, having a weapon whose main purpose is basically to counter other players using a certain weapon set makes it almost a dud item.

The spear can be used on foot against regular mobs. When equipped you can't sprint, and you can't jump. Great against Zombies, Husks, players on horseback, Vindicators.

You sure about that? You mention the attack is slower than a sword, well, in that case it's basically an axe used at a further range, which would make axes useless if not for the inhibited movement controls, which makes spears useless instead, since all these mobs can close the distance to you if you try to wait for them to recover if you use an axe, and 2-3 blocks is not much extra. Vindicators are even faster.

Ok against melee Drowned, and Zombie Pigmen (their swarm mechanic will quickly overrun you). Not recommended against creepers(knockback needed). Bad against Skeletons, Trident Drowned, Pillagers, and Evokers. It is basically suicide as they will always out maneuver and out damage you.

Which makes the spear a worse weapon to have on you than either the axe or the sword, and since players won't want to waste too much of their hotbar on weapons, that makes them quite a dud.

Regular attack will be slower than a sword, but more powerful. Weapon/item slot switching time will be increased when switching to or from a spear for balancing.

So not only will you want to switch from the spear to another weapon when encountering mobs against which using it would be "suicide", the game will hinder you doing so. Sorry, that's not much fun.

I have the crafting recipes for both of these, however I am on mobile so I have no way to share them. That I know of anyway.

I'll suggest my own.

I really like the idea in concept, but the execution is lackluster. My suggestion would be too focus on one weapon, have it have simple controls, but be unique and especially useful for horseback and elytra. And what the heck, for against foes on horseback too.

I'd combine the two ideas of the lance and spear, so that the less common use against foes on horseback can be included without making the weapon used for it a dud. Just call it the "spear", since lances are just a type of spear. We'll need to make it sufficiently different from the sword and axe so it doesn't replace either one. We'll also either need to make the recovery fast or do something else, otherwise it will become too unwieldy on horseback or when flying. The thing is, at the speeds that people travel at on horseback or with elytra, you'd almost need to be able to spam-click to have any hope of correcting yourself if you miss. Or you'd need to stop, which is impossible with elytra and a bit stupid with horses, since that defeats the purpose of riding them.

So let's do something else instead. I will keep the base attack damage by attacking, but I will re-balance it based on what comes next. I don't think any type of loading or drawing should be used for spears - it made sense for the bow and crossbow, but there's no reason holding a spear longer would make it do more damage. My idea is to instead have two "modes", which is just a fancy way of saying how you hold the spear, namely vertically (pointing skywards, no danger or use to anybody) and horizontally, pointing at wherever your crosshairs are pointing aka. where you look. You switch between them by right-clicking. No loading time, so drawing back, just "click" and the spear is pointing in a different direction - which you can see from how it's held in you hand.

The spear would be the weapon equivalent of the shield, doing stuff wherever it's pointed, though in contrast to the shield it would have far less wide and tall a range (just limited to the area around the crosshairs), and could be pointed upwards if you look up. Anything that moves into the point of the spear gets damaged and knocked back, but only if the person holding the spear is moving. The amount of damage is based on the type of spear (wooden through diamond) and the speed at which the person is moving. So if you are riding a horse or flying when the spear touches something you do much more damage and knockback than if you were just sprinting, and you do more damage if you sprint than if you walk, and none if you stand still.

The fact the spear does damage by you moving is the reason for the modes - so you don't accidentally impale your pets or your friends. But I did say I'd keep the base damage, and I will. You can attack normally with a spear, but only when held horizontally, and only at a range of three blocks. This means you can't accidentally hit your horse if on horseback, and means it is a viable way of fighting against an opponent on horseback, since you get extra range. I would make spears do half a heart less damage than swords of equal value (1,5, 2, 2.5, 3 hearts), but increase their recovery speed to 0.5, which means their attack speed would be 1/0.5 = 2 and their DPS 2 * (3, 4, 5, 6) = (6, 8, 10, 12), very close to that of swords. But since each hit is less damaging and you need to be at a certain range for the damage to count, swords are still the better choice when fighting against opponents on foot - a swordman can bridge the distance and chop you up.

If you hit something that's within two blocks range of you, you switch from horizonal to vertical (this is the indicator the opponent is too close) and any hit you land does as much damage as your fist, but won't remove durability from the spear.

This doesn't add anything of value. All adding this would add is damaging the player every few minutes randomly, with no way to avoid it besides not playing the game. I suggest you read this thread, especially the part under "Artificial difficulty".

Adding this would probably even make the game unplayable. Considering that the player is usually always on the move, this would mean they would trip an average of once every 100 seconds (every one and two-third minutes) at minimum, and sustain one heart of damage every 13 minutes. At maximum, they would trip an average of once every five seconds, sustaining one heart of damage every 25 seconds, or just under half a minute.

This would make sprinting completely unviable.

And that's not even taking into consideration that fact you need to take a few seconds to get up again.

No support

Quote from ScotsMiser»

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

Amen to that.

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 from Bad_Jim2»

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.

Quote from Badprenup»

(...)

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.

Thank you!

Quote from ScotsMiser»

Well thought-out and well presented.

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.

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.

Quote from HeadlessCowboy_»

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.

Quote from Bad_Jim2»

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.

Quote from Dheatly23»

Wow! What a neat idea. I think it is implementable in 1.13 using datapack.

FULL SUPPORT

Interesting. I might have a go at that.

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

2) Locking an Inventory

3) Inaccessability of Inventories

4) Breaking a Locked Container

5) Only Holding it in your Off-hand

6) Locked Double Chests

7) Breaking Locks

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

Locking Mobile Inventories

Keyrings

Copying keys

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.

I had an idea similar to this.

Quote from flaminghawk83»

As it's been said, this needs more detail. But I think it has potential. Maybe have it so that, the actual damage is based on the speed of the horse? And the more damage it deals, the faster the durability goes down.

But, it does need more detail. Like, a crafting recipe, stats, maybe a description on how it looks. It has potential, but it's vague.

Quote from Hydraheads»

I think this would be pretty fair game. I have a few ideas for it myself. By right clicking the lance, you extend it forward. If it makes contact with a mob or player, it retracts and deals damage. Regular left clicking only has sword range. If paired with a shield, both are held out simultaneously. However, it passively slows you as it is extended. It has the cooldown time just below an axe, and about the power of a sword.

Because it slows you, it is best used on a horse where the horse's movement is not hindered in the least bit. When charging at high speed the lance does high knockback. This allows you to pull back and charge forward replenishing the strength bar for another charge.

(in other words, it is a decent weapon on ground which is still not as good as your other weapon options, but it shines when you are on a horse as a knockback oriented weapon allowing you to effectively control the positioning of a player or mob/knock them off a ledge).

This might also give the elytra combat potential, seeing as how you needn't swing at the exact right moment, but rather extend and swoop. Given how we know now that it's possible to use the angle of attack and defence (shield), I would suggest a similar thing for the lance, an range of 45° around the crosshairs, 22.5° to each side; right, left, up and down.

Quote from Hydraheads»

I can't speak on the behalf of the OP, but I would recommend this for the crafting recipe:



(got this from another site)
It would probably be the most fair approach as it wouldn't be too great without a horse.

Quote from Wrangler1941»

I'm sorry i didn't detail anything, I'm just nub / part-time player. No way i am coder of any sort.

Hydrahead's proposed build of a pike lance would be basically what i was proposing. Range would properly be one block further away than sword would be but it would have longer cooldown time. Especially if your trying jab it at people.

If your on a horse as a lance, with the up coming shield, i'd would hope you get least be able aim it as your going try strike the target. However, you wouldn't really need cool down period because your trying steer the horse.

That where lies the problem i think trying to control the horse and do combat.

Quote from AuranJ

a) You still have the problem of knowing what potions are in what cauldron. But yes, now that I think it through it would be quite easy to store the data with a single variable.

No it would be hard to know what potions have what effects in the split second where you are ambushed or fall into lava.

c) I assume you mean the /effect command. That is just applying effects directly to the player. Things like NBTEdit take something like a speed potion and then change the effects of it. The color of the potion is the original potion and the ID is the same as the original potion.

d) Good Job! I hope we get to see the new "Potion Update" soon

e) Actually cauldrons are used for lots of things. They can be sinks, witch cauldrons, urinals, toilets, a and pretty much anything that has a hole in it. You wouldn't want to use it everywhere though, it's like how you wouldn't a building made of solid diamond blocks.

Says the person who said poor cauldron was useless.

Quote from redstone1337

So can someone update me on what's been going on here? I'm curious to see how this little idea has been developed by other people. I have some new ideas if we want to start from scratch.

-VO syntax
-ergative alignment (no case marking, though). A sentence with an intransitive verb has the subject at the end.
-maybe have deictic information indicated by infixes inserted after the first consonant cluster of a noun. These infixes would indicate the person of the referent as well as spatial information (roughly equivalent to English "this, "that", and "yon") etc.
-Verbs have no finite/infinitive distinction. Compound verbs just stack two verbs together whose tense and voice match

Any other ideas?

Quote from AuranJ

I like it but There are some problems with it.

a) How would you know what potions are in any given cauldron? How would the game store that data?

Having to rename every potion in an anvil is hideously expenisive.

c) If all the combinations are their own potion type and unlike 3rd party editors aren't a normal potion item with custom effects, the item ID list would easily triple or quadruple in size.

d) Potion diluting by adding water to make it somehow less level 1 would require a massive rewrite of the entire potion system.(Breaking the rule of not being a pain for mojang to add)

e) Saying cauldrons are useless is like saying stone bricks are useless, in fact, it's even worse. Cauldrons look better than stone brick and have the added bonus of being able to store water.

Unless you solve these problems you have No Support from me.

E isn't really a problem it's just: why are you being mean to cauldron D':

Quote from redstone1337

Oh man! I didn't realize there'd be so many replies. I haven't been on the forums in years. Now that the villagers have sounds, I think their language would have an abundance of nasals. Come to think of it, that should have been obvious even before the sounds were added. Also, I conceived this long before trading and iron golems were implemented, so now that their society is a little more fleshed out, a language would be at least a little easier to make.

I'm still having trouble finding a good system for documenting the language, though. I wish there were a computer program that could output words based on a phonology and phonetactic constraints.