This helps to bridge the latency gap between the dig completing
on the client side, and the server sending the result, which might
include adding dynamic lights from a now-handheld light emitter,
e.g. for torches or lanterns.
When the player is moving forward, take autorun
speed into account for distance to lead, to better
counteract server latency and let players run at higher
speeds. When standing still, still extend the light in
the player's looking direction a little bit, to get more
favorable "rounding".
Instead of checking to make sure one of the objects
found at a location is the glowing entity (which is
very slow and has to search every object for each
light) just make sure that the entity still exists
(get_pos() does not return nil) and that it's still
within the same node position as before.
This fixes a huge lagspike that was caught on NCC
due to a bunch of dropped glowing lenses.
The problem was pointed out by Josh
(gitlab.com/krazy-j) in merge request !22.
Apparently MT is not very smart about marking
mapblocks dirty to send to clients based on
calling mt.set_node(), i.e. it will mark them
dirty presumptively even if you set the node to
the same value it had already been.
This behavior can be confirmed by registering
an ABM against a common node like grass and
setting action = minetest.set_node. This
causes every mapblock containing that node
to be invalidated every interval, causing a big
spike in the packets received each interval
that you can clearly see on the F5 graph.
Rather than just fixing it for the most easily
observed case (fire checks), add utlity functions
to check this for ALL node change situations,
and apply it more or less universally anywhere
that we are not certain that the node is being
changed and we don't need to worry about the
extra overhead cost of the check.
Note that we don't need a
nodecore.set_loud_check call, as set_loud was
only ever being used already in cases where
we were pretty sure we were actually changing
a node.
- Regen with LBM too.
- Allow different delay time for "just loaded" case.
- Use DNT auto-start for more things, replacing
regen ABM/LBM where possible.
Also tried to improve door ablation reliabiity:
- Use DNT autostart for door ablation.
- Faster DNT check so we don't need the ABM
neighbor scan anymore.
- On early ablation trigger, set DNT for right after
cooldown ends instead of letting DNT loop die,
removing one scenario that could cause
sponge squeezer stalls.
- Players no longer constantly glow in darkness.
- Players can now place light spots by scaling, faster
than actual climbing spots.
- Climbing spots appear if player continues placement
after light appears.
- Floor traversal mechanism is now obsolete.
This allows players to traverse dark caves reasonably
well, still, but only voluntarily, so darkness stealth
mechanics are possible again.
If the node we want to place dynamic light in is occupied (e.g.
player is inside a ladder node space) then allow placement on one
of the 6 face-touching spaces. This makes dynamic lights work
correctly on most ladders, and may fix other similar situations.
Instead of registering the TTL for a light and expecting
more time to be pushed in, use a fixed TTL of 0.25s and
register a callback to check if the light is still valid, i.e.
lights now pull time as necessary.
This should prevent light flickering that can happen
under heavy server lag, i.e. when the time step is
wider than the dynamic light TTL.
Lights that don't register a callback will be ephemeral,
and will disappear after 0.25 seconds, which can be
used to increase the chance that the server has had an
opportunity to move the light, as per torch destructor.
Some time in the 5.3 dev stream (docs updated at
217f3a42), object refs started being invalidated
immediately on calling obj:remove(), such that
obj:get_pos() starts to return nil instead of the object's
last known position.
This can cause some crashes in NodeCore, where we
assume that our object is still valid (or usable as if it
were still valid) even though we're looping through
handlers and any one of them may have remove()d the
object before other handlers get a chance to fire.
Instead, just watch for unexpected nil returns from
functions we expect would never return nil (e.g.
get_pos or get_properties) and return if we hit one.
We can assume all other calls will be non-nil after that
one, as long as we stay in the same function flow.
All possible light level nodes are pre-registered at startup time
so that light levels can be determined fully dynamically at run
time, without needing to explicitly declare what light levels will
actually be needed.
Hopefully this will make using dynamic lights a little easier
and lead to some interesting content.
Also reduce client packets by tracking dynalight node
ttl in-memory instead of meta. Lights might flicker out
a bit on area first loading, but some startup judder is
expected on any unloaded area anyway.
Add a "cheat" code for torch testing, and possibly for
other dev uses.
