Blaze Entity shakes in TESR

I'm confused why you say this isn't a duplicate of MC-111339; the blaze case is already mentioned on there (as one where it's animating on ticksExisted and partialTicks, and ticksExisted doesn't change while partialTicks does – the stutter is from it interpolating with partialTicks unless I'm misunderstanding what you're reporting)

bold = important
I repeat this is not MC-111339*. This has to do with the blaze rotating inside of the spawner flashing back and forth. It's not suppose to flicker when rotating at all *since there is no animation it shoulder render without any flickering

yes animating the spawner will in fact fix this bug but, I see no attempt to animate all entities(as the report stated a whitelist) in the spawners yet almost as if it's not suppose to because it's an intended feature to not animate all entities inside of a spawner. If that's the case then this is a separate issue. 

However if blaze is planned to be on a whitelist of animated mobs in a spawner or they animate all entities then this issue get's closed. Thanks for understanding.

I specifically call that out in that ticket (bold added here, and yes it indicates that it's important):

Suggested fix

There is no real good fix for this, but the best fix I can come up with is tweaking the way spawners render so that when the spawner is spinning, ticksExisted is updated, and when it is not spinning, partialTicks is always set to 0. That way, the animations play normally when the spawner is spinning, and when it isn't spinning, it doesn't attempt to animate a nonexistent animation.

Yes, there should be no animation for the spawner, but the entity is animated. And the bug, to my understanding, is that the animated entity's animation is being applied when it shouldn't be.

I don't see how the second half of my fix doesn't solve this issue, by freezing the entity when it's not rotating.

Also, I'm not aware of any sort of whitelist of mobs to special-case animation; the list in the issue is just places it can be seen.

your fix would force the render of the blaze to rotate it's wind chimes.

the question before you close it you have to ask yourself is: does mojang intent want the spawner mob of blaze to be animated or simply rotated? If animated then yes do your fix if not this is a special case. If they are only going to animate specified entities inside of the spawner or everything. if specified they need to fix the entity blaze's renderer else they need to do your thing.

Now the issue you brought up and I found is this: you can't tell what jeb_ sheep is until they actually spawn. I agree with you that that needs to be fixed but, I cannot fully agree until mojang takes a look and says do we want to animate mobs in mob spawners fully?

My solution to this issue for silkspawners is this:
forge config option animated items and animated blocks for the entities able to configure on and off but, mojang would have to add a new video setting or new gui would be a pian for them

As for the actual fix for this issue I hard coded if is entity blaze and !config.animationSpawner in the block form then render partial ticks 0 always. Now the more proper fix would be to go into the entity render of blaze and fix it

Oh, I see what I'm misunderstanding here: in this case, the spawner is rotating (and the player is in a gamemode other than spectator), but the rotation is happening very slowly due to the high delay. I did address the case of spinning spawners in MC-111339, but I only provided reproduction steps using cheat engine which are much more awkward to use.

That's supposed to be solved by the first half, where ticksExisted is increased so it can animate for most entities as they're spinning (those with the ✔ ), but it could equally be solved by also always setting partialTicks to 0 in all cases when rendering the inner entity.

again tickExsisted++ would force the blaze windchims to rotate around the spawner and be fully animated while it does it's spinning based on delay as well does mojang want this? So basically you got one animation forced with chimes then you got another animation really fast both rendering at the same time. Also if they decided to do jockey render it wouldn't be cached Entities it would be an array of all recursive passengers and the entity base

In some cases it looks cool but, in others it makes the animation worse since the spawner on the ground is spinning really fast.

now nei has this implementation yes it looks better when the delay is very high but, looks worse when on the ground for alot of animated mobs sometimes. 

So is the proper fix ticksExisted++ or only do a specified whitelist of mobs to do ticks+? Or fix this said issue reported here and issues with rendering the shulker and do a new method called animationUpdateSpawner() where default is nothing but, on stuff like sheep and creeper ticksExisted+ if the entities world isn't null?

Ok fine if you want to merge the two issues go ahead but, have two solutions one animate everything two being animate whitelist everything and if blaze isn't on there say you need to fix it's render. Go ahead and close this. I also misread your title I thought you said spawners had no animation meaning it was more specific derp 😞

Also the shulker seems to need onInitialSpawnCall() before rendering no matter what it's broken. ticksExisted++ doesn't fix it as the render and/or the entity need to be patched. my solution for silkspawners was to always call onInitialSpawn() and make sure it never gets ticksExsited++ or it will start shaking again very broken render. 

Resolved. I'll look over other entities and add more info to the solution later. Sorry for the confusion.