Utilizes several new features allowing the description of an item to be changed using the `description` meta key. This also moves keys from using the old single-value itemstack metadata system to the new node-like metadata system.
This reverts commit 5e4a6e8ac68b92c7394b80bb67839b71b4a4a00b, and
commit 60cf3f85b6e661482ec2705cadbdc1b04e388d19.
The original door API rewrite I posted had all rotation disabled using
the correct on_rotate() handler returning `false`. Two subsequent
changes attempting first to enable simple rotation and second disabling
that again changed the callback handler to a boolean `false`, which
is incorrect use in the screwdriver API, and actually allows rotation.
The proper way to disable rotation for facedir nodes it to use a full
callback handler that does `return false`.
This code adds the key concept to minetest_game, and integrates it
with lockable nodes. Currently supported lockable items are the Steel
Door, the Steel Trapdoor, and the Locked Chest.
The goal of this modification is to introduce a fine-grained multi-
player permission system that is intuitive and usable without any
console or chat commands, and doesn't require extra privileges to
be granted or setup. Keys can also physically be conveyed to other
players, adding to gameplay and adding some personality that is
preferable to console commands or editing formspecs.
A skeleton key can be crafted with 1 gold ingot. Skeleton keys can
then be matched to a lockable node by right-clicking the skeleton
key on a lockable node, which changes the skeleton key to a "key".
Gold was chosen as it's currently a not-so very useful item, and
therefore it's likely that players have some, but aren't really
using it for any purpose.
This key can subsequently used by any player to open or access that
lockable node, including retrieving items from Locked Chests, or
putting items in them.
They key is programmed to fit only the particular locked node it is
programmed to. This is achieved by storing a secret value in both
key and locked node. If this secret value doesn't match, the key
will not open the locked node. This allows many keys to be created
for one chest or door, but a key will only fit one node ever. The
secrets are stored in node, and item meta for the key.
If a locked node is removed, all keys that opened it are no longer
valid. Even if a new door/chest is placed in exactly the same spot,
the old keys will no longer fit that node.
Keys can be smelted back in gold ingots if they are no longer useful.
The method of storing a secret in nodemeta and itemstackmeta is secure
as there is no way for the client to create new items on the server
with a particular secret metadata value. Even if you could possible
create such an itemstack on the client, the server does not ever read
itemstackmeta from a client package.
The patch adds an API that allows other nodes and nodes added by
mods to use the same keys as well. The method how to implement this
is described in game_api.txt. The mod should add 2 callbacks to it's
node definition. Example code is given.
Textures are from PixelBOX, thanks to Gambit.
Currently all minetest_game PR's are failing travis since the
upstream luacheck now also warns about whitespace issues, and
there are a few of those in the code. This fixes all of them
so we can yet again rely on luacheck.
With mip-mapping enabled, some GPUs cause a visual bug with indexed
textures that use alpha. This bug has been present for a while but
not noticed before. All indexed alpha textures must now be converted
to RGBA, to start this process we revert some textures converted to
indexed in the recent commit af3c918.
This fixes all cases where the color profile was broken, and
libpng warns about. It also makes almost all textures indexed
instead of RGB where possible (textures that don't have
semi-transparent pixels).
The collision box still extended into a neighbouring empty node, causing
falling node objects to collide but not transform back into normal nodes.
Completes the fix started in a previous similar commit.
Part 1: All mods except default and xpanes.
Add license.txt files.
Add missing README.txt files.
Check and update copyright years for all contributors.
Improve text format and make more consistent.
Make the softer woods, pine and aspen, 'flammable = 3'.
Correct inconsistent flammability of wood and stairs in relation
to all other solid wood nodes in MTGame.
Make the the softer woods, pine and aspen, 'choppy = 3'.
Previously, the collision box extended into an empty node, causing
falling node objects to land on the open gate but not transform
back into normal nodes. Now fallng node objects will fall through and
either side of the end of the open gate and transform back.
Fix crash when doors are placed under unknown nodes.
Share a can_dig among doors, that does not crash on nil-player.
Only set can_dig if we actually protect the door.
* Unused variables
* Unused values (assigned to variables, but overwritten before use)
* Defining already defined variables instead of reassigning to them.
Currently any doors viewed from underwater will disappear but removing the line 'use_texture_alpha = true,' seems to fix this. Thanks to Thomas-S for finding this glitch.
If LVM or some other nonmetadata method is used to place a door,
then metadata is missing that tells us whether the door is left
or right-hinged.
However, we can detect that nodemeta is missing and see if the node
name is _a or _b. In the case of _a, nothing needs to be done and we
can just open the door. In the case of _b we assume the door is right
hinged, and tune the state nodemeta value so that the door opens the
right way. This all of course assumes that the schematic method places
the doors *closed* by default, which is reasonable.
We were cleverly attempting to use an airlike node as the
top half of the doors, but as airlike nodes are not walkable,
falling nodes would not stop falling and thus remain an entity
stuck on top of a door.
After inspecting the builtin/game/falling.lua code, I considered
the remaining options: (a) revert doors such that the top part is
actually the door, (b) play with nodedef fields and see if other
flags may work, or (c) modify the hidden door part to another
drawtype that properly prevents this issue.
(a) seemed way over the top for now, although it would solve the
issue, it would cause a rewrite of most of the code including the
old-door-conversion.
(b) turned up nothing.
(c) turned out to be relatively simple.
So, here's the implementation where I turn the hidden door top
into a tiny, non-targetable but walkable nodebox that is entirely
inside the door hinge. It's entirely transparent, so you still
can't see it, can't hit it, nor can you place anything in it or
make liquids flow through it. The top part is placed in the right
position on placement and not touched further.
Falling nodes will properly stop on top of these doors. I've
adjusted the door conversion code to properly account for the
issue as well, so the only thing remaining is people who have
been running a git branch - those can upgrade by re-placing the
door.
