This is an adapted version of #861 - by oleastre
Most mods had been calling `doors.register_door() with a door
name that included the "modname:" prefix, and we should continue
to allow mods to do so, without registering the nodenames created
in the "doors:" namespace.
The default case is to use the "modname:" prefix verbatim. If
mods or code calls this function without a prefix, then "doors:"
is automatically used.
Now that the namespace is corrected, the copy replacement ABM is
no longer needed.
This function maps doors.register_door to the new API as far as
reasonable. We can't map the texture, so we fall back to a default
texture. An error message is printed if mod writers did not provide the
needed new tiles field for the door. The created doors are functional
and a full replacement. Old doors are replaced with the new ones
through an ABM.
Other mods may depend on knowing whether doors are placed
to setup additional attributes or perform node manipulations.
This is something e.g. mesecons does to connect circuits
to doors. This was tested with mesecons. Placing a door next
to a mesecon wire will make the wire automatically
connect, which was otherwise not happening.
And similarly, if we wield a door and right click any node
that has an on_rightclick() handler, call the handler
instead.
Just to be on the safe side, assure that none of this
code runs when right-clicking an entity or player, which
would likely crash the server.
Fold in PR #831 as well - prevent server crash on door
place on unknown blocks, by @tenplus1.
This code never allowed placing a door on e.g. a grass
plant. The code to handle this isn't that complex. With
this code, doors can be placed on flowers and on normal
node surfaces without issues.
This patch replaces the default door nodes with a new mesh model
and nodes.
Two new models were added that are 2 blocks high. One for left-hinge
and one for right-hinge doors. This allows us to make a single texture
fit on both models. The alternative would have been 1 model and 2
unmapped textures, which is more work for mod developers.
Doors work exactly like the old doors, including ownership, breaking
doors, opening and closing.
Under the hood, we can prevent the top part of the door from being
obstructed by placing an invisible node. This prevents liquids from
flowing through doors or people placing sand or other blocks in the
top half. The door code automatically places and removes these as
needed.
Metadata is used to store door state, just like the old version.
A doors API is added, it allows mods to use the API to open/close or
toggle door states without worrying about sounds, permissions and
other details. This is intended for e.g. mesecons. This API allows
mods to manipulate or inspect doors for players or for themselves.
In-game old door nodes are automatically converted using an ABM and
preserve ownership and orientation and state.
TNT blows up all doors and trapdoors except for the steel ones,
who can survive a blast. We return an itemstack in on_blast(),
which requires a TNT API patch which is also pending.
We enable backface culling for most of these doors, as this gives
the identical visual appearance that the old doors had. In the case
of the glass door, there's a slight twist.
The texture files used by the new doors have new names that do
not conflict with previous texture file names to avoid texture
pack conflicts.
Thanks to red-001 <red-001@users.noreply.github.com> for some
of the conversion code, cleanups, and extra textures.
We're using a normal wooden side texture to draw the sides
of trapdoors. But the side textures have only 2 edges that
have a nice texture for the 2px wide trapdoor. We can
either repaint the textures, or just rotate the texture
properly for the two sides that need it.
Because the side texture for wooden doors was just a default:wood
texture, it clashes with the colors in the trapdoor, and so
we add a wooden trapdoor-matching tile side texture as well.
This also improves the steel trapdoor side, but without a
texture change there since that was already a specially
drawn texture for that node.
We also increase the thickness of the trapdoor to 2px. Right
now the model is 0.4 large, but this causes the side textures
to look odd as there's a mismatch in pixel size. By scaling the
trapdoor side up to exactly 2px, the sides look natural.
Thanks to @kilbith for the suggestion.
There really is no reason to prevent rotation in trapdoors, I
expect this to be an oversight.
Trapdoors work perfectly well sideways, upside down and can
work like fences, gates and more. Most commonly, people will
want to put them in the top half of the node so they remain
flush with a floor.
In oversight, I added this recipe not verifying that it was already
taken.
We change this to a 2x2 iron bar recipe. The shape and amount are
reasonable (reduced to output 1 steel trapdoor), and I verified that
it wasn't in use.
Fixes #779
Adds a steel trapdoor. Textures were painted from scratch, and
inspired by the current Steel Door. Ownership on the trapdoor
works as expected, and so does the crafting recipe.
Mirror the setup of a door placed next to any door, not just next to
a door of the same type. This is particularly useful where there are
multiple door types that have the same appearance, but one wants the
doors of a pair to have different behaviour in some other respect.
When a trapdoor is mounted upside down, to make its top surface flush
with the floor above when closed, it is necessary to have some way to
climb through the trapdoor node when it's open. Making it climbable
like a ladder satisfies this need. It is somewhat realistic, as a real
trapdoor can have a ladder segment mounted on one face. When the trapdoor
is mounted in its default orientation, making the bottom surface flush
with the ceiling below when closed, the climbability when open is not
strictly necessary, but is still a convenience.
