This enables the feature of unsticky pistons. This allows
for some nodes to be unpullable, but otherwise pushable or diggable.
A certain selection of nodes that can never be moved.
And, stops certain entities from being pushed if they shouldn't move.
Along with this change; I've also updated the rules regarding
pushing, and pulling of nodes & objects to be more accurate to MC.
Now allowing for more complex redstone circuits to be built.
* Added another special case to the item entity registration for
lodestone compasses, without this a dropped lodestone compass would
turn into a regular compass on being dropped.
* Update the compass and lodestone compass frame number to be the
stereotype frame.
* The nature of a compass was being determined by looking at its meta.
This caused lodestone compasses with unset meta to turn into regular
compasses. Fixed by using string matching on the itemname.
* Changed lodestone rightclick handler to explicitly set the correct
name and frame of the compass used on it instead of waiting for
globalstep to do this.
* Split up `get_compass_image()` into smaller functions. This allows
for better code sharing between old and new API and globalstep fn.
* Add `get_compass_itemname()` function. It will be the new API of
choice, `get_compass_image() will be deprecated soon.
* Remove function declaration out of globalstep function.
* Various other performance improvements.
* Add local aliases for global functions
* Lodestone compasses can only stack 1 item.
* Document functions and variables.
* Fix lodetone compass inaccurately reusing compass descriptions.
* Add usage descriptions to node definitions
* Refactor craftitem registration code.
* Update translation templates.
This spawns a villager per bed on village gen and saves the bed
position in the entity. If it moves too far from the village
it gets teleported (for now) back.
By adding cobbled deepslate to the group "cobble", it automatically
inherits all crafting recipes and tool repair capabilities that apply
to that group.
* Add `cobble=1` to cobbled deepslate node definition groups. This
requires a little refactoring of the deepslate variants registration
function.
* Remove stone tools, furnace and brewing stand crafting recipes.
* Register "cooking" crafting recipe for deepslate ores that enables
smelting these ores in furnaces.
* Extend deepslate ore registration function to allow passing cooking
result as argument.
* Update the deepslate ore table to include smelting results.
* Put deepslate w/ lapis drops in a separate table, making the deepslate
ores table less unwieldly.
The discussion about how to handle the new ores is still ongoing.
This PR was originally only intended to add the new nodes so
that's what it does now.
* In commit 86b2cd70f907dccb161bbdbb99e1770647ba2a76 an extra argument
was added to the `add_large_plant()` function in order to handle silk
touch. For some reason, the callers for "double_grass" and
"double_fern" were updated with two new arguments. Because of this,
silk touch likely never worked on these nodes. This commit removes
the unused `nil` argument from both callers.
* This commit fixes#2155.
If a player wants to make a path when there is no dirt with grass on the
ground it means they need to either have silk touch to collect dirt with
grass or place dirt beside dirt with grass and wait for the grass cover
to spread before they can create the new paths …
Since the former is not possible early in the game and the latter is not
easy, this patch imitates Minecraft 1.17 behaviour; the following nodes
can now be turned into path nodes by right-clicking them with a shovel:
• Dirt (mcl_core:dirt)
• Coarse Dirt (mcl_core:coarse_dirt)
• Dirt with Grass (mcl_core:dirt_with_grass)
• Mycelium (mcl_core:mycelium)
• Podzol (mcl_core:podzol)
A group “path_creation_possible” has been added to mark nodes that can
be turned into a dirt path with a shovel. One obvious objection to that
addition might be that the “dirt” group already exists. Even though all
existing nodes that can be turned into a dirt path do indeed belong to
the “dirt” group, it is not a good idea: Changing what “dirt” means to
“any node that can be turned into a dirt path” would make it harder to
maintain the code.
