There has been much craze over the new command blocks that are coming to 1.9. Not only do they remove the annoying job of creating fill clocks, but they also present a nice, clean aspect to command block redstoning. Chain command blocks are one of the most useful as they provide a clean, quick way of executing your commands (1 block/tick) with numerous options to toggle in order to make a solid command sequence. But lately, I have been working on a Minecraft Minigame Map, and I've noticed an issue that could easily be solved with this simple block.
The Tick Extender Block (or just "Tick Extender") provides an easy way to place a precise pause within a long line of Chain command blocks.
"But this can already be done! Why not just use repeaters?"
True. Repeaters can be used in a long line leading up to the next command block. But with the Tick Extender, you can save space and time. There are few things that are more annoying in Minecraft than having to place down a repeater, click it three times, then move forward. *click* *click* *click* *click* (move forward) *click* *click* *click* *click* (move forward).
The Tick Extender has a clean, simple GUI - similar to that of a command block - and is used by either inputting a tick amount directly into the box, or using the up and down arrows for a quick tweak.
Possible texture for the Tick Extender:
(Numbers on the side do not reflect the digits inputted into the block)
Like the other command blocks, an arrow shows which way the signal will continue.
The highest amount of ticks that the Tick Extender can reach is 999999 ticks.
999999 ticks:
= 49999.95 seconds
= 833.3325 minutes
= 13.888875 hours
(I'd like to point out that this GUI is a re-textured crafting table which explains some of the derpy textures)
So in conclusion, the Tick Extender is a simple to use block which can help to keep your contraptions clean and neat but also provide a nice tool to use whenever you're performing the tedious process of timing different command blocks at once.
I'm not that good at ending threads...
Thanks?
Yeah... Thank you.
Rollback Post to RevisionRollBack
"Life happens wherever you are, whether you make it or not."
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Nah. If this is added tons of other similar blocks would have to be added (tick delayer, tick shortener, etc. etc. etc.), which would probably cause some sort of lag or confusion.
Other blocks won't have to be added. Heck, a new block won't need to be added if it was just an option. It acts like a repeater, nothing else. Why would other command blocks need to be added anyways? Wouldn't it be a good thing for map makers if new command blocks need to be added?
And the lagument is invalid in most cases. Several command blocks don't lag a player, especially in 1.9, but lots of them could depending on the specs of the PC.
New types of blocks don't lag players? I thought if there were 500 items in minecraft instead of 200 items it would cause a little more lag when it goes to check what kind of item it is. Does it work like that?
"If this then why not this?" isn't a terribly valid argument, I agree. So instead, let me explain:
1) "This has so few uses. Why should there be an entire block for it?" is the first point of my argument. It's not often you need a tick extender.
2) "It's mechanically no different from using redstone repeaters." Seriously, if this doesn't fit in your circuit then you can just use wireless redstone methods to put it elsewhere. There are probably already advanced methods to compress it to a very small space.
3) "Because of the above reason, I would far prefer that they made something else." There are circuits that absolutely must delay a command block creation a tick, like comparators. That puts huge limitations on a lot of stuff, like my creation here.
(Also, don't chain command blocks trigger instantly, rather than 1 per tick? Please answer this, because I might be doing it wrong.)
I don't know how chain command blocks are triggered, but I know that they are all triggered at once, but in order. This suggestion merely adds delays and is more flexible than repeaters. "One commands" could make good use of this. Multiplayer friendly machines could make good use of this.
I know it can be useful. It's just a redundant feature (redundant because it isn't necessarily "better" than using a setblock technique, just a little easier to build), and there are much better redstone things to be added, like delay-less comparators.
I mean, maybe if there was a library of 100 command block functions, this would be nice as one of them, but otherwise, it's not worth taking up the UI space for.
Anyhow, now it's getting really subjective so we might as well end this argument.
Conditional doesn't actually work with testfor, because the testfor succeeds regardless of whether it finds the player. But I did find a method to testfor without comparators (assuming you are testing if there is one player that satisfies the condition rather than more than one player): /execute @p[condition] ~ ~ ~ /setblock x y z redstone_block. Cool, right?
I know I'm super late, but thanks for all the support and feedback!
I do understand that adding an entirely new block with such a simple function might be unreasonable, but as others have said, I think just adding another togglable option to the existing command blocks would work as well.
Again, thanks for the support!
Rollback Post to RevisionRollBack
"Life happens wherever you are, whether you make it or not."
INTRODUCTION:
There has been much craze over the new command blocks that are coming to 1.9. Not only do they remove the annoying job of creating fill clocks, but they also present a nice, clean aspect to command block redstoning. Chain command blocks are one of the most useful as they provide a clean, quick way of executing your commands (1 block/tick) with numerous options to toggle in order to make a solid command sequence. But lately, I have been working on a Minecraft Minigame Map, and I've noticed an issue that could easily be solved with this simple block.
The Tick Extender Block (or just "Tick Extender") provides an easy way to place a precise pause within a long line of Chain command blocks.
"But this can already be done! Why not just use repeaters?"
True. Repeaters can be used in a long line leading up to the next command block. But with the Tick Extender, you can save space and time. There are few things that are more annoying in Minecraft than having to place down a repeater, click it three times, then move forward. *click* *click* *click* *click* (move forward) *click* *click* *click* *click* (move forward).
The Tick Extender has a clean, simple GUI - similar to that of a command block - and is used by either inputting a tick amount directly into the box, or using the up and down arrows for a quick tweak.
Possible texture for the Tick Extender:
(Numbers on the side do not reflect the digits inputted into the block)
Like the other command blocks, an arrow shows which way the signal will continue.
The highest amount of ticks that the Tick Extender can reach is 999999 ticks.
999999 ticks:
= 49999.95 seconds
= 833.3325 minutes
= 13.888875 hours
(I'd like to point out that this GUI is a re-textured crafting table which explains some of the derpy textures)
So in conclusion, the Tick Extender is a simple to use block which can help to keep your contraptions clean and neat but also provide a nice tool to use whenever you're performing the tedious process of timing different command blocks at once.
I'm not that good at ending threads...
Thanks?
Yeah... Thank you.
"Life happens wherever you are, whether you make it or not."
Could be very useful for us redstoners.
Though, I do agree with AThingWithAThing, why not just add the option in the command blocks?
Either way, it's a good idea.
Support
Brother, you got yourself a support.
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Unofficial Suggestions Guide (2.0) - by Theriasis
Unofficial Critics Guide - by yoshi9048
Nah. If this is added tons of other similar blocks would have to be added (tick delayer, tick shortener, etc. etc. etc.), which would probably cause some sort of lag or confusion.
No support.
Spears, Daggers, and Hammers for 1.9
New types of blocks don't lag players? I thought if there were 500 items in minecraft instead of 200 items it would cause a little more lag when it goes to check what kind of item it is. Does it work like that?
"If this then why not this?" isn't a terribly valid argument, I agree. So instead, let me explain:
1) "This has so few uses. Why should there be an entire block for it?" is the first point of my argument. It's not often you need a tick extender.
2) "It's mechanically no different from using redstone repeaters." Seriously, if this doesn't fit in your circuit then you can just use wireless redstone methods to put it elsewhere. There are probably already advanced methods to compress it to a very small space.
3) "Because of the above reason, I would far prefer that they made something else." There are circuits that absolutely must delay a command block creation a tick, like comparators. That puts huge limitations on a lot of stuff, like my creation here.
(Also, don't chain command blocks trigger instantly, rather than 1 per tick? Please answer this, because I might be doing it wrong.)
Spears, Daggers, and Hammers for 1.9
I know it can be useful. It's just a redundant feature (redundant because it isn't necessarily "better" than using a setblock technique, just a little easier to build), and there are much better redstone things to be added, like delay-less comparators.
I mean, maybe if there was a library of 100 command block functions, this would be nice as one of them, but otherwise, it's not worth taking up the UI space for.
Spears, Daggers, and Hammers for 1.9
Well, I mean, if the devs get around to it.
Anyhow, now it's getting really subjective so we might as well end this argument.
Conditional doesn't actually work with testfor, because the testfor succeeds regardless of whether it finds the player. But I did find a method to testfor without comparators (assuming you are testing if there is one player that satisfies the condition rather than more than one player): /execute @p[condition] ~ ~ ~ /setblock x y z redstone_block. Cool, right?
Spears, Daggers, and Hammers for 1.9
I know I'm super late, but thanks for all the support and feedback!
I do understand that adding an entirely new block with such a simple function might be unreasonable, but as others have said, I think just adding another togglable option to the existing command blocks would work as well.
Again, thanks for the support!
"Life happens wherever you are, whether you make it or not."