The tnt:boom node doesn't actually need the on_construct and on_timer functions to remove the node after 0.4 seconds as the tnt_explode function already does this beforehand.
It is useful for protection mods to know who owns an exploding
TNT block. This allows the blocks destroyed by the TNT to be
limited to the same ones the owner could destroy without using
TNT.
TNT placed within a protected area by the area owner, and later
ignited by another player will destroy within the protected area
nodes the igniter may not otherwise be able to interact with. Any
player could significantly increase the size of an explosion by
placing more TNT in an adjacent unprotected area if the original
TNT block was placed withing 1 node of such a boundary. This
feature sounds dangerous, but we are talking about TNT. Players
should use it carefully.
Pass nodename to tnt.burn function where possible to reduce
use of 'get_node'.
Change 'ipairs' to 'pairs'.
Use 'nodeupdate_single(pos)' instead of 'nodeupdate(pos)' to
avoid every node triggering recursion, the loop itself takes
the place of recursion and works upwards through horizontal
planes as required.
This fixes the TNT bug that can crash game when blowing up a container
which holds huge stacks above the norm... e.g. give yourself 65535 snow,
place in chest, blow up, stalled!
* Unused variables
* Unused values (assigned to variables, but overwritten before use)
* Defining already defined variables instead of reassigning to them.
This uses a vmanip to count adjacent tnt nodes and explodes them
all at once, using an inverse square law to recalculate the radius.
The maximum explosion becomes 125 nodes of tnt yielding a radius of
15 nodes, which does not break my machine and makes it return
in under a second.
This makes both bigger explosions and less stability issues.
The drop code has been simplified and now drops at all times a
reasonable amount of drops, never blanketing the area with drops,
even at the larges explosion level.
Particles are scaled up according to explosion size as well - a
bigger explosion will show bigger particles.
To scale the tnt:boom particle, we move it to the _effects() function.
Introduces an `on_blast(luaobj, damage)` callback that mods can attach
to an entity def. The function will get called with the damage that
TNT would make.
The function should return three values:
bool do_damage, bool do_knockback, table drops
do_damage allows the mod to tell the TNT code to perform damage on
the entity for the mod. The mod code should not do anything with
the entity HP. The entity should not be immortal. If false, then
the entity will not be damaged by the TNT mod.
do_knockback allows the mod to tell the TNT mod to perform an
entity knockback effect. If false, no knockback effect is applied
to the entity.
the drops table is a list of items to drop. It may be nil. E.g. {
"wool:red" }.
I've documented both on_blast() API methods in game_api.txt. It is
a better place than lua_api.txt.
Any second explosion near a first TNT explosion will punch all
entities found nearby, including item drops. This causes the
item pickup code to think the item was picked up, but by
a `nil` player, thus removing the item.
We query for the immortal entity group, and if the item is in
the immortal group, do not punch the item.
We reuse the tnt:boom texture for a particle that is added by the
on_construct() of tnt:boom, and has a short expiry time (0.2sec).
It is 3 nodes larged, centered on the explosion.
We then make tnt:boom airlike so it doesn't have a texture, and it's
the thing that emits lots of light (we could even make it exist a
bit longer).
The nice thing about particles is that the client is less susceptible
to lag and will always remove them as fast as possible, so this makes
the visual more constant and responsive.
The effect is similar, and the reduction in particles is a small
boost in responsiveness.
To compensate, I've lowered the spawner time and expiration length
as well.
