Adding cobble/sandstone just arbitrarily holding
up gravelfalls looks awkward. Instead, just clear
them out, like they fell long ago when the stone
weakened into gravel but were scattered long ago.
Instead of wasting compute cycles running falling
node physics on freshly generated terrain where
the player would only see the aftermath anyway,
just shore them up with non-falling alternatives.
Nodes are checked for falling automatically upon
mapblocks being loaded, and also every now and
then in the background. In most cases this should
mean that nodes that should fall will fall as soon as
they are loaded, or pretty shortly therafter, and in
rare cases where something is missed, they should
"catch up" eventually.
Processing falling stuff is surprisingly expensive,
especially when loading an ocean floor where nearly
every node is a sand node, so a lot of complex
optimizations and limits were put in place to prevent
this from lagging the game. Pre-checks are done to
avoid calling MT's builtin falling check code, which
is surprisingly inefficient (even by MT standards) and
limits prevent it from either taking too much time
itself or spawning falling_node entities beyond a
safe limit.
Be consistent with the principle that the mere
presence of a player does not affect the behavior
of objects in the world. Items should "fall
through" players instead of bouncing off them,
i.e. being deflected.
Some time in the 5.3 dev stream (docs updated at
217f3a42), object refs started being invalidated
immediately on calling obj:remove(), such that
obj:get_pos() starts to return nil instead of the object's
last known position.
This can cause some crashes in NodeCore, where we
assume that our object is still valid (or usable as if it
were still valid) even though we're looping through
handlers and any one of them may have remove()d the
object before other handlers get a chance to fire.
Instead, just watch for unexpected nil returns from
functions we expect would never return nil (e.g.
get_pos or get_properties) and return if we hit one.
We can assume all other calls will be non-nil after that
one, as long as we stay in the same function flow.
This freezes many things that normally happen automatically
in the world, including most ABMs and AISMs, and a few other
custom step logic items like the player "hot potato" logic.
This can be used for "creative mode" purposes to setup a complex
build without it running itself away from you, and for texture
pack authors, to have time to see things that are normally
transient or difficult to observe because of the effects they have
on nearby things or players.
Treat all API mods as a "layer", and use the new
nc_api_all registration to indicate that a mod depends
on the NC API (which ALL NC mods assume they do).
This means that each non-API mod does not need to
worry about which API mods it really needs and which
it does not, nor will they need to be updated for any
internal API restructures.
This is a game, not a modpack, so all mods will be
loaded anyway, and we only care about order. That
means that we don't really need to worry about
having excess dependencies because any mod we
don't actually need will be needed by something that's
loaded anyway. If somebody wants to reuse a
component elsewhere, they're likely to need to do
some work to untangle it anyway, because of the
amount that NodeCore mechanics interact and
interdepend.
This created a ton of dependency inversions, which
necessitated moving a number of API functions up into
higher layers, and restructuring dependency lists for
a number of mods.
BOLO: non-deterministic load errors due to missed
dependencies.
If the falling item/node causes enough damage to
trigger a "hurt" effect, then it loses much of its energy
and bounces upward off the player.
This will also reduce the "scraping" effect when nodes
fall through a player. Hopefully the damage from
falling things is a little more consistent now.
Wrong falling check. We don't need to check for repose
because that's already handled by an ABM. Instead use the
standard check_for_falling that's recursive.
- Make some adjustments to player entity location finding.
- Genericize crush damage logic to apply to item entities too.
- Item ents cause only 20% crushing damage.
- Collapse all nodecore "core" mods in the /mods listing, so it's
easier to find the actual add-on mods.
- Parameterize in-game branding to make renaming derivatives just
a little easier.
Use interception where possible to modify destintion for items
directly instead of relying on post-hoc inventory rearrangement.
This should resolve the glitches where items appear in the wrong
place in inventory for a flash before being moved.
- Eggcorn cleanup. They look a little better falling out of the
tree, and we don't have so many now.
- Crushing damage fixes. Crushing is nuanced now, and most things
don't smush you, and many do reduced damage. A few may do more.
- Item stack convenience. Items landing on a stack or right-
clicked onto one attempt to merge into it.
- Ladders now fall (they don't connect to sides). Use the new
full-scale frames for ones that don't.
- Nodes that are falling do damage to those near to them from
crushing and/or friction.
- Player activity can cause falling nodes left in precarious
positions by mapgen to fall randomly.
