Certain items, e.g. heated lode, were meant not to
be carryable so that players would need to plan
certain constructions properly. The "hot potato"
feature was added to achieve this, and I had
assumed that players would eventually find it
sufficiently frustrating that they would stop and try
to figure out how to do things properly. This has
not worked out, and players working at a forge
spend a lot of their time fiddling with hot things
trying to randomly throw it into the right spot.
This change should make it more difficult for
players to manipulate the "hot potato" item
physics to move items that shouldn't be movable
by hand once heated. Problems involving heated
item placement need to be solved through proper
furnace design, not workarounds. As a bonus, it's
now also harder to accidentally hot-potato your
items into places it's hard to get them out of.
At some point in the future, we will probably be
adding tongs to provide a proper way to move
these items, once players have reached the
proper tech level.
- Track visinv ents in a separate list instead
of minetest.luaentities, so we can skip the
removed and non-visinv ents all in one pass
- If no visinv updates were scheduled for any
given tick then don't run any pass at all
- Push early activation externally.
- Fix bug with ents fooling visinv checker into
thinking pos is handled even when marked
for removal
- Eliminate a redundant stack_get call
We actually have good enough coverage to
push in events when the ents need to update
appearance, so the only thing the patrol
on step was doing was clearing old ents that
the ABM wouldn't catch, which would just be
cleared eventually anyway due to unloading
or something.
This cuts out a major performance cost item
entirely.
Defer and coalesce visinv entity creation/removal
checks until the next tick, so we can process them more
efficiently in a batch.
The spawn area of the Community MP server was
lagging to something like 6x the dedicated step size,
due to the huge number of dropped items. This code,
on the same machine, seems to appear the same to the
player, but produces almost no measurable lag.
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 should more reliably minimize network traffic
incurred by excess property setting.
We could probably standardize a few more things,
like set attach, anim, yaw, pos...
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.
