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.
