This is an idea to hopefully fill a lot of needs minecraft currently has.
The basic idea is a block that, when powered, pulls in x blocks from side y and spits them out side z, kinda like a winch and chain, but with blocks.
This would immediately provide functionality for:
Floodgates
Elevators
Crush traps
Hidden doors
Large gates
Among many other potential creative uses.
To get the most out of this new block it will need several options, available on a menu.
Input: n;e;s;w;u;d
A number: x
Output: n;e;s;w;u;d
Incremental: y;n
Those 4 options are all we need for maximum versatility. Allow me to explain, though it does seem fairly self explanatory.
Input, the side the blocks are taken from
Number, how many blocks to take
Output, the side to spit blocks out of
Incremental, dictates behavior of the devise when it receives power. If "no", it will act as a binary switch, moving all blocks to the output side when powered and moving them all back when off. If "yes" it acts as a counter, only moving one block per on/off cycle, and counting in order all the way out then back in.
Now we only need some rules for consistency!
The chain should stop moving if it hits a block or runs out of room.
Air blocks/immovable blocks should break a chain
Objects/creatures should be pushed by moving blocks, unless there is no space, in which case they should be destroyed/suffocate
And that's pretty much it! Pretty simple concept, with some very powerful applications. The max number of blocks in a chain is of course up to balance, I'd say limit it to 5 or 6.
to give a visual representation of the rules, and to show the limitations of the idea, here are some graphics:
where is the new block
say we set the block like so:
input: w
number: 4
output: e
incremental: n
this would allow this:
[] [] [] []
to switch to this:
[] [] [] []
or say you want a retractable bridge/gate.
you could do:
input: e
number:4
output: u
incremental: n
which moves this:
[]
[]
[]
[]
to this:
[] [] [] []
the problem with this is it does not approximate a hinge, as it is a push/pull type arrangement, so something like this:
[]
[]
[]
[]
would not do this:
[] [] [] []
but would rather do this:
[] [] [] []
unfortunately there is no way to fix this without adding another toggle, and that would just get weird in my opinion.
anyway here are a few more examples of the rules:
say we have:
input: w
number 4
output: e
incremental: n
and we start with this:
[] [] []
after the first power on we would get this:
[] [] []
so the air space only allowed the 2 attached blocks to move.
ah, but the blocks are now attached to other blocks at the other end, so when power is lost this happens:
[] [] []
notice the last block is stuck because the other blocks ran out of room.
now the next time the device is powered on, its going to attempt to move 4 blocks from the left side to the right. there are 2 ways to handle this:
1. treat all airspace up to 4 blocks away as available and simply push extra blocks to the end, like this:
[] [] []
or 2: treat the extra cobblestone as a blocking block and allow no movement until it is removed.
my personal preference is for the first option, but i will leave it up for discussion.
and now for an example of the power! i submit plans for a color changing door (top down view):
and the bottom furnace:
input: w
number: 4
output: e
incremental: y
so the player presses a button attached to the bottom furnace from 1 to 4 times to select his color, and then throws a lever attached to the upper furnace to close the door with the color of his choice! this setup does require movement scenario 1 above, but could be made to work under the other scenario as well.
another edit: here is a list of things and how i think they should be handled:
not movable, crushed to items:
signs
torches
pressure plates
doors
paintings
ladders
plants (including leaves, but not including logs)
not movable, destroyed:
fluids
fire
not movable, blocks movement:
bedrock
obsidian
all other blocks movable, including fences
of course all blocks should still obey the other physics, so sand/gravel traveling over a hole should just fall.
This suggestion... does not suck. *Fights uncontrollable urge to glomp lucusloc*
More on topic, though, I think your "Number" input variable makes more sense as a "range" variable which would accomplish the same thing but be a lot less likely to cause problems with the game engine deciding where the conveyor belt starts and stops, i.e:
[] [] [] [] -> continued 100x
With "Number: 4" it would try to pull the blocks all the way from the far end of the "chain" of dirt blocks, 4 times. With "Range: 4" it would simply do like so:
[] [] [] [] -> continued 100x
Which makes much more sense, at least in my mind.
I also think that the "one at a time" option needs to be removed. My rational is this: It would be better if this block had two states, an on and an off, one of which caused it to behave the way you've described it and the other of which reverses the inputs and the outputs so that you wouldn't have to adjust the block every time you want the drawbridge to close instead of open. Thus, what you would more or less have is a large, custom door. When it receives power, it drags blocks one direction, and when it is unpowered, it drags blocks the opposite direction. Thus, the "one at a time" method would have no way to be reversed with Redstone, because it needs to be in its "off" state at some point to recognize the next "on" state.
The "move one block at a time" functionality really is unnecessary anyhow; I assume you left it in there for elevators, but an elevator wouldn't work with this item anyhow, because it would just place blocks around you and suffocate you.
You might also want to consider block types that should be "immune" to being moved. Fluids come to mind, though I suppose it might be worth it to allow them to be moved for the purpose of creating water "pumps." Things like stairs, slabs, and fences, all of which are oriented in a particular direction in the game world, should probably be immune to moving as well.
you have the basic idea of what i want. it is a push pull kinda deal, but the incremental option is important for logic stuff, as my last example (edited in) on my last post shows. i am sure there will be unmovable blocks, such as signs, torches, bedrock, and fluids, and how each case is handled (i.e. blocked or crushed/moved) will have to be handled according to balance issues. it is also important that "moved" blocks not just appear like a placed block, but "phase in" and push objects/creatures in the right direction. you should only get crushed if you are pushed into another block.
i should edit my second post to include a list of things i think should be movable and not movable, just for reference.
you have the basic idea of what i want. it is a push pull kinda deal, but the incremental option is important for logic stuff, as my last example (edited in) on my last post shows. i am sure there will be unmovable blocks, such as signs, torches, bedrock, and fluids, and how each case is handled (i.e. blocked or crushed/moved) will have to be handled according to balance issues. it is also important that "moved" blocks not just appear like a placed block, but "phase in" and push objects/creatures in the right direction. you should only get crushed if you are pushed into another block.
i should edit my second post to include a list of things i think should be movable and not movable, just for reference.
I have to ask, then. With the incremental option left in, how would the user be able to "reverse" the pusher bock (or whatever you want to call it)? if you can't do that with Redstone, it's pretty useless for doors, elevators, and just about any other application I can think of.
The basic idea is a block that, when powered, pulls in x blocks from side y and spits them out side z, kinda like a winch and chain, but with blocks.
This would immediately provide functionality for:
Floodgates
Elevators
Crush traps
Hidden doors
Large gates
Among many other potential creative uses.
To get the most out of this new block it will need several options, available on a menu.
Input: n;e;s;w;u;d
A number: x
Output: n;e;s;w;u;d
Incremental: y;n
Those 4 options are all we need for maximum versatility. Allow me to explain, though it does seem fairly self explanatory.
Input, the side the blocks are taken from
Number, how many blocks to take
Output, the side to spit blocks out of
Incremental, dictates behavior of the devise when it receives power. If "no", it will act as a binary switch, moving all blocks to the output side when powered and moving them all back when off. If "yes" it acts as a counter, only moving one block per on/off cycle, and counting in order all the way out then back in.
Now we only need some rules for consistency!
The chain should stop moving if it hits a block or runs out of room.
Air blocks/immovable blocks should break a chain
Objects/creatures should be pushed by moving blocks, unless there is no space, in which case they should be destroyed/suffocate
And that's pretty much it! Pretty simple concept, with some very powerful applications. The max number of blocks in a chain is of course up to balance, I'd say limit it to 5 or 6.
Please discuss.
where
say we set the block like so:
input: w
number: 4
output: e
incremental: n
this would allow this:
to switch to this:
or say you want a retractable bridge/gate.
you could do:
input: e
number:4
output: u
incremental: n
which moves this:
[]
[]
[]
[]
to this:
the problem with this is it does not approximate a hinge, as it is a push/pull type arrangement, so something like this:
[]
[]
[]
[]
would not do this:
but would rather do this:
unfortunately there is no way to fix this without adding another toggle, and that would just get weird in my opinion.
anyway here are a few more examples of the rules:
say we have:
input: w
number 4
output: e
incremental: n
and we start with this:
after the first power on we would get this:
so the air space only allowed the 2 attached blocks to move.
ah, but the blocks are now attached to other blocks at the other end, so when power is lost this happens:
notice the last block is stuck because the other blocks ran out of room.
now the next time the device is powered on, its going to attempt to move 4 blocks from the left side to the right. there are 2 ways to handle this:
1. treat all airspace up to 4 blocks away as available and simply push extra blocks to the end, like this:
or 2: treat the extra cobblestone as a blocking block and allow no movement until it is removed.
my personal preference is for the first option, but i will leave it up for discussion.
and now for an example of the power! i submit plans for a color changing door (top down view):
[] [] [] [] [] [] [] [] []
[] [] [] [] []
[] [] [] [] []
the topmost furnace is set to:
input: s
number 2
output: n
incremental: n
and the bottom furnace:
input: w
number: 4
output: e
incremental: y
so the player presses a button attached to the bottom furnace from 1 to 4 times to select his color, and then throws a lever attached to the upper furnace to close the door with the color of his choice! this setup does require movement scenario 1 above, but could be made to work under the other scenario as well.
another edit: here is a list of things and how i think they should be handled:
not movable, crushed to items:
signs
torches
pressure plates
doors
paintings
ladders
plants (including leaves, but not including logs)
not movable, destroyed:
fluids
fire
not movable, blocks movement:
bedrock
obsidian
all other blocks movable, including fences
of course all blocks should still obey the other physics, so sand/gravel traveling over a hole should just fall.
Maybe post this idea in that thread...?
Also, the stuff in Post #2 can be done relatively simply with the AdventureCraft mod.
More on topic, though, I think your "Number" input variable makes more sense as a "range" variable which would accomplish the same thing but be a lot less likely to cause problems with the game engine deciding where the conveyor belt starts and stops, i.e:
[] [] [] []
With "Number: 4" it would try to pull the blocks all the way from the far end of the "chain" of dirt blocks, 4 times. With "Range: 4" it would simply do like so:
Which makes much more sense, at least in my mind.
I also think that the "one at a time" option needs to be removed. My rational is this: It would be better if this block had two states, an on and an off, one of which caused it to behave the way you've described it and the other of which reverses the inputs and the outputs so that you wouldn't have to adjust the block every time you want the drawbridge to close instead of open. Thus, what you would more or less have is a large, custom door. When it receives power, it drags blocks one direction, and when it is unpowered, it drags blocks the opposite direction. Thus, the "one at a time" method would have no way to be reversed with Redstone, because it needs to be in its "off" state at some point to recognize the next "on" state.
The "move one block at a time" functionality really is unnecessary anyhow; I assume you left it in there for elevators, but an elevator wouldn't work with this item anyhow, because it would just place blocks around you and suffocate you.
You might also want to consider block types that should be "immune" to being moved. Fluids come to mind, though I suppose it might be worth it to allow them to be moved for the purpose of creating water "pumps." Things like stairs, slabs, and fences, all of which are oriented in a particular direction in the game world, should probably be immune to moving as well.
I have not, do you have a link?
@qlmmb2086
you have the basic idea of what i want. it is a push pull kinda deal, but the incremental option is important for logic stuff, as my last example (edited in) on my last post shows. i am sure there will be unmovable blocks, such as signs, torches, bedrock, and fluids, and how each case is handled (i.e. blocked or crushed/moved) will have to be handled according to balance issues. it is also important that "moved" blocks not just appear like a placed block, but "phase in" and push objects/creatures in the right direction. you should only get crushed if you are pushed into another block.
i should edit my second post to include a list of things i think should be movable and not movable, just for reference.
I have to ask, then. With the incremental option left in, how would the user be able to "reverse" the pusher bock (or whatever you want to call it)? if you can't do that with Redstone, it's pretty useless for doors, elevators, and just about any other application I can think of.
Hello there, there is a similar mod which may do what you are asking.
I believe Notch is going to implement similar in a future update.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
it would cycle back and forth. and example:
input: w
number: 2
output: e
incremental: y
a pulse is an on, of any duration, followed by and off of any duration.
start:
pulse 1:
pulse 2:
pulse 3:
pulse 4:
etc.