| Age | Commit message (Collapse) | Author |
|---|
|
defaults to disabled, whether the node has a new formspec or not
note that furnace fuel stacks can't be split.
|
|
(e.g. if there's room for 50 of some item, and you send a stack of 99,
50 are added to the chest and a stack of 49 is rejected and sent
on to the next destination)
|
|
(in case the file gets corrupted on write?)
|
|
* make item drop by tubes nicer
|
|
break tubes on blast
|
|
|
|
by striking it with cottages:hammer, or castles modpack anvil:hammer,
or with any glooptest hammer except wood or stone.
|
|
(not needed now that tube breaking is reliable)
|
|
|
|
|
|
|
|
|
|
that is, if there are more than X number of items in a tube. Default is
40 in a tube, but breaking is also disabled by default.
(original framework by Novatux, with changes by VanessaE)
|
|
|
|
|
|
|
|
and it's not going back into a tube, reject it and pop out as an item
|
|
(too many means that something is wrong with that tube circuit)
|
|
Tweak listring behavior of autocrafter
|
|
Now goes player->source->player and destination->player
|
|
(forces them to "empty" and "off")
|
|
|
|
reuse the code from entry panel
|
|
caveats: in order to cleanly handle the entry panel, valve, and sensor
I had to rotate the valve and sensor models 90 degrees
so that their in-/outlet pipes point the same direction as the
entry panel.
This also enables proper handling of a valve or sensor turned vertically.
Some objects have rotation disabled entirely (as flipping them over/around makes
no sense)
When a valve is rotated, it is turned off automatically, to work around a glitch in
the rotation code.
|
|
(instead of on_punch)
|
|
|
|
|
|
Special-case technic machines
|
|
This makes them work correctly with filters.
|
|
|
|
Add digilines support to autocrafter
|
|
"on" and "off" messages turn it on or off, "single" crafts one item, and sending nested tables in the shape of the crafting grid sets the craft. Example message:
{
{"default:wood","default:wood","default:wood"},
{"default:wood","","default:wood"},
{"default:wood","default:wood","default:wood"}
}
|
|
|
|
for priority tube, instead of [colorize
(except for inv image). Saves a tiny bit of RAM.
|
|
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
|
|
Add list rings and enable sorting tube reordering
|
|
|
|
|
|
|
|
* Add digiline detector tube
The digiline detector tube outputs an itemstring of every stack
that passes through it on the channel specified in its formspec.
* Don't store digiline detector tube's formspec in a temporary local
|
|
The table lookup will fail if node.param2 is outside [0-3] which
is easily possible since there are several ways to modify param2
values of nodes. Force truncating param2 to always be 0-3 before
using it in a table lookup.
|
|
This shouldn't be this complex. For me, both syntaxes work,
but I bet it breaks others.
|
|
Before, init.lua called io.open on
pipeworks.worldpath..'/pipeworks_settings.txt'
to see if it existed, but did not close the resulting file handle if
it was found to exist. It instead erroneously called io.close() with
no argument, which does nothing if the default output file is set to
stdout, which it is.
Now, the result of io.open is saved to a local variable. If that value
is not nil (i.e. if the world settings file exists), the file handle is
passed to io.close before calling dofile.
Also, this saves pipeworks.worldpath..'/pipeworks_settings.txt' to a
local variable to reduce redundancy.
|
|
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.
|
|
Fixed mixup between enables for conductor and detector tubes
|
|
pipeworks.enable_detector_tube would define detector tubes but the
recipe for conductor tubes, and vice versa
|
|
|
|
|
|
|
