There's a "soft disable" that just hides the entities
but keeps the database up to date, and a "hard
disable" that clears the database, keeping only
minimal data, until existing transactions (taken
items, dumped inventories) are flushed to the
world.
I had wanted this to be a standard feature of the
game for a while but put off merging it because:
- I had hoped to find a better visual design for the
ghost player entities that matched the bandolier
in nc_player_wield better, and
- I had scalability concerns with large servers with
thousands of offline players.
However, in practice it seems like the scalability
issues are not as critical, and the visuals are
acceptable as they are for now.
In making this a standard game feature, it
will probably also make sense to add an option
to effectively disable parts of it (e.g. avoiding
creating the ents, or even avoiding filling the
database except where players' items are already
taken).
- 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.
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.
- Clear the cached timer when the timer has fired.
- Simplify the save-timer-save cycle and just rely
on dnt_timer to do the save, to eliminate
redundant saves.
