The /summon (potion) effects for mobs: speed and slowness

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

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

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.

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

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

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

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

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)

Present in 14w06b.

Confirmed for 14w08a

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

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.

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

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.

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

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

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.

Confirmed for

• 14w29b

• 14w30c

• 14w31a

• Minecraft 1.8-pre 1

Confirmed in 1.8.

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.

@@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}]}}]}

Confirmed in 1.8.1-pre2.

Confirmed for pre3 and 4

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.

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

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"}]}

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

Confirmed up to 15w38a.

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

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

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

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

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.

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.

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

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

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

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

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.

@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!

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