[MC-88099] Slimes/magma cube with NoAI-Tag still can damage the player

The bug

When summoning a slime with the Tag NoAI:1b it can still damage the player.

How to reproduce

/difficulty hard
/summon slime ~ ~ ~ {Size:3,NoAI:1b}
/gamemode survival
Walk into the slime and die a slimy death 🙂

Video: https://youtu.be/ZkI3uU7hoBA?t=2m33s

Fix

Having in mind the overall AI-System this is a hack. See note below.

There is a method canDamagePlayer() in EntitySlime.java. A check can simply be added there.

EntitySlime.java (in MCP)

...
	protected boolean canDamagePlayer() {
		// Added && !this.isAIDisabled()
		return this.getSlimeSize() > 1 && !this.isAIDisabled();
	}
	...

@EDIT I didn't find MC-67667 somehow. Searges comment declares it as "Won't fix".
I still think this should be changed as damaging logically would be part of the AI, even if it's not directly inside the AI code.

:info: Note: As @unknown pointed out in his comment, this is probably not so much viewed as "Won't fix", but rather will likely get fixed properly in future by moving this part of entity behaviour to the AI-Code.
Looking at it, it looks like a simple task at the beginning, but soon you realize that it probably would make sense to relocate the EntitySlime in the class hierarchy and I think form there it will feel like this soon. It's understandable why it gets ranked less important than other issues for now.

Linked issues

is duplicated by 3

MC-87590 NoAi Slime does damage Resolved

MC-95792 NoAI&friendlyfire-false Slime/LavaSlime attack Resolved

MC-97293 Slime attacks with NoAI:1 Resolved

relates to 4

MC-67667 Slime's still damage you on NoAI Resolved

MC-75089 Slimes do not use the slot.weapon for attacks Resolved

MC-105099 Slimes & Magma Cubes can still attack players when they are in their death animation Resolved

MC-173091 Piglins with the "NoAI" tag set to 1b does not dismount the entity they are riding Resolved

Comments 30

Dlawso the Really Lucky Rabbit 2015-09-05T02:50:48Z

Unfixable per Searge on MC-67667:

Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.

sancarn 2015-09-05T03:31:00Z

It's not "unfixable" as Panda has showed... and has even done himself (he fixed it on his own in the video you probably didn't watch...)

That being said there is very good reason for this to be fixed. There have been multiple occasions as a map maker that I have needed an invisible mob of any size to detect player clicks for instance. The main thing to remember is slimes are exceptionally good for map making because of the fact they can be any size. That is so powerful and the only problem at the moment is you can't use them... Because whenever it gets near a player the player dies... Not great as a map maker.

Also might I just say, it doesn't make any sense. Every single mob does damage through AI except slimes... noAI stops every mob damaging you... except slimes. For consistency this should be implemented. The fact that many people have suggested it just goes to show that even though it does not fit to mojang's definition of a bug, to the rest of the community it is. Therefore, at least in my opinion, it should be fixed or another work around added.

kumasasa 2015-09-05T04:11:34Z

Hm, normally any "NoAI" bug get's resolved as invalid due to Mojang's Won't_fix_any_NoAI_bug policy, but since the fix is already provided here, this may remain open.

Meri Diana 2015-09-05T08:51:15Z

Thank you Kumasasa (my favourite Mod 😸), cool decision!
I just wanted to add that I do a lot of custom creations with ArmorStands and mobs, and Slimes are the ONLY mob (at the moment at least) which can be made ANY size!
It could be SO useful for mapmakers or creationists if it wouldn't hurt you!

I set myself into a team "blue" and summoned a Slime for team "blue" (in 1.9:

/summon Slime ~ ~1 ~ {Size:1,Team:"blue"}

), but it still could hurt me..
Mobs in the same team should not be able to attack you.
Not sure if I did something wrong, but my quick testteaming returned as a fail, maybe someone more awake than me could quickly check that, thank you };]

Setting their generic.attackDamage also doesn't seem to work: MC-47091

As for the "`NoAI` bug get's resolved as invalid due to Mojang's Won't_fix_any_NoAI_bug policy" (I've read Mr. Stoyke's statement about that):
If one gets features into the game one expects them to work as intended for everything.
The question is if a "works differently" is REALLY intended, or if it's just a statement to have an official "excuse" for it because there are other problems which are more important to Mojang, hence they don't want to spend time trying to fix such issues like e.g. the NoAI-problem with slimes.

Don't misunderstand me, this is not a bashing of the Devs or anything, but I just have the feeling that sometimes they hide their reasoning for some decisions under statements like these, and it would annoy or upset people less if they'd get a truthful, open answer.
Because it can feel frustrating if you put your heart into this game, creating things for others to enjoy, then also try to help find the bugs, but then get replies like these.

I hope it's understandable what I mean, and I only had to mention it because I know a couple of people feel the same, and I always try to excuse such statements with the "there are things you're not ought to know" delusion to not get upset };]
But that's only me, as I said, there are others, and I cannot tell them not to get frustrated and to not give up on the bugfinding help etc. completely, and as the community is very dear to me, I'd like to have a REAL explanation, so I'm able to calm down those being upset about such kinds of statements.

So if we could have a more detailed statement from Mojang WHY this is a "works as intended", even more if they won't implement Panda's fix suggestion, that'd be great.

Sorry for the lengthy and slightly offtopic post, but I had to get that off my chest finally.
Regards, Meri

kumasasa 2015-09-05T08:58:26Z

Thank you Kumasasa (my favourite Mod 😸)

😃

cool decision!

That's the difference between tin ass @unknown and me.

20 more comments

Torabi 2015-09-06T16:05:56Z

There are two basic motivations to declare something "Works As Intended", but only one of them is obvious to a non-programmer: the code produces the desired end result. However, in some instances, a programmer may care more about how the result is achieved than the result itself: they probably want the code to be elegant, easy to read, understand, and maintain. They may care more about performance than accuracy. Doing things the right way is sometimes more important than getting the right result. Catching corner cases can be both computationally expensive, and make it harder for them to update the code in the future without creating more bugs. If the undesired result doesn't interfere or disrupt their intended use case for the software, then it may make more sense to the programmer to not handle that corner case.

Here's the relevant history, as I understand it: The mob AI was originally built directly in the mob code, inherited when possible from one mob to another, with mob-specific behavior scattered throughout various functions. Jon Kågström was hired to write a generic artificial intelligence system, and built the basic targetting and pathfinding code before being moved over to Scrolls. Only a few mobs used this new code for a long time, with the remainder only being switched over fairly recently. However, it only handles very generic behavior, and all the unique behavior for each mob type is still buried in their respective classes, completely unconnected to the AI system, and therefore not controlled by it. The NoAI tag does one very specific thing, and that's disable the AI system for that entity. That's all it's supposed to do, and how that affect's the mob's behavior depends entirely on how much of that behavior is controlled by the AI system. From a programmer's perspective, that part's Working As Intended. The code that reads the tag, and the code that disables the mob AI work exactly as they're supposed to. The mobs just aren't designed correctly, because the AI system isn't developed enough to handle their specific behavior.

The right solution, and presumably the eventual goal, is to expand the AI system to cover a wider variety of behavior, and then rewrite the mobs to use it for all that behavior, removing all the special-case code scattered throughout their classes and consolidating it in code that interacts with the AI. That would be elegant, and far more maintainable. But the developers don't have time to do that right now: they're busy doing things like overhauling combat and the world storage format. Hacky solutions like scattering !this.isAIDisabled() checks throughout the code don't make the code more correct, even though they make it produce the desired behavior. They just increase the technical debt, make it even more work to eventually do the right thing the right way: expand and use the AI system. They're still trying to dig their way out of a massive pile of technical debt, and throwing a few shovelfuls more on top may not slow them down that much, but it still isn't going to help them get there any faster.

To summarize, @unknown has marked many of these bugs as Won't Fix, and instructed us to do the same, because they don't view them as bugs so much as features they've yet to implement. The part they have implemented works correctly. The other parts they just haven't worked on yet. They could put in ugly temporary code to make it work how people want it to, but it's not a productive use of their time. This will eventually get "fixed", not as a result of deliberately setting out to fix it specifically, but as a byproduct of restructuring the code. They have done a lot of work on entities already in the 1.9 snapshots, moving code up the inheritance chain, like how mobs hold and use items. @unknown has recently tweeted about working on the AI a few times. Maybe they'll get to upgrading the AI system in time for the 1.9 release, if @unknown stops breaking worlds with every snapshot 😉.

Meri Diana 2015-09-07T10:28:49Z

Hello Torabi, thanks a lot for your long, kind and detailed reply }=)

The other parts they just haven't worked on yet. [...]
This will eventually get "fixed", not as a result of deliberately setting out to fix it specifically, but as a byproduct of restructuring the code.

If that is the case, then there's nothing for me or anyone to complain about, I very much understand that something do have a higher priority.
if it's really solely a matter of time and it is planned to fix it sometime during a general overhaul of the code, then we can all chill };]
It will be only a little nuisance for the mapmakers in the meantime.

See, it's so easy to please us, if we get such answers }=Þ
What I mean is: The way some mods or devs express it can be misinterpreted by (really good-hearted) people from the community as "we don't care what you say, this works as intended/won't fix".
If we'd at least get to know that it is a temporary issue, that it will very likely fix someday in the future, (basically: "Won't fix YET [planned later"], then nobody would hold a grudge at all };]

That's a reply I can deliver to anybody I talked about that topic, and I'm sure it'll also make them see the situation in a better light again };]

Thank you very much again, Torabi }=)

Panda4994 2015-09-07T10:44:31Z

@unknown Thank you for clearing that up!
I guess it's not even always obvious for people with programming experience as the overall goals are not always known/communicated as you did here (It probably should have been clear looking at the developments of AI-System though).
So it's not that much "Won't Fix" but "Fix proper later".
I find that most bugs are caused by old bad code design in one way or the other. I wonder how their "code that needs to be rewritten"~~list looks like :~~)

marcono1234 2015-11-11T18:05:41Z

Relates to MC-65664

Confirmed for

15w45a

James (inactive) 2015-12-21T00:24:31Z

Confirmed for 15w51b.

James (inactive) 2016-01-13T23:12:59Z

Confirmed for 16w02a.

Brian McNamara 2016-02-11T16:15:55Z

confirmed for 16w06a (after they recently made other NoAI changes)

froggy man 2016-03-03T13:31:27Z

Confirmed for 1.9

James (inactive) 2016-03-15T23:48:47Z

Confirmed for 1.9.1-pre3.

froggy man 2016-03-30T19:18:06Z

Confirmed for 1.9.2.

froggy man 2016-04-23T12:08:55Z

Confirmed for 1.9.3-pre1

froggy man 2016-04-27T18:38:08Z

Confirmed for 1.9.3-pre2

null 2016-05-06T00:17:06Z

Confirmed for 1.9.3-pre3.

null 2016-05-11T23:24:49Z

Confirmed for 1.9.4.

null 2016-05-18T22:15:23Z

Confirmed for 16w20a.

null 2016-05-25T23:18:14Z

Confirmed for 16w21a.

null 2016-05-26T23:08:16Z

Confirmed for 16w21b.

null 2016-06-03T01:55:08Z

Confirmed for 1.10-pre1.

null 2016-06-07T23:06:15Z

Confirmed for 1.10-pre2.

null 2016-06-08T21:47:47Z

Confirmed for 1.10.

null 2016-06-22T17:11:08Z

Confirmed for 1.10.1.

Greg Milson 2016-07-14T10:00:09Z

The same also happens with Magma Cubes.

bemoty 2017-08-10T17:44:09Z

Can confirm for MC 1.12.1.

Elemend 2017-12-13T11:22:25Z

Affects 17w50a, also as mod Torabi mentioned that it gets fixed in the future, one can almost say that time is now, the technically better update is already happening.

muzikbike 2018-06-04T13:24:48Z

Affects 18w22c