[MC-32575] The /summon (potion) effects for mobs: speed and slowness

With the new command /summon, some (potion) effects that can be added to a mob, are not functional (as I believe).

I was attempting to /summon mobs with potion effects on my multiplayer minecraft server. I was doing this with command blocks. All potion effects worked and were added successfully except speed and slowness.

To recreate this:
1. Put the command:

/summon Cow ~0 ~1 ~0 {ActiveEffects:[{Id:1,Amplifier:10,Duration:100000,Ambient:0,ShowParticles:1}]}

in a command block.
2. Activate the command block.

I am unsure of whether this is intended or bug. Thank you!

Linked issues

is duplicated by 22

MC-30685 Minecraft - Mob Speed Effect Bug Resolved

MC-30763 Dodgy slowness potion effect on mobs Resolved

MC-47220 Villager Slowness/Speed Effect bug Resolved

MC-48336 Bats still move with slowness effect 7 Resolved

MC-54601 Slowness effect does not work Resolved

17 more links

relates to 1

MC-33110 Spiders (and some other mobs) are not affected by speed effects or movementSpeed attributes Resolved

Comments 41

Vasil Bochev 2013-10-05T08:36:11Z

I noticed the same problem...some potion effects do not work at all on mobs. Absorption and extra health are among those as well.

Thomas Oßwald 2013-10-12T21:15:44Z

Confirmed for 13w41b
The potion particle effect on the mob is even displaying the right color. Throwing another potion at the mob with lower amplifier/time at the mob seems to activate the effect.
This could be used as a workaround:

/summon ThrownPotion ~0 ~1 ~0 {Potion:{id:373,Damage:1337,Count:1,tag:{CustomPotionEffects:[{Id:2,Amplifier:0,Duration:100}]}}}

Ezekiel 2013-11-27T20:47:18Z

Is this still a concern in the latest Minecraft version 13w48b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Jason 2013-11-30T22:26:42Z

Yes, this bug still exists in 13w38b and in minecraft 1.7.2

Skylinerw 2013-12-21T09:45:52Z

Still present in 1.7.4. As well, another bug report exists but also includes information regarding the movementSpeed attribute: https://mojang.atlassian.net/browse/MC-33110

31 more comments

Skylinerw 2014-01-10T07:03:39Z

Present in 13w02a/b/c, but with a slight twist: mobs summoned with the speed and slowness effect using NBT tags will not gain the speed, but if they are given the effect through the /effect command using the new @e selector, the speed does work:

/effect @e 1 100 10

Squid Eevee 2014-01-18T20:52:34Z

I'm having this exact same problem and it really annoys me.

clamlol 2014-01-18T21:01:37Z

Same as MC-30763. A workaround is to summon them with different generic.movementSpeeds, or to summon a custom thrown potion along with them (since effects from potions still apply)

Skylinerw 2014-02-08T18:56:44Z

Present in 14w06b.

EscoreFairplay 2014-02-21T06:06:50Z

Confirmed for 14w08a

Onik 2014-02-24T14:52:03Z

Confirmed for 14w08a too!
Why didn't they fixed it yet?!

midder 2014-02-24T15:08:31Z

This. Also, attributes doesnt work in 14w08a too, so you can only slow down/speed up mobs by the command /effect and throwing potions at them.

BanzaiBrigade 2014-04-25T23:53:54Z

This is still a problem in the most recent snapshot (14w17a). Still no fix despite it being over 7 months old?

EscoreFairplay 2014-04-28T23:28:43Z

Some bugs seem to never get looked at. But luckily suggestions like "we need stone in more different colors" will be looked at instantly. Yay! No offense though.

Joaquin Ortiz 2014-05-04T23:08:59Z

Confirmed, a workaround is to use /effect on these mobs instead.

EscoreFairplay 2014-05-05T09:15:55Z

slowness effect does not effect bats unfortunately, as they fly :/

Mackenzie McClane 2014-05-16T00:23:18Z

This is still in the game and is kind of ruining my explosion effects, cause invisiblity doesn't work and so my creepers aren't hidden.

marcono1234 2014-07-18T20:24:38Z

Confirmed for

14w29b
14w30c
14w31a
Minecraft 1.8-pre 1

Sonicwave 2014-09-21T04:42:43Z

Confirmed in 1.8.

MGMX 2014-10-21T16:19:47Z

Even trying to add the effect using /entitydata (E.G: /entitydata @e[type=Zombie] {ActiveEffects:[{Id:2,Amplifier:100,Duration:300,Ambience:0}]} ) does not work.

The only way to apply slowness to a mob it's by throwing potion.

BoxFigs 2014-10-21T18:24:44Z

@@unknown: No, /effect is another way.

Also, if you're looking to make a mob not move at all, just use an AttributeModifier, like this:

/summon Zombie ~ ~ ~ {Equipment:[{},{},{},{},{id:stick,tag:{AttributeModifiers:[{AttributeName:generic.movementSpeed,Name:slow,Amount:-1,UUIDMost:2,UUIDLeast:1}]}}]}

Sonicwave 2014-10-22T04:08:25Z

Confirmed in 1.8.1-pre2.

Gamma 2014-11-16T23:40:12Z

Confirmed for pre3 and 4

Gamma 2014-11-22T09:16:25Z

Confirmed for pre 5
with command:
/summon Zombie ~ ~1 ~ {Invulnerable:1,PresistenceRequired:1,ActiveEffects:[3:{Id:2,Duration:32768,Amplifier:14},1:{Id:14,Duration:32768,Amplifier:1}],Silent:1,IsBaby:0}
Zombie is invisible.

Zombie gets slowed( imobile because slowness 14) after a speed or slowness potion is trown at it.

KingSupernova 2014-12-18T03:21:54Z

Confirmed for 1.8.1. The bug only occurs with the summon command, the effect command works fine.

marcono1234 2015-05-24T17:13:59Z

Confirmed for

1.8.5

Command

/summon Cow ~0 ~1 ~0 {ActiveEffects:[{Id:2b,Amplifier:100b,Duration:100000,Ambient:0b}]}

Possible reason

Slowness and speed both directly affect other attributes. It seems like they only work when they are listed as attributes as well:

Effect added with summon

ActiveEffects:[
	{
		Ambient:0b,
		Amplifier:100b,
		Duration:99874,
		Id:2b,
		ShowParticles:1b
	}
],
Attributes:[
	{
		Base:10.0d,
		Name:"generic.maxHealth"
	},
	{
		Base:0.0d,
		Name:"generic.knockbackResistance"
	},
	{
		Base:0.20000000298023224d,
		Name:"generic.movementSpeed"
	},
	{
		Base:16.0d,
		Name:"generic.followRange"
	}
]

Effect added with potion

ActiveEffects:[
	{
		Ambient:0b,
		Amplifier:0b,
		Duration:709,
		Id:2b,
		ShowParticles:1b
	}
],
Attributes:[
	{
		Base:10.0d,
		Name:"generic.maxHealth"
	},
	{
		Base:0.0d,
		Name:"generic.knockbackResistance"
	},
	{
		Base:0.20000000298d,
		Modifiers:[
			{
				Amount:-0.15000000596d,
				Name:"potion.moveSlowdown 0",
				Operation:2,
				UUIDLeast:-7778190119041365872l,
				UUIDMost:8144722948526719024l
			}
		],
		Name:"generic.movementSpeed"
	},
	{
		Base:16.0d,
		Name:"generic.followRange"
	}
]

So this command would probably create the wanted effect:

/summon Cow ~0 ~1 ~0 {ActiveEffects:[{Id:2b,Amplifier:100b,Duration:100000}],Attributes:[{Base:0.20000000298d,Modifiers:[{Amount:-15.150000602009612d,Name:"potion.moveSlowdown 100",Operation:2,UUIDLeast:0,UUIDMost:1}],Name:"generic.movementSpeed"}]}

Aerotactics 2015-08-15T09:32:44Z

Thanks @Marcono1234! Surprised this is still a bug in the current version.

Skylinerw 2015-09-17T11:18:44Z

Confirmed up to 15w38a.

Meri Diana 2016-01-06T21:14:50Z

Confirmed for 15w51b/latest 1.9 Snapshot.
(Moving this comment to MC-40949)
~~generic.movement.speed also still not working.~~

~~@ Mods: Is there another bugpost regarding the attributes like generic.movementSpeed, or is this here with the title about effects the host for basically both issues?~~
~~If so, could the title be maybe altered so it's clear that it also applies to those attributes, not only potion effects?~~
~~I'm glad I found this bugpost regardless 😸~~

~~I tested this command in 15w51b, without success (Bat is still moving normally fast):~~

summon Bat ~ ~ ~ {Tags:[LLPartShow,PartBat],Attributes:[{Name:generic.movementSpeed,Base:0.05}],Invulnerable:1,Silent:1,ActiveEffects:[{Id:14,Amplifier:0,Duration:630720000,ShowParticles:0b}]}-

Edit: I tested @unknown's workaround, and it seems to work on Cows, but apparently not on Bats }=/

Kind regards, Meri

Skylinerw 2016-01-06T21:23:18Z

@@unknown The movementSpeed attribute works for most mobs; it's the flying/swimming ones that are unaffected by any speed modifiers (MC-40949 covers that). For this report, the "ActiveEffects" tag applying speed or slowness does nothing for any mob, with generic.movementSpeed being the more precise work-around.

Meri Diana 2016-01-06T21:31:14Z

Thanks @unknown!
I'll look into the other bugpost and add my comment there then 😸

Meri Diana 2016-01-11T14:56:59Z

"Works as Intended" because a major portion of code for mobs has to be rewritten sometime in the future for it to be possible?
Can't understand otherwise how this should be intended.

KingSupernova 2016-01-11T20:11:48Z

Mojang often uses "Works as intended" on issues that are obviously bugs. It's less embarrassing to say that this is how they wanted it to work then to say that they won't fix it.

Dlawso the Really Lucky Rabbit 2016-01-12T00:17:34Z

Mojang often uses "Works as intended" on issues that are obviously bugs.

Looks like a little snippet of saying that Mojang sucks when resolving bug reports not under your preferred resolution.

Meri Diana 2016-01-12T04:45:29Z

@unknown That's absurd, not the point I was getting at.
As Mod Torabi explained here https://bugs.mojang.com/browse/MC-88099?focusedCommentId=247684&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-247684 there are 2 basic motivations to resolve a bug as "WaI".
My reply to him already contains what I mean: https://bugs.mojang.com/browse/MC-88099?focusedCommentId=247814&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-247814

The heritage of that old bad MC code is not a good one from what I've heard, and fixing bugs in this insufficient + messy code cannot be always an easy task.
And they're doing it "on the fly" while the game is actively being played - it's not easy.

I just wish there'd be an additional status that expresses something like "CAN'T get fixed (YET - but will be naturally fixed as soon as all the old bad code has been rewritten)".

That way such snide/negative remarks from bughunters who can't know what is going on behind the stage could be prevented, the Devs would get less hate, the mods had at least mentally a less stressful job here, and me, trying to soothe the community, would not become an annoyance in "WaI"-resolved bugs.

Ever since Torabi explained it I'm super chill, understanding, and just being a pest in trying to figure out which type of "WaI" a bug, that's important to be solved from my personal or the community's perspective, is.
If it's a "can't get fixed yet", I'm understanding, chill and patient.
If it's a "No, we really mean it, we want it that way" and I object their opinion, then I will argue.
That was the sole reason for my comment.

More clarity, more transparency, a different resolved-reason would really lead to less stress on all sides and bigger patience.

marcono1234 2016-01-12T17:24:09Z

I can agree with this being WAI because when the ActiveEffects tag modifies the Attributes tag that is kind of a suprise (which should not be the case). In general the problem might be that these effects have to create modifiers for the attribute. The fact that these modifiers exist is fine, but effects should probably not stored as modifiers (in my opinion).

Meri Diana 2016-01-12T17:55:58Z

From someone who's not so deep into (MC) coding, or any generic user's perspective, it seems somewhat strange and inconsistent if some potion effects do affect mobs, but that there are also exceptions, which is illogical - from a generic user's perspective (including myself), I'm sure you can get my point.
So if a WaI is indeed justified, it'd be good to get an explanation that all "generic non-coding users" can understand easily, so they are understanding and not upset about such a decision.

In any case, I hope that at least https://bugs.mojang.com/browse/MC-40949 will not be a WaI in the end - if we cannot properly address all mobs and not give them all possible attributes equally, it'll end up not only minimizing the possibilities we have, but also become confusing (I personally feel confused about such apparent inconsistencies and I know I am not the only one), and confusion leads often to disappointment and anger, and that's something that shouldn't be, if possible, so we can continue to be an overall awesome game community with a warm atmosphere.

To not know or understand something often leads to misunderstandings and thus problems that could have been prevented if handled properly beforehand (as I said: clarity + transparency).

I apologize if I may come off sometimes rude or demanding, but I truly only got the good for Minecraft and its community in mind, I don't like the "bad vibrations" I can feel/read from "the generic (uninformed) user", thus I'm being a bit persistent and very direct and honest to raise awareness and understanding on all sides, and lessen anger/hate by argumenting why a decision is a good decision (as soon as someone would actually explain it so I can get it).

Torabi 2016-01-12T18:11:41Z

By definition, Mojang has the exclusive capability to determine their own intentions, and thus whether any particular behavior is a bug or not. They could intend for the game to crash, erase your hard drive, or set your computer on fire. It might be illegal to distribute such software to unaware parties, but it would still be their right to call it "Works As Intended". Whether anyone else likes the behavior is irrelevant.

That said, "Works As Intended" doesn't mean that the current behavior is completely true to their vision. In some cases, "Works As Designed" would be more accurate, that the behavior is as close to their intentions as is currently possible. It may require an extensive design change, it may have dependencies that they're not ready to require (hardware features, java or library versions, etc.), it may have performance tradeoffs that they're not willing to accept, or it may just be impossible. "Won't Fix" may be appropriate for some of those situations, but when the system as a whole simply has to work the way it does, or there are intractable flaws with the alternatives, then "Works As Intended" is the correct resolution. Lag, for instance, is probably never intended by a software developer, but may be an unavoidable consequence of how other things have to work in order to do what they do. The system may be "Working As Intended", even if they don't like all the consequences of the design.

A developer may not interpret a report the way the reporter intended it. That's the nature of communication, particularly with the difference in perspectives between an end user and the developer. The end user is focused on the behavior, while the developer is focused on the code. Marking a report as "Works As Intended" doesn't always mean that the behavior is intended. Sometimes it just means that the code is working correctly, and that achieving the desired behavior would require redesigning other code. The individual pieces may do exactly what they're supposed to do, and it's not sufficient to produce the desired behavior. At that point, however, it's an enhancement or feature request, not a bug.

I'd have to go poking around in the code to be sure, but in this case, it would appear that speed and slowness are essentially just visual "dummy" effects, and that the actual effect is produced by applying attribute modifiers. Commands such as summon don't provide a lot of hand-holding – you have to follow internal formats and reproduce effects in the same way the game handles them. It may not be ideal, but changing it would require redesigning a system that already works, requiring a not-insubstantial effort – for no benefit for the average player. They may address this in the future, either through improvements to the commands, or in improving the effects and attributes systems. Either way, it's an enhancement, not a bug. @unknown's "workaround" is likely not a workaround at all, but simply the correct way to produce the desired effect using the systems as they currently are designed.

In short, the resolution field doesn't provide a lot of context on its own. Developer comments explaining exactly what is intended and what is not would be nice, but are not always a reasonable expenditure of their time. I'd say it's obvious that speed and slowness are supposed to work on mobs, because they do when applied through normal game mechanics, such as throwing splash potions at them. In this case, "Works As Intended" should not be interpreted as meaning "Speed and slowness are not intended to work on mobs", but instead "The potions work a certain way, and if you want to reproduce their effects using commands, you must provide the necessary data."

Skylinerw 2016-01-12T21:00:58Z

I can agree with this being WAI because when the ActiveEffects tag modifies the Attributes tag that is kind of a suprise (which should not be the case). In general the problem might be that these effects have to create modifiers for the attribute.

That appears to be the correct observation. The only other effects that change attributes that mobs have, being Strength & Weakness (for generic.attackDamage) and Health Boost (for generic.maxHealth), also do not work. I externally modified my player.dat file to give myself Luck and Unluck in ActiveEffects and it had the same result. MC-71977 covers health and strength-based effects, but the underlying issue indeed is that any effects that change attributes are ineffective via /summon and ActiveEffects.

Meri Diana 2016-01-13T05:22:40Z

@unknown Always a delight to read your comments, thanks a lot for the effort, the time you put in.
It makes it so much easier for me to explain such things to upset people (me, being not a native nor really eloquent English speaker and too awkward to begin with).

I already did understand the general WaI-issue from your first post I was referring to, but it can't be stressed enough.
The more people know about it, the less mean comments or "bad vibrations" will arise in the future.

Developer comments explaining exactly what is intended and what is not would be nice, but are not always a reasonable expenditure of their time.

I don't expect any of the developers to waste their time on a reply, I rather have them more bugs fixed - but I hoped that any of the mods or very experienced people would reply and explain, and that hope wasn't in vain, thank you };] <3

@unknown's "workaround" doesn't work for bats by the way (I'm sure I tested it correctly), but thanks to what he and even more so @unknown said I completely understand the problem with effects versus attributes, and why it can be considered as "works as intended".
I hope fixing attributes for flying + swimming mobs will be possible, but if not I'll keep in mind what you wrote (and I already knew thanks to you) about the current code situation.

If it's sure that it will be fixed someday when all the code is rewritten then it's just a matter of time.
I play Minecraft since 2010, I don't mind waiting as long as I know it's not futile };]

So, again a huge thank you to you all also on behalf of others for taking your time and explaining it.
Take care!

clamlol 2024-01-27T06:35:10Z

Here's an updated command for anyone who wants to test this "feature" in recent versions:

/summon cow ~ ~ ~ {active_effects:[{id:"minecraft:speed",amplifier:10b,duration:-1,ambient:0b,show_particles:1b}]}

And for clarity, this issue occurs with any effect which modifies an attribute, including strength, weakness, health boost, absorption luck and bad luck. (It may also affect jump boost on horses, since they have an attribute for that, but I haven't tested this myself.)