| Type: | Bug | ||
| Reporter: | Connor Steppie | Assignee: | [Mojang] slicedlime |
| Resolution: | Fixed | Votes: | 29 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||
| Category: |
Commands, Entities, Rendering
|
||||||||||||||||||||||||||||
| Mojang Priority: | Normal | ||||||||||||||||||||||||||||
| Description |
|
Summon a Primed TNT using /summon tnt ~ ~ ~ {Fuse:127}
As the fuse is set to 127, the Primed TNT will explode after 127 ticks. This is as expected. /data merge entity @e[type=tnt,limit=1] {Fuse:127}
works on the invisible TNT to extend the fuse, but will not render it back as the client has already deleted the entity. TL;DR Server doesn't inform client of fuse length changes, TNT animation will always end at 80 ticks. To reproduce in 16w21b, simply summoning a TNT with Fuse:127b won't work. You must continuously use /entitydata to stop the Fuse value from reaching zero. /data merge entity @e[type=tnt,limit=1] {Fuse:127}
Code analysis by marcono1234 can be found in this comment. |
| Comments |
| Comment by Numeritos [ 12/Jun/20 ] |
|
Affects 1.16 pre5 |
| Comment by Connor Steppie [ 27/Sep/19 ] |
|
Affects 19w39a |
| Comment by Connor Steppie [ 26/Sep/19 ] |
|
Affects 19w38b, can I request ownership? |
| Comment by Oval [ 20/Sep/18 ] |
|
Confirmed for 1.13.1. Updated entitydata command: /data merge entity @e[type=tnt,limit=1] {Fuse:127}
|
| Comment by Paint [ 29/Jan/17 ] |
|
Confirmed for 1.11.2. |
| Comment by Marcono1234 [ 09/Jul/16 ] |
|
Please link to this comment in the description The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30. The reason for this is that the method net.minecraft.network.datasync.EntityDataManager.set(DataParameter<T>, T) only sets the dirty field of a DataEntry to true if the set value is not equal to the current value. Only if the dirty value is true, a SPacketEntityMetadata is sent to the client. The problem here is that the EntityTNTPrimed class uses both a DataEntry an a fuse field for storing the fuse value. However only the fuse field is decreased when the method net.minecraft.entity.item.EntityTNTPrimed.onUpdate() is called. This means that the value of the DataEntry is still 127 when the /entitydata command sets it to 127. |
| Comment by null (Inactive) [ 23/Jun/16 ] |
|
Confirmed for 1.10.2. |
| Comment by null (Inactive) [ 22/Jun/16 ] |
|
Confirmed for 1.10.1. |
| Comment by null (Inactive) [ 08/Jun/16 ] |
|
Confirmed for 1.10. |
| Comment by null (Inactive) [ 07/Jun/16 ] |
|
Confirmed for 1.10-pre2. |
| Comment by null (Inactive) [ 03/Jun/16 ] |
|
Confirmed for 1.10-pre1. |
| Comment by null (Inactive) [ 27/May/16 ] |
|
The bug is the same; only the steps to reproduce have been slightly modified. |
| Comment by libraryaddict [ 27/May/16 ] |
|
If the bug has changed, shouldn't a new bug be opened instead of this bug used? This bug has been fixed, the new bug is similar but not the same one. |
| Comment by null (Inactive) [ 26/May/16 ] |
|
Confirmed for 16w21b. The description of the bug should be updated, as the steps to reproduce in the description no longer work. |
| Comment by null (Inactive) [ 25/May/16 ] |
|
Confirmed for 16w21a. To reproduce, simply summoning a TNT with Fuse:127b won't work. You must continuously use /entitydata to stop the Fuse value from reaching zero. |
| Comment by user-f2760 (Inactive) [ 24/May/16 ] |
|
Reopened. |
| Comment by null (Inactive) [ 24/May/16 ] |
|
Confirmed for 16w20a! See |
| Comment by user-f2760 (Inactive) [ 19/Aug/15 ] |
|
if I use it in the latest snapshot, the tnt is still unrendered a lot earlier then it explodes for me |
| Comment by [Mod] redstonehelper [ 19/Aug/15 ] |
|
FVBico: That command works fine for me in 15w34a. Is it still broken for you in the latest snapshot? |
| Comment by user-f2760 (Inactive) [ 18/Aug/15 ] |
|
it states that this is fixed in 15w32c, but if I use summon PrimedTnt ~ ~ ~ {Fuse:200}
it still disappears before it explodes |
| Comment by mert [ 31/May/15 ] |
|
Confirmed for 1.8.6 |
| Comment by KingSupernova [ 17/Mar/15 ] |
|
Confirmed for 1.8.3. Relates to |
| Comment by [Mod] Sonicwave [ 16/Sep/14 ] |
|
Confirmed for 1.8. |
| Comment by [Mod] Ezekiel (ezfe) [ 10/Aug/14 ] |
|
From the same comment
|
| Comment by Paint [ 10/Aug/14 ] |
|
"a 60 second fuse simply doesn't work" Indeed, since the fuse value can only go to a max of 127 (See /summon PrimedTnt ~ ~ ~ {Fuse:127}The pause in-between the entity disappearing and the actual explosion is the bug. |
| Comment by [Mod] Ezekiel (ezfe) [ 27/Jul/14 ] |
|
summon still counts as vanilla |
| Comment by libraryaddict [ 26/Jul/14 ] |
|
Does spawning it in using /summon count as vanilla? |
| Comment by [Mod] Ezekiel (ezfe) [ 26/Jul/14 ] |
|
I'm not able to reproduce. While I do see some de-syncing of explosion times, i.e. a 5 second fuse visually explodes at ~4 seconds, and actually explodes at ~5, a 60 second fuse simply doesn't work, and the server / client agree on it. Does this require non-vanilla NBT changes? |
| Comment by libraryaddict [ 26/Jul/14 ] |
|
Updated |
| Comment by [Mod] Ezekiel (ezfe) [ 26/Jul/14 ] |
|
Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by feildmaster [ 26/Sep/13 ] |
|
An update on what this issue is caused by: The client gets a packet when the entity spawns (Packet23), this packet does not take NBT data into account. The way tnt fuses are implemented (as nbt, not in the DataWatcher), the fuse gets completely ignored (both on the server <stop/start> and the client <always>) |
| Comment by libraryaddict [ 26/Sep/13 ] |
|
Still is a concern. |
| Comment by [Mod] CubeTheThird [ 26/Sep/13 ] |
|
Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by libraryaddict [ 21/May/13 ] |
|
Still is a concern. |
| Comment by Tails [ 15/Mar/13 ] |
|
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by feildmaster [ 26/Dec/12 ] |
|
This isn't invalid, as you can actually reproduce it in vanilla. Reopening. |
| Comment by mprock3 [ 11/Nov/12 ] |
|
I was able to replicate this without bukkit and in single player. This can't be replicated in pure vanilla, but it also addresses that some NBT data isn't being sent to the client, which is an issue. To change the fuse length, you can use MCEdit to create a schematic where an NBT editor can edit the entity then and replaced back into the map. In vanilla minecraft the fuse length is redundant but to map makers, or to a future feature this is potentially a bad issue. |
| Comment by Cloudy (Aaron Mills) [ 10/Nov/12 ] |
|
The client won't know about the fuse length being changed after being spawned - hence why it explodes at a different time. As this was done using bukkit, this is invalid as it cannot be repeated under vanilla circumstances. |
| Comment by libraryaddict [ 10/Nov/12 ] |
|
This was using bukkit. Spawned in entity and changed fuse length. |
| Comment by Selbram (Tory Clement) [ 10/Nov/12 ] |
|
I would still like to know the steps taken to accomplish this so it can be confirmed. |
| Comment by mprock3 [ 10/Nov/12 ] |
|
TNT now has an NBT tag defining the fuse length. |
| Comment by Selbram (Tory Clement) [ 10/Nov/12 ] |
|
How are you changing the fuse length? |