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.
We add a +/- 0.5 random value to the velocity vector of
ejecting nodes.
I've spotted a lot of nodes going exactly straight up if blowing
up sand above TNT. The extra variation looks less artificial.
We apply punch damage to mobs caught in the blast radius, as
this code previously only hurt players.
We "move" players back 1 node if they're caught in the blast, and
slightly up. We can't "eject" players due to missing API code to
support that, unfortunately.
Adds a minor helper function that allows efficient retrieval of
several inventories from a node inventory. We use this helper to
quickly retrieve the items in chests, vessel shelves, book shelves
and furnaces, and return these with the nodes itself to the TNT caller.
The TNT caller then performs the entity physics, and we don't need
to do anything else.
We disable TNT doing anything with bones.
We expose a bug in the code that drops the items - metadata was lost
entirely. This patch corrects that by properly copying the metadata
and creating the drops list inclusive metadata.
We add on_create() handlers for both burning TNT and burning
gunpowder. Because gunpowder will explode TNT in 1 second,
and not 4, we need to modify the 4 second timer after we
make the TNT burning. Other mods can now place burning TNT
that will by default explode after 4 seconds.
I spotted two places where under stress (many explosions) luajit would
end up passing nil to these functions. I'm not entirely sure how,
but it seems good form to guard against it, which does make it
more robust. After this patch, I'm not able to crash the server. With
many explosions, it may still lag significantly, but always returns
in the end.
We define the blast intensity as the square of the tnt_radius, divided
by the square of the distance to the explosion center, where distance
is limited to 1 at the lower end.
When destroying nodes, we calculate the intensity for each node, and
only destroy the nodes when the intensity is 1.0 or larger. To avoid
perfectly spherical explosions, we make sure to retain a randomness
factor of 20%. This will make explosion edges jagged and not smooth,
but not too much.
We pass the calculated intensity to on_blast() functions as well,
except we take the jitter here out and make sure it's always 1.0
or larger.
We apply a log scale to the size of the stacks ejected, so that
in larger explosions we are getting larger stacks. For normal r=3
explosions, this gives stack sizes ~6-7 or so, but for r=10 explosions
it could end up giving stacks of 25+.V
The drops list already has quantities, so let's just select the one
with the highest quantity from it, and use that as tile. Fallback
tile will therefore only be used if explosion happens in air. Oh well.
