We generally either require all cooking recipes to operate on a
single item, or on any number in parallel, and will probably
never want to do an exact match on any other quantity.
This speeds up a 4000ms startup cost to 40ms.
If the item type does not at least pratially match any cooking/cooling recipe the first run, assume it never will and cache this fact
so we can quickly skip all stacks of the same
item next run.
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.
- Further simplifies their appearance and
registration code
- Makes stacks on ground consistent with stacks
on shelves.
- Makes stacks-on-stacks look a litlte less silly.
- Eliminates spurious implication that stack
nodes might block light, which they don't
necessarily do.
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.
- Thrown objects inherit initial velocity.
- Player and objects have matched terminal
velocity and can free-fall in tandem.
- Thrown objects experience horizontal air
friction too.
Instead of shuffling all the shells once for each tick used,
shuffle only those shells actually used once per tick. This
should save us more time in common cases where we need
to only check a few shells to find a place to settle.
- Always prefer closest place first, then lowest height.
- Simplify search order; use a pre-built order instead of scan.
- Randomize search order only once per tick, if used.
If a node is specially tagges with the stack_as_node group, and
the stack size is exactly 1, place as a real node instead of a
stack node.
This reinstates logic from WAY back in the super-early pre-alpha
days, except only for nodes explicitly tagged this way.
This should be applied only to nodes that aren't transformed in
any non-desirable way when placed as nodes instead of stacks, and
can be dug the same ways as stacks (i.e. snappy = 1 or
crumbly = 1).
Currently applied to sticks, staves, leaves, ladders/frames,
and torches. Ladder/frame placement offers some interesting
possibilities in terms of throwing ladders to rappel down holes.
The old method was designed for 0.4 compatibility. Since 5.0
there appears to be a flag we can just check to see if the item
is still moving according to physics or settled.
When removing a stack, if there is a stack above, move it
immediately into place of the removed stack. This works
recursively, so stack nodes never have a chance to break out
into item entities, fall to the bottom and make a huge mess.
Unfortunately there isn't a very good visual for the stack
shifting down yet, but at least the gameplay is there.
When a leaf node is displaced by crushing by a falling node,
instead of ejecting an item, try to place the node itself within
a reasonable distance.
This shoudl reduce the number of stack nodes generated from tree
canopy decay, and should alleviate the inconsistency of leaves
falling sometimes as nodes and sometimes as stacks.
- 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.
If items have a common "stackfamily" property in definition, then
they combine stacks; name and metadata are effectively ignored and
any name is considered acceptable for the combined stack name.
This is used by Lux to allow it to stack naturally instead of the
player having to lay them out spaced on the ground to "cool" them
all to the same level, since all Lux changes dynamically anyway.
Attempt to place stack node directly when player is pointing at
a node space, instead of tossing out an item ent.
This makes item organization less tedious in the early game, as
players are manipulating node positions instead of calculating
ent ballistics in their heads when trying to lay out inventories
on the ground, or using naive shelving.
(Note that wooden shelves still have an advantage in how quickly
items can be taken from them).
Items are still tossed as ents if a player is not looking at a
valid place in nodespace, so inventories can still be e.g. thrown
over a cliff or jettisoned in the ocean...
