Github is a non-free platform owned by Microsoft. Reasonable alternatives exist, such as Gitea, Sourcehut. We need a federated, mastodon-like forge based on ForgeFed. See: https://forgefed.org
* mineclone dig times balanced
* fix pickaxey dupe
2023-09-01 15:00:50 +02:00
Github is a non-free platform owned by Microsoft. Reasonable alternatives exist, such as Gitea, Sourcehut. We need a federated, mastodon-like forge based on ForgeFed. See: https://forgefed.org
* make it boot in non mtg
* make water flow
* fix water texture warnings
* fix missing steel texture issues
* remove depreciated/unnessary default function calls
* make sounds work
* fix default formspec crashes
* fix wierd tab spacing
* additionally game dig group support
* move crafts to crafts.lua
* make crafts support various games
* Save the fakeplayer's wielded item in set_wielded_item
* pipeworks.luaentity: Return the found objects in get_objects_inside_radius
* Remove the invalid and unused on_blast return values in lua_tube.lua
This should avoid a crash when a strong explosion happens next to a Lua Tube.
* Do not access a global "nodename" in a BUG message.
This avoids a potential crash, in case the message actually appears in practice.
* Set the Flow Sensor and Fountain Head mesecons connection rules
* pipeworks.luaentity: Use the same function for move_to and set_pos
* (no functional change) Do not save the object returned by tube_inject_item into the "item1" local variable in filter-injector.lua
- Created `locale/template.txt`
- Fixed some typos
- Replace some `print("[pipeworks]"..` with `pipeworks.logger()`
- Removed "You hacker, you" from descriptions
By passing the list name and the slot index, these functions now receive
all data related to removal of an item from an inventory: the side on
which the removal is taking place, as well as which stack is being
pulled from. This means it’s no longer necessary to choose between
implementing `on_metadata_inventory_take` (which tells you which item
stack was pulled from but not from which side of the node) or
`remove_item` (which tells you which side the filter is on but not which
item stack it wants to take).
You can now make reqyests like `{group="stick"}`, `"default:pick_wood 1
30000"`, and `"mod:block <count> <exact wear> <meta>"` to match
items precisely.
If you don't specify a field, that field won't be checked. If you
specify a field in an invalid way, that rule will match nothing.
You can also specify wear as a table `wear={min, max}` to specify
a range `[min, max)` of acceptable wear values. For example,
`{name="default:pick_wood", wear={0, 32768}}` matches only wooden
pickaxes that have at least half of their life left.
You can even do things like `{count=2, metadata="whatever")}`, which
will match any item at all, as long as its metadata matches, and will
retrieve at most two of those items.
* Made digiline filter-injectors not pull a whole stack if the count is exactly 1
* Made digiline filter-injectors pull a whole stack if no count specified
* `default:dirt` still has a count of 1, but `{name="name"}` has no count
This adds a new type of Filter-Injector that waits for a digiline
message on its channel and then pulls the items described by the
message out of the inventory. It is basically a Stackwise Injector
that, on receiving a digiline message, sets its filter to the contents
of the digiline message and then activates itself.
Sending the message {name="default:brick", count=2} should do the
same thing as setting the filter of a Stackwise Filter-Injector to
two Brick Blocks and then punching it.
If no count is specified, it defaults to 1. Since this is based off
of the Stackwise Injector, it might make more sense if the default
were an entire stack. I can change this trivially.
You can also send requests like {{name="default:brick", count=1},
{name="default:dirt", count=1}}, which acts the same as setting the
filter to one Brick Block and one Dirt Block and then punching it.
If you send a string "default:dirt" instead of a table
{name="default:dirt"}, the string is passed to ItemStack and the
name and count are extracted from the resulting ItemStack. You can
also send a list of strings instead of tables: {"default:dirt",
"default:brick"}, and the first item found will be pulled.
Punching this or activating it with Mesecons currently does
nothing. I'm not really sure what would be the right thing to do in
either of those two cases, so I made it do nothing. I guess I could
make it use the previously-used filter, but I can't really see any
usefulness in that.
The recipe is probably too cheap. The darker of the two blue texture
colors could probably be better.
