Sadly further testing has not provided me with the results I originally hoped for. While a single unit performs very quickly a stack of these seems to become very very slow. I don't know if that's due to the performance bug in this snapshot or something else. Also the items would be moved up the stack and then just stop halfway for no good reason at all. More testing to be done.
I'm not sure if anybody has already come up with this design but I created a rapid clock using the comparators subtract function. It's adjustable and can be as fast as the old rapid pursers but can easily be controlled without pistons.
This can be used in some cases when comparators were being used to send rapid pulses for things such as automatic emptying droppers or vertical item transportation.
It's just temporary, I think. And that WAS NOT a lighting engine, it was just tweaks to the current system.
Okay it's refereed to as a "Lighting system overhauled." in the wiki, added in 12w39a and removed in 12w40a. Overhaul sounds more then "just tweaks to the current system"
Snapshot 13w05a removed the comparators ability to auto update blocks this broke most item elevators. I've built a new stack-able item elevator that gets past this. It's a little bigger then the comparator update version but it works.
This uses the subtract function of a comparator to make a clock that will run as long as there are items in the detected dropper. It is very fast, just as fast as the original comparator item elevators as far as I can tell
It's preferable to use default or close to default texture packs when creating tutorials so anybody viewing it can immediately look at the video and know what is what.
Using comparators to send constant pulses to droppers no longer works. I have come up with a design that works to counter this though.
With snapshot 13w05a I see that Mojang is working on fixing a few lighting bugs, Does this mean they've given up on the new lighting engine they added then removed a few updates ago? Or are they just fixing a few bugs before the new render/lighting engine can be fully implemented?
I think they were talking about implementing an actual BUD block, so maybe that's why they are trying to remove these types of bugs that are not needed as features. It would be great to have a BUD block because it's hard to work in a compact space when pistons get stuck because it sees power 2 blocks up, or 1 diagonal. Also, a BUD block would be faster than pistons. I know it's a little off topic, but my mind tends to wonder sometimes.
An actual bud block would be great, but that would only fix one of the problems removing the updating aspect of the comparator adds.
Many people are aware of the comparator "bug" that allowed for comparators to force block updates where they are needed>
[Bug MC-6077] – Comparators causes block updates while idle.
This was a very useful bug that served many functions. Being able to choose where block updates happen was a very powerful tool. It allowed us to get past the quasi-connectivity of "bud switches" another example of a "bug" that is now a "feature" and will not be fixed despite it interfering with some builds.
I used this updating feature to make sand elevators work again which thanks to the timing changes in sand vs pistons all broke with the first snapshot of 1.5
This has been used to make more efficient vertical signal delivery using pistons
This has been to create vertical item transport for use with droppers.
More compact arrow "machine guns" and instantly emptying droppers will now require large clocks.
Simplified the "Jeb Door" by forcing an update caused by the "bud switch bug"
While some of these devices still work without this "feature" things like the sand elevators (to the best of my knowledge) are completely broken. I can understand not wanting to have all comparators all the time creating constant updates because that may lead to some undesired effects and potential performance drop but the usefulness of this "bug" cannot be denied so we really should get an alternative device that serves this function.
What you'll need to do, is hook up X number of wooden buttons to individual T-Flip-Flops, plus a few extra buttons for lols. Then when the TFFs synch up properly, they activate whatever it is they are activating.
A better example here: You just replace the stone buttons, with wood and place it where you need it. Not the "best" of designs, but its simple enough.
As it stands right now this design will not work in 1.5
You need to be able to craft a bowl of milk and place it somewhere then the cats will stop following you. I had a few but it was impossible to tame more because the cats following me would spook the ocelot .
It's definitely not a left hand holding sand. The block you are holding also is hidden when the hud is, so you cannot see the block and not the hud. The picture doesn't look like it has had dimensions altered to erase the hud either.
The left of the chest also doesn't look like it has a block sitting next to it or at the corner because you can still see the side of it.
0
It's not really a creation, it's more of part of a creation or a "mechanism"
0
0
This can be used in some cases when comparators were being used to send rapid pulses for things such as automatic emptying droppers or vertical item transportation.
0
20=lapis
50=iron
75=gold
100=emerald
125=diamond
Much better.
0
Okay it's refereed to as a "Lighting system overhauled." in the wiki, added in 12w39a and removed in 12w40a. Overhaul sounds more then "just tweaks to the current system"
0
0
This uses the subtract function of a comparator to make a clock that will run as long as there are items in the detected dropper. It is very fast, just as fast as the original comparator item elevators as far as I can tell
1
Using comparators to send constant pulses to droppers no longer works. I have come up with a design that works to counter this though.
0
0
An actual bud block would be great, but that would only fix one of the problems removing the updating aspect of the comparator adds.
0
[Bug MC-6077] – Comparators causes block updates while idle.
This was a very useful bug that served many functions. Being able to choose where block updates happen was a very powerful tool. It allowed us to get past the quasi-connectivity of "bud switches" another example of a "bug" that is now a "feature" and will not be fixed despite it interfering with some builds.
I used this updating feature to make sand elevators work again which thanks to the timing changes in sand vs pistons all broke with the first snapshot of 1.5
This has been used to make more efficient vertical signal delivery using pistons
This has been to create vertical item transport for use with droppers.
More compact arrow "machine guns" and instantly emptying droppers will now require large clocks.
Simplified the "Jeb Door" by forcing an update caused by the "bud switch bug"
While some of these devices still work without this "feature" things like the sand elevators (to the best of my knowledge) are completely broken. I can understand not wanting to have all comparators all the time creating constant updates because that may lead to some undesired effects and potential performance drop but the usefulness of this "bug" cannot be denied so we really should get an alternative device that serves this function.
0
As it stands right now this design will not work in 1.5
0
Yeah there just is not enough sand for multiplayer servers, even on my small server the nearest desert to spawn was stripped to stone
0
I've made so many of these things I actually have generations.
Gen 1 = timed
Gen 2 = memory based
Gen 3 = controller based (as seen)
Gen 4 = advanced controller
0