[MC-136152] Placing mob spawner renders a pig for up to a second

The bug

In current versions:

/give @p spawner{BlockEntityTag:{SpawnData:{entity:{id:creeper}},Delay:10000}}

results in the mob spawner rendering pig for 0.1-1 full second before going back to the right render of the specified mob.

In older versions between 1.8-1.8.1 for sure this did not occur.
In 1.8.1:

/give @p spawner{BlockEntityTag:{EntityId:Creeper,Delay:10000}}

Solutions

Make blank spawners always blank (force people to use pig spawners with the blockdata). Then it simply won't render till the client gets its data. I don't recommend this approach as it's not instant when the client already has the data of nbt from the itemstack. I recommend the below solution.

Backport code to 1.8 where the blockentitytag was placed on both client and server side note that 1.8 had an issue with render as well not noticeable until porting the code to spawners newer then 1.10 where horses will render two different models only to the person placing the spawner. This is fixed by the server not sending a packet to the placer if a block entity tag was placed but, everyone else should get the packet.

Attachments

22w44a try1.mp4

MC-136152.mp4

Comments 20

kumasasa 2018-08-18T09:06:34Z

The pig isn't shown for one second, more for one tick.

jredfox 2018-08-25T19:14:07Z

yes it is look closely after placing 10 spawners really fast it renders a different model and pink for example place a parrot spawner on a server with lag you will see the pig every time. Although I had to deal with fixing this bug so I notice it everytime but, in order for you to notice it fully experience lag it renders pig the first tick to 0.3 seconds at least sometimes before it renders the proper entity.

Anyways just posted pics for you to view I had to clutch it since it does correct itself in < 1 second usually but, it's about 1 second in 1.13+

Yes this is vanilla I do not say otherwise until after I test it.

[Bot] Arisa 2018-08-25T19:44:30Z

Please do not mark unreleased versions as affected.
You don't have access to them yet.

kumasasa 2018-08-25T19:53:13Z

As I said, it's around a split second, maybe on tick for me in 1.13.1

jredfox 2018-08-25T19:56:15Z

well 1 second is the max but, it shouldn't render improperly at all.

10 more comments

jredfox 2018-09-02T16:59:40Z

I fixed this using base class edits via asm in a couple classes. first off you need to be able to place it on both sides, second there is an issue with NetHandlerPlayServer#onTryUseItemOnBlock() where it sends a blockstate packets back when it wasn't successful with the main hand causing your tile entity to reset data momentarily when placing in the offhand. The third issue is if the tile entity is instanceof tile entity mob spawner you as the placer need to ignore the next packet getting sent from the server to your client as it's already rendering properly on your client and letting the packet readFromNBT() would reset the render flashing between two different horse models.

I recommend adding a new boolean method for the tile entity called ignoreNextPacketOnPlacement() that way it could be dynamic and not hard coded when seeing if on placement you should ignore the next packet.

NetHandlerPlayServer#onTryUseItemOnBlock() 
if(res = EnumActionResault.sucessfull || hand == EnumHand.offhand) sendpackets else do nothing

the tile entity update packet have a client only list of blockpos which will ignore the next incoming packet then remove it once received if tileentity.ignoreNextPacketOnPlacement(). Make sure the ignoring blockpos placement is only added to the placer only.

on the itemblock have it fired on both sides for placement and setting the tile nbt. If it fails you may need to send a packet from client to server telling you to reset the spawner on your end.

jredfox 2018-10-04T23:46:42Z

I don't mean to rush things but, I specified in great detail all issues causing the display issue. If you give me the mojang source I could even manually apply the fixes via pull request. I know mojang hasn't released it yet officially but, I could show you forge's version if you need to see the fixes across multiple classes.

Oval 2018-10-22T00:58:09Z

Confirmed for 1.13.2-pre2.

Oval 2018-10-22T00:59:08Z

Confirmed for 1.13.2-pre2.

Avoma 2020-12-16T17:19:15Z

Can confirm in 20w49a.

Avoma 2020-12-25T18:11:55Z

Can confirm in 20w51a.

Avoma 2021-02-10T13:02:57Z

Can confirm in 21w05b.

Avoma 2021-03-01T16:18:03Z

Can confirm in 1.16.5 and 21w08b.

Avoma 2021-06-14T18:42:20Z

Can confirm in 1.17.

Avoma 2021-07-07T17:49:34Z

Can confirm in 1.17.1.

Avoma 2022-06-29T12:46:36Z

Can confirm in 1.19.

Avoma 2022-10-18T15:27:24Z

Can confirm in 1.19.2.

Avoma 2022-11-02T17:38:00Z

I'm pretty sure that this issue has been fixed in 22w44a, though it's slightly hard to tell due to the nature of this bug only occurring for a split second. I've tried to recreate the observed behavior for only five minutes now, only to be unsuccessful. Would someone mind reinforcing my claim here and double-checking if this problem has been fixed? I'd greatly appreciate it; thank you! 🙂

Rabrun 2022-11-05T13:52:19Z

I tested it on a pretty bad laptop in 22w44a about 15-20 times and didn´t find a single frame of pig, so I think I can say it´s resolved 🙂 I attached the mp4 in the files, but I had to cut it short to match the max file size

Avoma 2022-11-05T14:02:51Z

Alright; sweet. I'll put in a request for this ticket to be resolved as fixed in the Mojira Discord. Just for clarity, this issue was present in 22w43a, but no longer occurs in 22w44a, meaning that this problem was fixed in 22w44a.