summaryrefslogtreecommitdiff
path: root/textures
diff options
context:
space:
mode:
authorelectrodude <electrodude512@gmail.com>2015-12-18 14:18:29 -0500
committerAuke Kok <sofar@foo-projects.org>2016-05-10 16:13:41 -0700
commit649c7d79f6d70251d9da93ca1c648ca2d9cc5562 (patch)
tree7da291979042fc78f3188494c97364bb35196c36 /textures
parent193a5f8db96f92c386fe22c2ed213c434bca42b0 (diff)
downloadpipeworks-649c7d79f6d70251d9da93ca1c648ca2d9cc5562.tar
pipeworks-649c7d79f6d70251d9da93ca1c648ca2d9cc5562.tar.gz
pipeworks-649c7d79f6d70251d9da93ca1c648ca2d9cc5562.tar.bz2
pipeworks-649c7d79f6d70251d9da93ca1c648ca2d9cc5562.tar.xz
pipeworks-649c7d79f6d70251d9da93ca1c648ca2d9cc5562.zip
Add Digiline Filter-Injector
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.
Diffstat (limited to 'textures')
-rw-r--r--textures/pipeworks_digiline_filter_input.pngbin0 -> 234 bytes
-rw-r--r--textures/pipeworks_digiline_filter_output.pngbin0 -> 217 bytes
-rw-r--r--textures/pipeworks_digiline_filter_side.pngbin0 -> 236 bytes
-rw-r--r--textures/pipeworks_digiline_filter_top.pngbin0 -> 236 bytes
4 files changed, 0 insertions, 0 deletions
diff --git a/textures/pipeworks_digiline_filter_input.png b/textures/pipeworks_digiline_filter_input.png
new file mode 100644
index 0000000..c1ffa53
--- /dev/null
+++ b/textures/pipeworks_digiline_filter_input.png
Binary files differ
diff --git a/textures/pipeworks_digiline_filter_output.png b/textures/pipeworks_digiline_filter_output.png
new file mode 100644
index 0000000..4c57d0a
--- /dev/null
+++ b/textures/pipeworks_digiline_filter_output.png
Binary files differ
diff --git a/textures/pipeworks_digiline_filter_side.png b/textures/pipeworks_digiline_filter_side.png
new file mode 100644
index 0000000..6a77896
--- /dev/null
+++ b/textures/pipeworks_digiline_filter_side.png
Binary files differ
diff --git a/textures/pipeworks_digiline_filter_top.png b/textures/pipeworks_digiline_filter_top.png
new file mode 100644
index 0000000..04ffda0
--- /dev/null
+++ b/textures/pipeworks_digiline_filter_top.png
Binary files differ