[MC-117005] /replaceitem and /give no longer allow stack sizes higher than max stack size

By using /replaceitem, we should be able to create stacked potions. However, error message will show up since 17w18a when using the command

/replaceitem entity @p slot.hotbar.4 minecraft:potion 64

Linked issues

relates to 1

MC-105965 /give ignores stacking restrictions Resolved

Attachments

Comments 15

marcono1234 2017-05-04T20:30:31Z

This applies to /give as well and is very likely intended. Otherwise unpredicted behavior like MC-114271 can happen.

Piyotato 2017-05-21T12:54:17Z

Is it possible to reopen this? Unpredicted behaviour as you mentioned is acceptable, but not being able to stack items this way is rather irritating and cannot be done by commands anymore. This breaks so many adventure/pvp/whatever maps out there. Can this be brought to attention?

SunCat 2017-05-21T13:01:34Z

This behavior was never really supported, and developers can do with unsupported behavior whatever they want. Even remove it.
You can still /summon or /entitydata an armor_stand that holds any amount of items, though.

Anyway, this is not a discussion forum, so, please, don't answer on this message

Piyotato 2017-05-21T13:03:43Z

MC-105965 this was also marked as "works as intended", and this is rather conflicting.

SunCat 2017-05-21T13:09:38Z

What was intended before, can become unintended later.

5 more comments

Piyotato 2017-05-21T21:45:29Z

I would just like to ask if it was marked as working as intended by a developer or a moderator as I feel that the developers would not unnecessarily mapmaking functionality without providing a good reason 😞

SunCat 2017-05-21T22:02:25Z

You can look at the history. Also, if there's assignee, then the resolution was (most likely) approved by that assigned developer

Piyotato 2017-05-21T22:21:47Z

Is there really no case for reopening this one? I'm sure that once more mapmakers start to update their maps for 1.12 they'll realize that there's a compromise of previously capabilities.

TheMinecraftNerd2017 2017-06-07T21:58:18Z

I am a mapmaker, and now I have to redo a lot of my Command Blocks because of this pointless and unnecessary change. Mojang actually made /give and /replaceitem able to bypass the item stack limits in a previous update, which means it was technically intentional. And before that change, /give would just place the items into separate slots.

Now, mapmakers have to go ahead and put in multiple commands that do the exact same thing if they want to player to receive more than one unstackable item at any single time. Which means functions and command block chains will not be a lot longer than before.

If Mojang did not intend for the commands to bypass the stack-size restrictions, then why did they allow /give and /replaceitem to do so in an update as an intended feature? And why did they never actually tell us the change was official? So they could push us towards using functions?

user-f2760 2017-06-07T22:08:36Z

Not getting reopened, this decision is final.

TheMinecraftNerd2017 2017-06-07T22:10:11Z

I know it is not getting re-opened, but why would they put a change in like this that literally breaks almost every map?

user-f2760 2017-06-07T22:12:20Z

Now you're just exaggerating; map makers have been made aware of this change, and map makers need to keep their own content up to date. If mojang changes something that breaks maps, too bad, wait for the map maker to update it.

TheMinecraftNerd2017 2017-06-07T22:18:57Z

If they were made aware, then why is there nothing about this change in the change-log?

I don't stay up-to-date on snapshots, and I am certainly not going to test out every single snapshot and risk my maps becoming corrupted.

Piyotato 2017-06-08T14:40:01Z

I face a similar circumstance. There has yet been a satisfying, rational reason that they have provided that this change was made. Furthermore, the fact that this change hasn't even been mentioned in any changelog is suspicious and characteristic of an accidental change. I understand that the report has been marked as works as intended, but there surely is the chance that it has been marked so by a mod, and seeing it as marked, Grum skimmed over it even though it was assigned to him?

SunCat 2017-06-08T15:03:53Z

@unknown, look into the history tab:

@unknown made changes - 05/May/17 10:00 AM

Field	Original Value	New Value
Resolution		Works As Intended [ 6 ]
Assignee		[Mojang] Grum (Erik Broes) [ grum ]
Status	Open [ 1 ]	Resolved [ 5 ]

So, the ticket was resolved by Grum himself