[MC-2490] TNT animation ends at 80 ticks, ignores fuse length changes

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.

However the client isn't informed of this change and will show the TNT animation exploding at the normal 80 ticks. This also removes the TNT entity from the client side.

/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.
Example: run this in a repeating command block:

/data merge entity @e[type=tnt,limit=1] {Fuse:127}

Code analysis by @unknown can be found in this comment.

Linked issues

is duplicated by 2

MC-81937 PrimedTnt with long fuses disappear before exploding. Resolved

MC-102314 Tnt invisibility Resolved

relates to 2

MC-59168 TNT explode delay Resolved

MC-205567 TNT flashes are translucent once again Resolved

Comments 42

Selbram (Tory Clement) 2012-11-10T03:52:54Z

How are you changing the fuse length?

mprock3 2012-11-10T04:03:23Z

TNT now has an NBT tag defining the fuse length.

Selbram (Tory Clement) 2012-11-10T04:47:09Z

I would still like to know the steps taken to accomplish this so it can be confirmed.

libraryaddict 2012-11-10T14:47:46Z

This was using bukkit.

Spawned in entity and changed fuse length.

Cloudy (Aaron Mills) 2012-11-10T15:23:50Z

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.

32 more comments

mprock3 2012-11-11T21:29:09Z

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.

feildmaster 2012-12-26T03:22:09Z

This isn't invalid, as you can actually reproduce it in vanilla. Reopening.

Tails 2013-03-15T15:22:06Z

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.

libraryaddict 2013-05-21T09:45:13Z

Still is a concern.

CubeTheThird 2013-09-26T02:56:46Z

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.

libraryaddict 2013-09-26T09:01:12Z

Still is a concern.

feildmaster 2013-09-26T15:59:25Z

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

Ezekiel 2014-07-26T18:55:57Z

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.

libraryaddict 2014-07-26T19:32:59Z

Updated

Ezekiel 2014-07-26T19:42:37Z

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?

libraryaddict 2014-07-26T20:38:14Z

Does spawning it in using /summon count as vanilla?

Ezekiel 2014-07-27T00:37:55Z

summon still counts as vanilla

Paint 2014-08-10T14:45:12Z

"a 60 second fuse simply doesn't work"

Indeed, since the fuse value can only go to a max of 127 (See MC-30255, that's intentional). But ignoring that factor, the fuse animation is still independent from the actual fuse of the entity. Use this command:

/summon PrimedTnt ~ ~ ~ {Fuse:127}

The pause in-between the entity disappearing and the actual explosion is the bug.

Ezekiel 2014-08-10T23:55:49Z

From the same comment

a 5 second fuse visually explodes at ~4 seconds, and actually explodes at ~5

Sonicwave 2014-09-16T03:39:37Z

Confirmed for 1.8.

KingSupernova 2015-03-17T02:14:26Z

Confirmed for 1.8.3. Relates to MC-59168.

mert 2015-05-31T19:46:51Z

Confirmed for 1.8.6

user-f2760 2015-08-18T12:33:53Z

it states that this is fixed in 15w32c, but if I use

summon PrimedTnt ~ ~ ~ {Fuse:200}

it still disappears before it explodes

[Mod] redstonehelper 2015-08-19T17:03:08Z

FVBico: That command works fine for me in 15w34a. Is it still broken for you in the latest snapshot?

user-f2760 2015-08-19T19:11:28Z

if I use it in the latest snapshot, the tnt is still unrendered a lot earlier then it explodes for me

null 2016-05-24T05:13:20Z

Confirmed for 16w20a! See MC-102314 (I also tested it myself).

user-f2760 2016-05-24T10:01:57Z

Reopened.

null 2016-05-25T23:10:22Z

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.

null 2016-05-26T23:01:03Z

Confirmed for 16w21b.

The description of the bug should be updated, as the steps to reproduce in the description no longer work.

libraryaddict 2016-05-27T02:49:05Z

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.

null 2016-05-27T03:19:30Z

The bug is the same; only the steps to reproduce have been slightly modified.

null 2016-06-03T01:47:17Z

Confirmed for 1.10-pre1.

null 2016-06-07T22:57:34Z

Confirmed for 1.10-pre2.

null 2016-06-08T21:40:20Z

Confirmed for 1.10.

null 2016-06-22T17:05:29Z

Confirmed for 1.10.1.

null 2016-06-23T16:33:44Z

Confirmed for 1.10.2.

marcono1234 2016-07-09T19:04:27Z

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.
This should probably solved by removing the fuse field completely.

Paint 2017-01-29T20:29:50Z

Confirmed for 1.11.2.

Oval 2018-09-20T04:46:05Z

Confirmed for 1.13.1.

Updated entitydata command: /data merge entity @e[type=tnt,limit=1] {Fuse:127}

muzikbike 2019-09-26T21:55:37Z

Affects 19w38b, can I request ownership?

muzikbike 2019-09-27T17:08:12Z

Affects 19w39a

numeritos 2020-06-12T19:44:54Z

Affects 1.16 pre5