All

I would also love this, because it would help with managing tnt for custom tnt purposes.

Added in PR 212 (bukkit) / PR 289 (craftbukkit).

While CraftBukkit was handled by the Bukkit team it was suggested to call EntityChangedBlockEvent with the TNTPrimed entity as the source. The entity could carry a reason and/or source, since plugins might need that information later when the actual explosion happens.

Oh yea, I almost forgot - the TNT block is set to air both clientside and serverside in some cases. So for the event to be useful, the block would need to be resent if the event is canceled.

Working on a patch for this. I think it makes more sense to create a separate event than to use BlockIgniteEvent since BlockIgniteEvent is always used when a fire block is created from ignition (and only with fire).

There are several additional causes, though, which makes it more complex.

The mostly obvious ones:

• FLINT_AND_STEEL would also include fire charges when used by players, since both can be used to set off TNT.
• FIRE_ARROW (rather than just ENTITY) would happen with a flaming arrow.
• EXPLOSION would be us used for TNT lighting due to other explosions.
• REDSTONE is a value that would make sense for use, although that event would fire many times since it'll trigger each time the TNT receives a block update (could get noisy).
• FIRE would be for when firespread ignites a TNT block.

But then there are the more subtle, annoying causes:

• Any TNT with a metadata value of 1 (the "explode" property) will explode when punched by a player. Thing is, this happens via a call to postBreak. That method only takes a World, a BlockPosition, and an IBlockData, and is used internally to trigger TNT explosions in a bunch of other cases, both ones where the block is actually broken normally but also with redstone triggering TNT. So it's not easy to try to detect and handle that case (since there are a number of places where that is triggered, but only some matter for this situation and those ones are really general).
• Dispensers with Flint and Steel in them will ignite TNT blocks in front of them (and this doesn't happen with fire charges). They also do this by calling postBreak, although I can fire the event within the dispenser code instead.
• Firespread (previously mentioned) also uses postBreak. Again, the event can be fired from the fire code, but it's more convoluted.
• Dispensers can directly dispense TNT. I don't know if that would fall under the jurisdiction of this event, but it's yet another situation to consider.

It's these situations that make it pretty hard to implement this event, and without handling them, the event is a lot less useful (since primed TNT could still be created in ways that wouldn't be expected).

+1
(Would be +1000000 if I can)
This would be very useful if exists.

+1

+1

added

I would be fine with the BlockIgniteEvent too. Also for the causes, maybe adding REDSTONE to them too...

You are right, the BlockIgniteEvent is not called when you activate a tnt block.

I think there does not need to be a TntIgniteEvent, its just needed that the BlockIgniteEvent is called if TNT is ignited. Wherefore the ignite causes should be shrinked to FLINT_AND_STEEL, ENTITY, SPREAD, REDSTONE

Yes, and that event is fired when the TNT has exploded and ignites surrounding blocks.

Did you tried listening to the BlockIgniteEvent?