Craft output nodes are rotate in a random (but still
upright) direction if they're facedir, and the param2
is not specified by the recipe. Currenly only affects
optic prisms.
There is a chance to find some at any depth. At
around -256, it should start to get practical to
actually hunt for it. By -600 or so, it is common
enough to actually be an obstacle, and deep
caverns start to get pum-filled.
Pumwater is added by scattering "blob" ore
throughout stone at various depths. Stone
immediately above pumwater sources is carved
away to air, to encourage the pumwater ambiance
to play, to make it a bit easier to find it by audio
cues.
Not-so-documented chat command hidehuds that
takes a comma-separated list of HUD types to hide.
Useful for e.g. streamers or video recording when
it's necessary to hide specific HUD elements to
compose a scene.
- Move translator-only contributors below
rarer core contributors, to make it easier
to manage.
- Automatically update contributor credit
in license when pulling translations from
weblate.
- Merge some apparent duplicate authors.
This can hopefully be used to maintain the
copyright statement for translators automatically
without the risk of missing anyone that the manual
process has had.
N.B. there is some translation file change noise
caused by nodejs sorting end-of-string in keys
differently than perl did.
The new process is a lot faster, since everything
is fetched in parallel, and a lot more extensible.
If there's any coolant near a node, that blocks
all application of heat and prevents it from being
cooked, and also prevents any passive slow-cooling
recipes from operating on it (i.e. racing against
the quenched recipes).
Use coolant neargroups for quench check too,
for consistency. Add memoization to the recipe
data on the check, so to avoid doing the quench
scan for each recipe separately.
- Fix door place-craft discovery not triggering due
to wrong label name
- Fix many door witnesses not working because the door
itself obstructs view of the action; "spread" the witness
event to multiple positions and give the player credit
if they can observe any part of the interacting nodes.
Right-clicking on the top of a shelf would place a legacy plantlike
eggcorn. This was due to the storebox right-click override
unconditionally calling `item_place_node` when placing an item against an
inaccessible side of a storebox.
The solution would be to call `item_place` instead, since that function
has the logic to handle `place_as_item` correctly. However, this cannot
be called from the storebox right-click override directly because
`item_place` calls the `pointed_thing` `on_rightclick`, which would
cause an infinite recursion.
Solve this by refactoring the placement logic into a new
`minetest.item_place_node_or_stack` which is called by `item_place`,
as well as by the storebox right-click override when placing items.
If an item stack is present in the node below a form,
the stack in the form will not fall into it even if it could add to it
(e.g. a 16-sand stack in the form will not fall into a 2-sand stack
below).
This is due to the item stack node being non-buildable-to and missing a
can_item_fall_in method, causing the stack_can_fall_in checks in
storebox_check_item_fall_out from failing when the shouldn't.
Fix by implementing the can_item_fall_in method for item stack nodes.
The implementation follows the storebox one, without any “geometric”
checks on accessible sides.
Changes to the stack stored in a storebox do not trigger a node update,
which meant that affected optics to not get updated until the next ABM.
Use the newly introduced storebox_register_on_stack_change to trigger
a check on dependent optics just like node updates.
