• 2

    posted a message on Why do so many tutorials make use of glitches?
    Glitches provide some of the most interesting engineering opportunities in this game. Intended or obvious behaviors are all fine, but it's the unintended and subtle behaviors of glitches that make you think sideways about problems and come up with solutions that push the envelope of redstone engineering.

    The fact that the glitches may get fixed/removed in the future does little to diminish my enjoyment in that process. After all, in a sandbox game with no definitive endpoint it ought to be the process that you enjoy most rather than the lasting results (at least that's my opinion on the matter). I enjoy figuring out unintended behaviors and making use of them, if only temporarily. Additionally they can enable much more advanced and capable devices for the time they persist.
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on ***Redstone Texture pack***
    I use this one:
    http://www.minecraftforum.net/topic/137113-32x32-tronic-revamped-v10/

    Nice linear redstone wire with good contrast. Pastel-tinted wool that's easy on the eyes and easily distinguishable.
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on D-Flip Flop 6x4x1
    That is a very interesting asymmetry around the F1 blocks, I'm sure it can be put to use somehow.

    I agree that it's interesting. There's got to be some clever way of making an XOR, JKFF, RSNOR latch, etc using that behavior. Maybe if I think about it long enough I'll come up with something useful.

    It is only a few more blocks to test, may as well be complete. There are known E/W and N/S quirks for rails and redstone so it should be checked out. Having checked it out completely, we now know there are no other asymmetries in mechanically (non-redstone related) provoked block updates.

    Right now it's only a few more blocks to test, but I'm worried about the complexity of testing all the various possible trigger materials (redstone wire placement, redstone wire state change, repeaters, levers, minecart track, furnaces, etc) in all the possible locations. I haven't observed any evidence that tells me there would be any violation of the symmetry. Hopefully if there is an asymmetry it will show up as a difference in our testing methods, since I am paying no attention to piston orientation and it sounds like you are (maybe I will start randomizing my piston orientation to increase the chances of uncovering an asymmetry without having to double testing iterations).

    The asymmetry in the F1 plane can be explained as follows: mechanically provoked block updates have a range of 1 from the changed block. When a piston is extended it acts like a 2 block long entity, and is adjacent to the F1 blocks. When it is retracted, it is not adjacent to them and so they do not provoke an update. By this theory, placing or destroying the block F2 should provoke an update to make an extended horizontal piston retract. I tested it, and it does (oops, I see you tested it too and recorded it). It also works for downward facing pistons to make them retract.

    This is my thinking too. A state update trigger needs to interact with a location containing part of the piston. When the piston is retracted, only position zero fits that description; when extended F1 fits that description too. In the future we will of course have to be careful to test specifically extended vs retracted states.


    I'm going to proceed with another phase of testing, replacing wool blocks with single pieces of unpowered redstone wire as my test material. Since it seems to matter if the redstone wire is connected to other redstone wire, I will be testing only isolated single pieces at first.

    [edit]
    Isolated redstone wire placement:

    Triggers in all cases:
    D2

    D1
    D1L1
    D1R1
    D1B1
    D1F1

    F1
    L1
    R1
    B1

    U1F1 (only testable for 0->1 piston state change)
    U1L1
    U1R1
    U1B1

    U2

    Triggers only when extended:
    D2F1

    D1F1L1
    D1F1R1
    D1F2

    F1L1
    F1R1
    F2

    U1F1L1
    U1F1R1
    U1F2

    U2F1


    All testing was done with a solid layer of inert blocks one layer below the testing layer. For example when testing redstone wire placement on layer D1, a layer of inert blocks formed a floor on layer D2. No blocks were above the test location, except for the obvious piston blocks when appropriate.

    This is what all the "always trigger" locations look like:


    And with the "only when extended" locations added:


    The "piston" in these conceptual representations is at the geometric center in all directions, so there is an empty space in that spot. Due to practical limitations (you can't place redstone directly on top of a piston), there is also an empty space above the "piston".

    These patterns seem like they could be the result of a mathematical convolution of an impulse function created by and centered on placement of redstone wire with the current valid coordinates of the piston block. Since the retracted piston is essentially a dirac delta function, the impulse function would be equal to the output function. In other words, placing a redstone wire triggers block updates in a pattern like this:

    D2

    D1
    D1L1
    D1R1
    D1B1
    D1F1

    F1
    L1
    R1
    B1

    U1F1
    U1L1
    U1R1
    U1B1

    U2

    where the redstone wire position is at zero. If the target piston is within this impulse function, it will be updated.

    The shape of blocks that only trigger when extended can be explained in the same manner - it is the intersection of their impulse functions with the temporary location of the piston plunger.

    [edit2] I found you overlooked U1F1 as a valid "only when extended" update location for inert blocks. At least it worked for me when using wool.

    Using the complete set of inert-block locations we can go through a similar process of determining the impulse function:






    Putting this together, it seems that redstone wire triggers primary block updates at U1 and B1, then all three of those blocks trigger secondary updates at all immediately adjacent locations. Inert blocks only trigger a single set of updates at immediately adjacent locations. It will be interesting to see if the redstone wire behavior holds true for other active materials too.
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on Sine wave
    Your sine is not a sine. For it to be a proper sine, you'd have to set the outputs of your circle signal generator to start on the transmission line at a single x-coordinate (assuming x is in the propagation direction). Right now if I'm not mistaken you have a y = sin(t+cos(t)) waveform.
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on Help resetting multiple RS-nor's
    Make sure you don't actually make any "rings" with repeaters in them. If current can travel in a loop from the output of a repeater back to its input, the repeater will stay on.

    I bet you need to just make a small break in your reset line "ring" and have it go 3/4 of the way around the circle rather than all the way around.
    Posted in: Redstone Discussion and Mechanisms
  • 3

    posted a message on D-Flip Flop 6x4x1
    There have been a couple topics popping up lately describing what appears to be a bug/quirk in piston update behavior. You can read about it here:

    http://www.minecraftforum.net/topic/554776-a-not-gate-without-a-torch/
    http://www.minecraftforum.net/topic/554668-173-piston-oddity-power-via-induction-wirelessly/

    I was inspired by this behavior to create a D-Flip Flop. I'm not really abreast of the current state of logic gate development, so this may or may not be useful or superior to other DFF designs in use now.

    Updated version:


    Size: 4Lx3Hx1W
    Speed: 1-tick delay off->on, 0-tick delay on->off

    Old version:

    D input is the lever at top left.
    Clock/Enable input is the button at bottom left.
    Q output is the repeater at right.


    This design can be tiled with no insulation space between DFFs:




    My current understanding of the piston update mechanism is as follows:
    Pistons use adjacent blocks as input to their extended/retracted state. For some reason blocks that are diagonally adjacent (one up, one behind) are polled as input, though not all the time, only when a state update of the piston is triggered from elsewhere. The D input in this design applies an input signal to one of these diagonally adjacent blocks. The clock input is at the right distance away from the piston such that it forces an update but doesn't actually transmit the clock signal into the piston state. Since the piston "reads" the D input whenever the clock signal forces an update, the output updates both on the rising and falling edge of the clock. I'm not sure about the canonical definition of the DFF behavior, but this could be easily modified to use a 1-tick clock pulse (or maybe even one of those mystical 0.5 tick pulses) to limit the DFF to a single update per clock cycle.


    I'm pretty bad at compacting redstone designs, so feel free to offer suggestions on the layout.
    Posted in: Redstone Discussion and Mechanisms
  • 2

    posted a message on Brand new redstone invention
    I am pretty sure no one has ever thought of this before, but I made this myself today and I think it's a really great idea. (I didn't hack I swear!)



    You can use the lever to activate the redstone circuitry which will extend the elevator so you can get on top of the wall. It took me a while to figure out the redstone part since I'm not very good at redstone, but I will make a tutorial for anyone who wants to build this if I get enough requests for it. (Don't forget to upvote and subscribe to my youtube channel in my signature!)

    If anyone finds this useful and wants to use it in their world just ask and I will upload a schematic just be sure you give credit to Krackor the guy who thought of this first.


    /endrant
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on smallest possible combo. lock
    Quote from Mecha*Rage

    Correct me if I'm wrong, but you can use redstone in place of the repeaters :unsure.gif:

    It would destroy the one-way signal transmission feature. That means you could replace one of the switches with a redstone torch and use it as a way to cheat and look at some of the internal signal generation information.

    i.e. replace the first lever on the line with a redstone torch, which then acts as an indicator of whether you've got the code right on all levers within redstone transmission distance of that torch. In effect it cuts down the complexity of the combination lock from 2^29 to 2^15+2^14, since you could do it from both ends and solve the two halves separately. Effectively replacing repeaters with redstone cuts down on the effectiveness of the lock by a factor of the square root, which is a pretty huge loss.
    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on 10x10 Piston Door In-Production
    Quote from Kamil

    It's not more useful, it's just more visible. What possible use do you have for a door 10 blocks high?

    Keeping the Millenium Falcon from leaving.
    Posted in: Redstone Discussion and Mechanisms
  • 5

    posted a message on Challenge: Free hugs
    Impossible to obtain a diamond without using a pickaxe?
    Posted in: Survival Mode
  • To post a comment, please .