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.
Don't use the stored pos, which might be at the time of
player login, and thus arbitrarily far from where the player
is now, such that it might never actually be loaded.
- Split "discovery" into 2 stages: a check (to see if
there is even anything new to discover) and a
commit.
- When doing witness checks, check to see if there
is anything to be discovered first, before doing the
more expensive visibility checks. If the player
already knows all the discoveries, then we don't
need to do any of the raycasts.
This should speed up especially pathological cases
like door catapulting, which can cause witnessing to
happen at multiple points, and causes major
slowdowns when multiple players are within the
distance range and facing the correct direction due
to tons of raycasts happening.
Clear the dirty flag after cleaning the cache. In
practice this will probably make no difference
since game logic makes it very likely the cache
would be dirty after every tick anyway, but it's
more correct at least, and MAY reduce lag on
empty servers.
All base-game priv checks should now only
require one priv lookup per player per tick,
except in special cases where a player's privs
changed during that tick.
Apparently accessing player privileges is
weirdly expensive, regardless of whether
get_player_privs or check_player_privs is used,
and because interact privs are checked so
frequently, it adds up to quite a lot (as much as
a third of the playerstep time). Since things
controlled by interact privs are probably safe
to delay for a tick (it won't be toggled very
often), just cache it for the current tick to
mitigate this.
In the future it might make sense to (1) trap
the privilege change calls to invalidate the
cache, and (2) consider doing this for some
other privilege checks.
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.
Note that we are not YET bumping the protocol version requirement
because (1) the proto bump policy was new as of 5.5, and (2) we
have no known cases yet of 5.4- not working correctly.
- Smoke API uses expandable options param instead of positional
- Separate burst qty from automatically adjusted rate
- Backward compat with old API for now
- Standardize burst of smoke puffs for crafting
- Torches emit small smoke particles at increasing rate as they
start to wear out, to warn players holding them to light another
- Torches now emit a puff of smoke upon snuffing
A single eggcorn that finds itself "forced" into a node
of loose dirt (e.g. by being displaced by a falling loose
dirt node that settles where it was) will become a
sprout.
- Unify setup and inv mods so they can share some
logic
- Lock more things when player is standing in the
"home" position.
- Automatically re-lock player if they return to the
"home" position and stay still.
Machines can only dig one way, and cannot hold the "sneak" key,
nor is there a particularly sensible way to differentiate between
different kind of actions or setup the environment to signal
the digging "mode".
Toward this end, it seems to make the most sense to have the thing
that the machine is digging always significant, and it should be
possible to emulate a "dig everything" machine (knowing that only
certain kinds of things will be within range within a machine)
using multiple "dig one thing" rakes, whereas the reverse is not
so obvious.
For this reason, until a multi-modal system is figured out, change
the default mode to be selective.
It was always weird that the player character could
sense hinged panels even when the faces shown were
completely undifferentiated from their non-panel
counterparts. Add a fairly subtle visual indicator that
makes it obvious why the player can spot them.
Players can still hide doors in plain sight, they may
just need to take more advantage of shadows and
other geometry tricks to ensure they don't stand out
against a field of similar nodes, or use psychological
tricks to distract other players from spotting the
patterns.
Treat all "stone-like substances" as stone for purposes
of the hints. You can chisel/bond any of stone, adobe,
sandstone, tarstone, etc. to get credit for the hints, so
there should no longer be hints hidden because you
haven't had the exact right kind of unetched concrete.
