Are hydrogen preheaters supposed to work with any liquid pipe coming in the side, or only RotaryCraft pipes? The YouTube tutorial says they take any pipes, but the multiblock does not seem to activate properly if Thermal Expansion 3 fluiducts are used instead of RotaryCraft pipes. (I am using DragonAPI, RotaryCraft, and ReactorCraft 19b, and TE 3.0.0.2.)
Redstone torches cannot transmit a signal through the block they are placed on, or through adjacent blocks. However, they transmit to a block above. Construct an overhang over the torch, and do something like this:
Yes, this can be done. I would suggest replacing your levers with buttons and a memory latch; when you push either button, it flips the latch, which changes the stairs. Latches can be built pretty easily; see http://www.minecraftwiki.net/wiki/Redstone_circuits#RS_NOR_latch. Alternately, use an RS XOR gate (available on the same wiki page) with two levers as the inputs and wire the output to the pistons; this will cause either lever to flip the state of the stairs.
Interesting; how did you get the bit-to-sequenced-data to work properly? In all of my attempts to output a sequence from static bits, they spill over into each other and generally make a mess of the data.
Currently modifications are not at all restrictive. A Mod API would restrict your access to the game by limiting the level at which you are able to modify the game. If you don't believe me, ask Notch.
There is no reason that the presence of an API would force you to follow the API's rules. To quote one of the guys who taught me to code, "A good hacker can write with anything, a great hacker can write around anything."
Well, I have a working single-bit writer (schematics and pics in this post), but writing a sequence is more challenging. Right now I am trying to use one writer device to transcribe a sequence,
: Delay line repeater (starred repeater should be the regular rate minus the delay of the torches; if this is 0, give it the same delay as other line repeaters) : Normal repeater, marked with ^v<> for direction and 1234 for counter : Redstone torch, always attached to a block (will be marked with ^v<> for which if there is a conflict) : Redstone wire; * indicates the "write all" wire : Stone with redstone wire on it : Stone with redstone torch on it : The input (type of bit to be written) : Output (to/from delay line) : Input guard (allows the device to write when off; defaults to on) : Empty space (put whatever, so long as it does not alter the circuit)
Top layer: :RFlower:*
Two layers below (middle layer is just the torches on the blocks, [ ] encloses the area under the above):
The input guard defaults to on, so that the torches do not interfere with standard operation; when an input is received, it will be ignored unless the input guard is activated. My plans for creating a sequence reader involve constructing a monostable circuit that lasts for the length of the signal; the only real remaining problem is timing it properly. If worst comes to worst, a signal of length N could be transcribed by N bit writers in succession.
This sounds like a very interesting idea. Delay-line memory provides the densest possible redstone memory-storage capability known to man; the main problem is simply in reading it properly, since unlike most other aspects of redstone engineering, it cannot be held static.
I would be very interested in seeing pictures of it and in reading a more detailed description of its operation.
Would it be possible to, for example, make an 8-bit reader to that would display the information from the 1st, 2nd, 3rd, or 4th portions of a 32-bit loop of memory?
I think the biggest challenge though will be in getting the "write" operation to work smoothly, but once read and write capabilities are operational, this will be a great boon to redstone computing.
The problem with reading uniform bytes is figuring out the timing, which I have not dabbled in yet but should be pretty easy with clock generation. Hooking up a clock and counter that tells you which chunk is in the reader could be used to make RAM, but I am not going to try that until after finals. It should certainly be possible.
Also, pics.
As seen from the front (the tiny line of repeaters is my stock delay line:
As seen from the side (reader inactive):
As seen from the side (reader active):
Reader mechanism from below:
Reader mechanism from above:
Memory field:
Memory reset mechanism (should be called after the code is processed, is just a p. plate):
And last but not least, some scanned bits:
If the images need more explanation, I can write it out; maybe I will have a working writer later today?
I have constructed a large device designed to read a series of bits from delay line memory. The device reads from the delay line after receiving an instantaneous pulse, transferring seven (theoretically any amount) successive bits into memory cells. From here, the cells can be read and analyzed by a human operator or another mechanism. The present delay line only holds two seven-bit chunks, which is fine for a prototype but rather impractical for any actual use.
A link to my save. (NOTE: The save was made in a copy of the game with the piston mod installed. I believe I removed all of the pistons from the map (inc. inventory) before making the save, but if it does anything crashy this is probably why.)
FUTURE IMPROVEMENTS:
Automatic reading: Finding the proper N-clock to automatically record every M bits. The bits will still be kept until analyzed, but when the reset signal is sent it will wait until the clock pulse confirms the beginning of a new value in the memory.
Better storage: Using z-levels more effectively (read: at all) allows for a much greater density of memory cells, but needs a different reset mechanism. This is something I would have implemented right away in a production model, but the flat data field is more visible for the prototype.
Multiple-sequence storage: Hoo boy, not even going to think about this yet.
Delay-lane writer: Works on the same principle, but in reverse; the signal is prepared in memory cells and sent to the lane in an instantaneous pulse. This one is a bit harder because it requires a way to easily zero the memory being overwritten.
The eventual intent is to have command codes hooked up to SMP rails, providing a valuable log of who is taking which tracks in which directions, and possibly allowing the construction of a massive railway command centre. Right now, though, just redstone shenanigans.
No. Even 100 tnts started by redstone at one time won't.
TNT DAMAGE DOSNT STACKS!!! (WELL, LAST TIME I CHECKED ANYWAYS).
It stacks via superposition; in other words, if two TNT are placed one block apart, the explosion will be stronger at the block between them when compared to the other blocks directly adjacent to the TNT. However, if the two TNT in question are further apart than twice the radius of a blast, the overlap will be zero anyway and they will act like separate blasts.
This is brilliant. Wouldn't placing some TNT to blow it all up fix it, though? I guess that TNT could also be used to destroy the entire trap...
Damaging any part of the wiring but the XOR gate (and even then, some parts can set it off) causes the trap to trigger; burying the gate and surrounding it with obsidian makes this less of a glaring security flaw.
Otherwise, it is as vulnerable to TNTspam as any other trap.
As a habitual trap designer, I get annoyed when cutting a single unpowered wire disarms my enormous doomsday devices in a moment, or placing a single redstone torch near a powered wire can shut down my barrage of arrows. So, I decided to make wires that are highly resistant to these common defusing methods. The answer? Clocked wiring.
By attaching a clock generator to the wire and measuring if it updates, the
Signal generator:
The diode in the clock ( :Frame:, must be facing the top of the diagram ) is set to delay 3 (+1 delay from the torch). Any of the bottom row of redstone can be connected to the wire. Any portion of the wire connected to the clock will flash at a rate equal to the clock's frequency; the frequency is what matters, so time loss due to repeaters is not a problem. However, all repeaters must point away from the clock.
Signal reader:
The reader checks to see if the clock is still active; the top row is connected to the wire, which in its normal state contains the clocked signal. The repeater (once again :Frame:, but this time facing the bottom of the diagram) is set to delay 4; this causes the output of the repeater to be one cycle behind the main clock, while maintaining the same frequency. The two redstone wires, the direct connection and the delayed connection, are then fed into an XOR gate of your choice (there is a good example on the wiki) at the points marked :GoldBar:. Some rows later, the tile marked is the output of the XOR gate, which is 1 if the two are not equal (i.e. if the state changed in the last cycle) or 0 if the two are equal (if the wire has become disconnected from the clock, or a redstone torch has been attached, making this step equal to the last).
To trigger a trap, either break the wire or send a signal down it. This will cause the reader to receive a 1 or a 0 for longer than the delay, setting the two branches to be equal and changing the output of the XOR to a 0. How to use this change in state, of course, is up to you.
The only way I have found that works to "defuse" a clocked signal (not counting removal of the XOR/XNOR gate) is to attach another clock generator to the wire, and then disconnect it from the trigger mechanism; note however that the two clocks must be perfectly synchronized, otherwise, sometime in the first period, the wire will temporarily match the state stored in the repeater, triggering the trap.
WARNING: On slower SMP servers (such as the one on my laptop derp), the server can very rarely make a mistake while updating the wires, causing the trap to trigger. Thus, it may not be ideal to use these wires with any manually-reset devices such as TNT mines or collapsing floors.
Ideas? Comments? Insults?
(Sorry if this is in the wrong place, I am a stupid newbie and could not find a redstone thread or trapbuilding thread. If someone has done this already, I did not find anything, so just link me to that thread or something? Thanks.)
0
0
0
http://www.minecraftwiki.net/wiki/Redstone_circuits#T_Flip-Flop
0
Is that what you needed to know?
0
0
0
There is no reason that the presence of an API would force you to follow the API's rules. To quote one of the guys who taught me to code, "A good hacker can write with anything, a great hacker can write around anything."
0
Top layer:
Two layers below (middle layer is just the torches on the blocks, [ ] encloses the area under the above):
[
The input guard
Pics of the single-bit writer: (full-size screenshots, so linked rather than [img]'d)
The bit writer:
http://minetrade.danomagnum.com/uploads ... 41Ng==.png
The bit writer with write button and pulse generator visible:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
The bit writer with input lever and memory visible:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
Memory containing a single 1:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
With write-all wire removed; rapidly sets every single bit to the input:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png
The memory after breaking and replacing the write-all wire:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png
After flipping the input lever and pressing the write button, the memory looks like this:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png (the bit looks like it is taking up 2 slots, but this is just because I took the screenshot right as the blocks updated)
Updated save:
http://minetrade.danomagnum.com/files/245/
0
The problem with reading uniform bytes is figuring out the timing, which I have not dabbled in yet but should be pretty easy with clock generation. Hooking up a clock and counter that tells you which chunk is in the reader could be used to make RAM, but I am not going to try that until after finals. It should certainly be possible.
Also, pics.
As seen from the front (the tiny line of repeaters is my stock delay line:
As seen from the side (reader inactive):
As seen from the side (reader active):
Reader mechanism from below:
Reader mechanism from above:
Memory field:
Memory reset mechanism (should be called after the code is processed, is just a p. plate):
And last but not least, some scanned bits:
If the images need more explanation, I can write it out; maybe I will have a working writer later today?
0
I will post some screens tomorrow; it is midnight here and I need to sleep to stay sane.
0
A link to my save. (NOTE: The save was made in a copy of the game with the piston mod installed. I believe I removed all of the pistons from the map (inc. inventory) before making the save, but if it does anything crashy this is probably why.)
FUTURE IMPROVEMENTS:
Automatic reading: Finding the proper N-clock to automatically record every M bits. The bits will still be kept until analyzed, but when the reset signal is sent it will wait until the clock pulse confirms the beginning of a new value in the memory.
Better storage: Using z-levels more effectively (read: at all) allows for a much greater density of memory cells, but needs a different reset mechanism. This is something I would have implemented right away in a production model, but the flat data field is more visible for the prototype.
Multiple-sequence storage: Hoo boy, not even going to think about this yet.
Delay-lane writer: Works on the same principle, but in reverse; the signal is prepared in memory cells and sent to the lane in an instantaneous pulse. This one is a bit harder because it requires a way to easily zero the memory being overwritten.
The eventual intent is to have command codes hooked up to SMP rails, providing a valuable log of who is taking which tracks in which directions, and possibly allowing the construction of a massive railway command centre. Right now, though, just redstone shenanigans.
Thoughts? Did someone already do this? Ideas?
0
Lightningrod blocks, to stop lightning from destroying my wool and wood every bloody thunderstorm.
Crafting with glass.
0
It stacks via superposition; in other words, if two TNT are placed one block apart, the explosion will be stronger at the block between them when compared to the other blocks directly adjacent to the TNT. However, if the two TNT in question are further apart than twice the radius of a blast, the overlap will be zero anyway and they will act like separate blasts.
0
Damaging any part of the wiring but the XOR gate (and even then, some parts can set it off) causes the trap to trigger; burying the gate and surrounding it with obsidian makes this less of a glaring security flaw.
Otherwise, it is as vulnerable to TNTspam as any other trap.
0
By attaching a clock generator to the wire and measuring if it updates, the
Signal generator:
The diode in the clock ( :Frame:, must be facing the top of the diagram ) is set to delay 3 (+1 delay from the torch). Any of the bottom row of redstone can be connected to the wire. Any portion of the wire connected to the clock will flash at a rate equal to the clock's frequency; the frequency is what matters, so time loss due to repeaters is not a problem. However, all repeaters must point away from the clock.
Signal reader:
The reader checks to see if the clock is still active; the top row is connected to the wire, which in its normal state contains the clocked signal. The repeater (once again :Frame:, but this time facing the bottom of the diagram) is set to delay 4; this causes the output of the repeater to be one cycle behind the main clock, while maintaining the same frequency. The two redstone wires, the direct connection and the delayed connection, are then fed into an XOR gate of your choice (there is a good example on the wiki) at the points marked :GoldBar:. Some rows later, the tile marked
To trigger a trap, either break the wire or send a signal down it. This will cause the reader to receive a 1 or a 0 for longer than the delay, setting the two branches to be equal and changing the output of the XOR to a 0. How to use this change in state, of course, is up to you.
The only way I have found that works to "defuse" a clocked signal (not counting removal of the XOR/XNOR gate) is to attach another clock generator to the wire, and then disconnect it from the trigger mechanism; note however that the two clocks must be perfectly synchronized, otherwise, sometime in the first period, the wire will temporarily match the state stored in the repeater, triggering the trap.
WARNING: On slower SMP servers (such as the one on my laptop derp), the server can very rarely make a mistake while updating the wires, causing the trap to trigger. Thus, it may not be ideal to use these wires with any manually-reset devices such as TNT mines or collapsing floors.
Ideas? Comments? Insults?
(Sorry if this is in the wrong place, I am a stupid newbie and could not find a redstone thread or trapbuilding thread. If someone has done this already, I did not find anything, so just link me to that thread or something? Thanks.)