Slimes/magma cube with NoAI-Tag still can damage the player

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.

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.

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.

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

Thank you Kumasasa (my favourite Mod 😸)

😃

cool decision!

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

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

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 }=)

@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 :)

Relates to MC-65664

Confirmed for

• 15w45a

Confirmed for 15w51b.

Confirmed for 16w02a.

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

Confirmed for 1.9

Confirmed for 1.9.1-pre3.

Confirmed for 1.9.2.

Confirmed for 1.9.3-pre1

Confirmed for 1.9.3-pre2

Confirmed for 1.9.3-pre3.

Confirmed for 1.9.4.

Confirmed for 16w20a.

Confirmed for 16w21a.

Confirmed for 16w21b.

Confirmed for 1.10-pre1.

Confirmed for 1.10-pre2.

Confirmed for 1.10.

Confirmed for 1.10.1.

The same also happens with Magma Cubes.

Can confirm for MC 1.12.1.

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.

Affects 18w22c