Instead of limiting the number of cycles
to some arbitrary upper bound, run as
many cycles as necessary up to a CPU
time limit, i.e. we only allow expansion
of globalstep time by a fixed limit.
If we're running multiple optic ticks in
rapid succession, then we don't return
control to the rest of the game between
ticks, so there's no point in reading the
map more than once per pos, and no
point in updating the map until the end
when optics may have oscillated
across multiple states.
Maintain a cache and commit buffer
during each globalstep and only flush
them at the end.
Apparently as oilboi pointed out, node metadata
is kinda gross, and in this case we didn't actually
need it, since the information could actually
always have been inferred from the nodes
themselves.
Instead of storing output state in node meta,
just register a callback on the node definition to
interrogate the node itself about its power output.
Item ejection due to injury or teleportation:
- Check for custom on_drop calls from items, e.g. admin tools
that distintegrate instead of becoming items.
- Log players losing items so we can audit where things came from
or went to.
- Make teleportation and injury APIs use the same methods.
Trying to isolate server performance issues, it was pointed out
that clients are spending a LOT of time receiving and rebuilding
mapblock meshes, and that updating node meta triggers this, even
when that meta is not relevant to the rendering of nodes.
Rubenwardy added a suggestion to change this in the engine:
https://github.com/minetest/minetest/issues/10127
This patch implements this suggestion at the game level, since
in NodeCore's case we already were making the assumption that
nearly all metadata fields were private.
Useful for more complex transformations like assembling
animations or tiling.
Use in a couple places to try it out, esp. the new living
sponge animation.
- Identify candidate spots to place loot.
- Store loot placement spots for later handling.
This will involve manipulating metadata and other
things that are not necessarily safe to do while
other mapgen_shared may run after us.
- Process the loot queue on tick.
Things left to do:
- Define loot tables and rarity values.
- Identify storeboxes and other storage mechanisms.
- Generate random stacks.
Two optimizations that added up to a significant
time savings in on_generated:
- Replacing calls to area:index(x,y,z) to precalculating
an offset and then using stride math inside the loops
gives us a huge cost savings.
- Prefilling lookup-by-ID tables to force them into
sequential arrays instead of hashmaps speeds up
lookups, for a more moderate savings.
Allow the "above" node to override the "under"
node's description. Use this mechanism to
append charcoal glyph descriptions to the
touchtips, but only when punching a face that
has a glyph on it.
This makes mass-production of etched concrete
nodes a lot less tedious and more interesting.
There's now an incentive to manage multiple
separate styluses for larger projects.
