- Clean up group expansion logic
- Lanterns covered in lux will never net-discharge, even if they
are not getting enough power to charge, so that they can be
carried and installed as light fixtures, with a supply of
flux from above, and can be "paused" in a flux flow when not
in use without discharging.
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.
Relying on the dynamic light thing for lanterns when they are
placed on the ground causes unexpected behavior when it comes to
lens activation and the displacement of dynamic light outside of
the node space of the lantern itself. It also causes issues with
lanterns lost deep underwater, i.e. they don't emit light when
they effectively should.
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".
- Check for water in same node (carried by player) and
one node above (esp. for placed stack)
- Slightly optimize node group check
- Fix float rounding error, since meta floats are not
perfectly round-tripped, to reduce spurious rate changes
- Add debugging info to trace phase transitions on all
lantern items
- Correct initial charge setting (for /giveme'd items)
- Fix failure to detect immersion in water
- Reduce re-wield animations
Compute current charge based on past rate and
time, like a soaking AISM, but do NOT update the
totals in metadata unless the rate changed or
we crossed a charge level threshold. This means
that we should only see the re-wield anim when
the charge level changes, the item is brought
in or out of water, or moved around a reactor.
We are losing the randomness factor from the
soaking AISM, but it's probably fine to have a
more exact discharge time for this sort of item.
Every sound in the game (and all known mods for
it) should play either at a specific location, to a
specific player (e.g. chat beeps or notifications),
or bound to a specific physical object. Detect any
that might be played globally by accident, e.g.
like a bug that existed in NC ZipRunes for a while,
to aid in debugging.
TurkeyMcMac's JIT Profiler mod provides much
better performance data anyway, and these
ABM stats haven't pointed out any really
useful actionable issues for a while.
Add a centrifugal/centripetal component to door
conveyance when it's on the vertical axis, to
help prevent gravity from immediately undoing
the work.
- Items propelled by the bottom of a door are
also pushed outward.
- Items propelled by the top a door are also
pulled inward, landing atop where the door was.
There IS actually a mechanism to detect it,
though I'm not exactly sure how to use it.
Players need an opportunity to discover that
method and prove whether or not it can be
exploited to make a proper machine.
Door recursion is now always:
- Breadth-first, so paths with fewer door-to-door
interactions always "win".
- Random-ordered within each depth layer, so
there are are no biases in door operation order.
This information is now presented in its
optimal compact form on the About GUI,
so we no longer need the same level of
human-readability for the chat command
and can restore its compatibility for
e.g. script purposes.
It's the light level incident on the rush itself, not
in the space above, that we care about. We also
don't need air above the rush, because there's air
IN the rush node.
This allows e.g. non-sunlight-propagates nodes to
behave like sunlight-propagates ones for purposes
of nametag display.
This should complete the changes necessary to
make NodeCore "darkcore" mode feasible with
true darkness by disabling sunlight_propagates
for air to block moonlight, but still pass optics,
nametags, and radiant heat as if transparent.
Looking into the possibility of making everything
overridable for game-logic purposes by group, it
turned out to be a bit of a nightmare. Also, instead
of overriding them at the "heuristic" layer, it's
probably better to simply allow overriding at the
specific game logic level, e.g. so that multiple
systems that use the same source data for heuristic
purposes can have differing behavior.
- If we fail to get the player name, instead of returning a dummy
object with no privs, defer to the wrapped function without the
cache, to preserve the old behavior.
- Clear cache more aggressively when the player joins or leaves.
This may help ensure that stale cache data doesn't affect things
for too long, and also allow the cache to be GC'd more on servers
with more player turnover.
Instead of caching privs only for the current tick, and only for
NodeCore itself, change the base API to use caching universally,
including for naive mod code. Privs are cached until invalidated
by a change; it's assumed here that the "auth_reload" command
exists in the first place because this kind of caching is allowed
and accounted for, even if it's not actually done by the engine
or builtin.
