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.
- 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.
The new change preserves uncombined stacks when digging. For
example, if you have dirt on the far right, tools on the far left,
and space between, and you dig dirt with the tools on the left,
it will create a NEW stack in the space between BEFORE it reaches
the dirt on the far right.
This behavior is necessary to ensure we can keep stacks separate
that we've separated for a specific purpose.
We also can't make the behavior vary based on whether using a tool
or not, because this would be even MORE jarring.
- Intercept /give commands.
- Provide an API for giving the player an item and inserting it
into the inventory in the right place(s).
- Change the fill order. We try to fill the current slot first,
the continue to the right to the end of the bar, and then
finally work our way left to the beginning. I think this fill
order should be most comfortable, in terms of having items tend
to fall close to the cursor.
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.
