An alternative description is provided in MC-72774.
Code analysis by @unknown here in this comment, he narrowed down the apparent issue of this bug.
Using the new EntityTag feature for custom spawn eggs, I created spawn eggs summoning a Squid with the invisibility potion effect, but while I was demonstrating the "Tags" tag by placing the spawn eggs against a barrierblock, one Squid popped into my face ;_;
Give-command for a custom squid spawn egg:
/give @s minecraft:squid_spawn_egg{EntityTag:{Glowing:1b,NoAI:1b,CustomName:'{"text":"Invisible","color":"dark_blue","bold":true,"italic":true,"underlined":true}',active_effects:[{id:invisibility,amplifier:1b,duration:1200,show_particles:1b}]}}It seems that the effect is not always (or generally?) applied immediately.
In current snapshot 20w12a it is visible each single time I use the spawn egg; that has not been always the case, e.g. back in 2015.
The Squid appears for about 1 tick.
[media]This seems to generally apply to every changes that you'd summon an entity with, e.g. also Rotation value:
/summon mooshroom ~ ~1.5 ~ {CustomName:"RandomUUIDCow",CustomNameVisible:1,Rotation:[270f,0f],NoAI:1,Silent:1}The summoned Mooshroom needed 2 ticks to get into the 270°-positioning.
The default position an entity "looks" - including the player in a newly generated world - is always South, and also that Mooshroom in this example looks at South first before it gets turned into the desired position.
As that's the confirmed case now, the title should be changed, but I'll leave this to the experienced mods to find a title which can describe the totality of the problem }=)
Linked issues
is duplicated by 7
MC-77152
Summoned invisible entities are visible for 1 frame/tick
Resolved
MC-100080
Invisible effect doesn't apply to creepers with 0 fuse
Resolved
MC-101073
Hitbox of Marker Armorstand is incorrect in the tick it is summoned
Resolved
MC-137714
Bug with /summon invisible
Resolved
MC-164303
Summoning invisible entity cause them to render one frame
Resolved
relates to 4
MC-268497
Fire animation isn't shown on the first tick
Open
MC-262213
Baby sniffer's head is smaller on the first frame of existing
Resolved
MC-221658
Axolotl appears pink for a second when releasing different color axolotls from buckets
Open
MC-188497
AngerTime and AngryAt cannot be set on summon
Resolved
Attachments
Comments 40
Thank you Nasm, it seems to be related, indeed!
Not sure if "EntityTag" and custom spawn eggs also should be consideres as own issue, as it's a new tag for entities/spawn eggs, but in the end it might be just the summon after all, or rather that they don't always have their specific attributes assigned to them in the very first tick of their existence.
I'll update my bugpost }=)
Made this the new base ticket, because here is the cause of the behaviour described.
I have updated MC-72774 with new information and will continue to do so as I explore this bug further. Please make it the primary report.
This is not a "fight about who owns a bug report", it is about fixing bugs.
As I'm frequently dealing with mobs for contraptions/inventions, I also plan to add more information if I find out anything new.
I'm not a fan of quarrels on that level, I'll leave it to the mods.
I only want this to be fixed, if possible.
Regards, Meri
"I don't think entities have any nbt in their first tick of existance."
This is incorrect as the EntityTag data and NBT from /summon is applied to an instantiated entity class first before the entity itself is spawned in the world. For instance, with /summon, the createEntityFromNBT() function is called first using NBT from input, and is then followed by spawnEntityInWorld(). The mobs should theoretically be invisible before spawned, and while that's the case almost every time for me, I'll get a rare "flash" of a visible mob before it disappears.
It's more likely to do with potion and rendering updates than NBT. Quick check in MCP shows that stored effects are one of the last things updated when an entity is ticked (and by the looks of it, while the effects are read from NBT right away, they essentially do nothing until the entity is ticked for the first time). Needs a much more keen eye than mine to get down to the bottom of what really causes it, though.
It seems that this is caused by the packets send. First a S0FPacketSpawnMob (MCP 1.8 names) is send, however apparently this packet does not contain the effect information (this is probably the bug) and after that a S1CPacketEntityMetadata packet which contains the information about whether or not the entity is invisible.
To fix this before the entity gets summoned the potion particle, ambient and invisibility flags need to be updated. This can be done by calling the method func_175135_B() of the net.minecraft.entity.EntityLivingBase class (the fire flag seems to be set correctly). This could be done from the func_151260_c() method of the net.minecraft.entity.EntityTrackerEntry class.
private Packet func_151260_c()
{
if (this.trackedEntity.isDead)
{
logger.warn("Fetching addPacket for removed entity");
}
if (this.trackedEntity instanceof EntityItem)
{
return new S0EPacketSpawnObject(this.trackedEntity, 2, 1);
}
//...
else if (this.trackedEntity instanceof IAnimals)
{
this.lastHeadMotion = MathHelper.floor_float(this.trackedEntity.getRotationYawHead() * 256.0F / 360.0F);
// Added the following line
((EntityLivingBase) this.trackedEntity).func_175135_B();
return new S0FPacketSpawnMob((EntityLivingBase)this.trackedEntity);
}
//...
}Note: It seems like in 1.8 in case a DataWatcher is send in a packet, the complete DataWatcher is send. What this means is it contains also the entity itself (as owner). That kind of negates every savings in respect of packet size.
Eventually the handleSpawnMob(S0FPacketSpawnMob packetIn) of the net.minecraft.client.network.NetHandlerPlayClient class should also run var10.getDataWatcher().updateWatchedObjectsFromList(var14); before the entity gets added to the world.
/**
* Spawns the mob entity at the specified location, with the specified rotation, momentum and type. Updates the
* entities Datawatchers with the entity metadata specified in the packet
*/
public void handleSpawnMob(S0FPacketSpawnMob packetIn)
{
//...
var10.setEntityId(packetIn.func_149024_d());
var10.setPositionAndRotation(var2, var4, var6, var8, var9);
var10.motionX = (double)((float)packetIn.func_149026_i() / 8000.0F);
var10.motionY = (double)((float)packetIn.func_149033_j() / 8000.0F);
var10.motionZ = (double)((float)packetIn.func_149031_k() / 8000.0F);
// Changed position
//this.clientWorldController.addEntityToWorld(packetIn.func_149024_d(), var10);
List var14 = packetIn.func_149027_c();
if (var14 != null)
{
var10.getDataWatcher().updateWatchedObjectsFromList(var14);
}
// Now runs after DataWatcher updated objects
this.clientWorldController.addEntityToWorld(packetIn.func_149024_d(), var10);
}Thank you very much @unknown and @unknown for looking into it and clearing this up, I was worried it wouldn't be really fixable, but now it seems it is }=)
I'll update my bugpost later (after work) and add a link to the comment with the code sniplets, so the Devs can see it, as soon one of them will take care of this bug.
Happy, also on behalf of all the mapmakers I heard complaining about it, so thank you again for your help };]
This might affect the spectral effect as well depending on whether or not this is stored as a flag (which should be the case).
4 months ago, when they added EntityTag to spawn eggs, I created a glowing sheep, but didn't notice that its effect was applied later for at least some of them, but it would indeed make sense if it would.
I'll record the summon via custom spawn egg process soon and then go through the footage frame by frame, maybe there is evidence for it }=)
Thanks for reminding me of this effect, I totally forgot it.
Will post any conclusions for it then as soon as I got the visual results.
Edit: Just realized I already mentioned also "Glowing" etc. in my bugpost ;-;
I forgot I already did, but what I definitely didn't do was recording it to see if the effect gets applied a tick later for some of them, it's harder to spot than if an e.g. invisibility effect fails.
My duplicate MC-101073 descibes an example that should be easier and more reliable to reproduce. Hopefully it helps you out!
It's not fixed, it still affects the newest versions.
This issue is not always noticeable.
20hz summoning of invisible armor stands, only 1 per 10 seconds doesn't instantly become invisible. (at least, for me.)
@unknown It definitely is not fixed, at least 1.11.0 inclusive.
I, as the responsible one for this bugpost, would not update it to a new version if I couldn't reproduce it.
I mentioned at some point that it has gotten way better (during the 1.9-versions iirc), but it still is reproducable, albeit it can take a bit until it shows, like @unknown mentioned.
With the spawn egg incl. an ActiveEffect it was never "reliably reproduceable" in the meaning of: It never showed always (at least since the reported 15w36d), so I don't quite get what your point is?
It is still "reliably reproduceable" in the meaning of: It does show at some point.
An e.g. inserted Rotation value is still very much/immediately noticeable in most of the cases, that the entity firstly "looks" towards South, before it turns into the Rotation the spawn egg EntityTag included, maybe you want to try out that instead, if you need faster reproduceable results.
I personally focus on the ActiveEffects, but of course I occasionally also test things like that Rotation-value-problem I also mentioned in the bugpost.
In that case MC-101073 is not a duplicate and should be marked as fixed. I must admit that I didn't put that much effort into reproducing this bug, because my "duplicate" is what I was mostly interested in.
Confirmed for 1.13pre4.
Confirmed for 1.13-pre6.
Confirmed for 1.13-pre7.
Confirmed for 1.13-pre8.
This might be fixed in 1.13.At least it seems to be a lot harder to reproduce in single player.I was able to see an invisible squid, but only by pausing the game in the right moment.
But by just spawning them I wasn't able to find a single visible one in hundreds of attempts.It should be tested in multi-player as well before it actually can be considered fixed though.
@edit 1: Confirmed for 1.13.
I'm not sure why I had trouble to confirm it at first. Trying again it was really common.
@edit 2: It seems to have to do with how busy the system is. If I play a video on the same screen it seems to be much more likely to happen.
Confirmed 1.14
Confirmed for 19w45a and 19w45b
Confirmed for 1.15.1.
[media]
Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 21w07a.
Video attached.
Can confirm in 1.16.5 and 21w08b.
Can confirm in 21w11a.
Can confirm in 21w16a.
Can confirm in 1.17.1.
Can confirm in 1.18.1.
Can confirm in 1.18.2 and 22w18a.
Can confirm in 1.19.
Can confirm in 1.19.2.
Can confirm in 1.19.4.
Isn't this bug "work as intended"?
No, it's not. Why would rendering the entity incorrectly on the first frame be by design?
Priority has already been assigned a while ago, which means Mojang saw this already too. It's still open.
This bug has not been fixed for years and is still unassigned. This suggests that Mojang is either unwilling to fix this bug or is unable to fix it for technical reasons. Shouldn't the resolution for this bug be "work as intended" or "will not fix"?
Not being on the current work track != not going to get fixed. This might require a bit of a rewrite to fix that's just not a priority right now.
Age of an issue never means anything regarding it's resolution.
Sounds like MC-72774