Detect a translation that once had strings but became
blank due to an uncaught failure to download the
file from weblate.
Also make trace output a bit terser but more specific.
When stack data was moved from node meta
inventory to fields, it was automatically privatized
and no longer sent to clients, which led to the
unintended consequence of breaking client
enable_local_map_saving. Maps saved this way are
missing all stored item stacks, which can be a very
significant part of the gameplay and render the
maps useless for many purposes.
The default behavior should be to leave this engine
feature intact, with an opt-in option for those who may
have come to rely on the alternative behavior.
- New near_unloaded API that supports custom
distance parameter, map bounds check, and
some optimizations.
- Add area automatic unload check support to ABM
API and add to applicable ABMs, replacing many
old manual checks.
Note that the explicit unload check is only strictly
necessary when something will happen due to
a node NOT being present in the area, e.g. something
igniting due to absent coolant, or soaking quantity
being reset due to missing sources. In simple cases
where the absence of a thing causes the ABM to do
nothing, then the standard check can work because
the default action is to do nothing anyway.
Got through a bunch of mods, up next is optics.
- Try to use crafting recipes rather than resources as
the criteria for completing a hint.
- It's okay to use simple item observation for specific
cases of transient things like pliant concrete.
- It's also okay to still use simple observations for the
eligibility checks.
- Simple observation is also okay for naturally occuring
e.g. decay processes, like wilting flowers, as opposed
to crafts that need to be completed.
- Normal non-selective raking mode works when
pushing a rake with a door.
- The rake does not pick itself up.
- Collected things are dumped at the location of
the direct raking target.
This doesn't seem super useful right now, but
a rake digging a full stack of some item will cause
all additional stacks of items in its range to settle
near the full stack, which could end up over a chute
allowing the item to fall down, and thus could be
used to collect items that scatter over a wider area.
Before releasing this we might consider making
rake digging selective by default, so these can be
used to sort and filter items.
May also consider making it possible to dig with a
rake in other circumstances, e.g. pushing a rake
against an open side of a storebox that has no room
for the rake will cause the rake to dig that stack and
all nearby matches?
May also consider cleaning up the raking API entirely
to make it easier to directly invoke a rake via
machine digging ... or tidy up the machine digging
API so it's no so hacky.
Make sparks bias "downward" for igniting nearby
materials, making starting a fire on top of thatch
more useful, and making thatch a more useful
tinder material.
NodeCore is supposed to be a "player vs self" mental
challenge, neither tourism/spectacle, nor a "player vs
environment" conquest. Players are supposed to find
their own goals, as well as applying the effort to
achieve them, and the nature of the goals is
purposefully as open-ended as possible, ideally with
no bias toward any kind of "completionism."
The name "Hints" implied some kind of assistance, and
thus was inappropriate. The name "Challenges"
similarly implies an extrinsic source of motivation,
which the system is only marginally designed to
provide; especially, it helps new player gain some
momentum, but players are supposed to find their own
motivation eventually instead of chasing after
hint completion as a goal, especially since they will
miss the most compelling aspects of the game.
Somewhat experimentally, rename these once again
to "discovery"/"discoveries" and remove language that
suggests progress toward completion. Add stronger
language suggesting that there is much more to
discover outside of this, hinting at emergent systems
as an example
Under heavy lag conditions, physical entities may
land on the ground at any point during a time
step, but if they have a lot of horizontal velocity
then they may "slide" along the ground, and if we
only check for settling based on their pos at step
times, they may have already slid some distance
dependent on luck and the actual amount of
server lag. This means that under heavy lag
conditions, items may spread out inconsistently
from their landing positions and make a messy
pile.
Using the MT 5.3+ moveresult parameter of
entity steps, we can easily find out when the
initial ground contact occured, and use that as
the settling position, which should be more
consistent under lag conditions.
This has the effect of making entities more
consistently "sticky" so they always tend to
stick at the point of initial contact and rarely
slide or glance along the ground, unless they
hit an edge/corner.
