I know the game's in beta, but goodness. The up-and-down insanity cost me my cache of screenshots (a hasty deletion coupled with an accidental recycle bin emptying. I know, I know, and my dog ate my homework). In any case, I began doing some redstone work on Dankcraft and realized I had no clue what I was doing. Being ever sensible, I split the difference -- I created a clunky, expensive non-redstone cart-boosting system for ol' Danks, then experimented on a single-player map until I got a redstone system that works.
If you're unfamiliar, here's the deal with making your minecart zoom:
1. Powered rails, the legitimate (read: intended) system to power minecarts, got a significant boost in 1.6. This is because the efficient, but goofy, booster bug -- which was used to power carts previously -- was removed in that patch, and powered rails require a _lot_ of gold.
2. Gold is the second-rarest ore in the game. At the old exchange rate of gold: boost from powered rails, you'd have to turn a continent upside-down to get your minecart to go any significant distance. It wasn't favorable at all, and God forbid if you wanted to go uphill.
So, being the jump-right-in type, I skipped the obvious first step (that is, testing how far powered rails can shoot a minecart up an unpowered incline). In other words, I honestly have no clue how excited I should be about my system.
But, in other news: the system works!
Here's a snap of the heart of the system -- a toggle switch. (A warning to those sensitive to such things -- this redstone wiring is very, very inefficient and awkward. My next pass will tidy up / look to maximize space. I can probably halve the square feet this monster takes up.)
A toggle switch takes up about 36 square meters to do one thing -- whenever you feed a charge of redstone power into it (in this case, via a card going over a pressure plate) its output will switch to "on" or "off."
This is the launch pad. It does two things -- it provides an initial jolt to get the minecart going, and switches that curved rail momentarily to put the cart onto a loop. The powered rail on the loop is always turned on (hence the torches) so the loop would have no end if it weren't for nearly 1,000 square feet of wiring.
Here's a view of the loop. The two raised sections are pressure-plate rails; whenever the cart passes over one, it sends a pulse of redstone charge through redstone lines. The loop is necessary because of how Minecraft adds momentum to moving items -- the more powered rails a minecart passes over, the higher its momentum. A high-momentum minecart will lose speed at a slower rate, which means you can rocket to silly heights by building up momentum in a setup like this.
Here's the first cringe-inducing wiring. The far detector rail -- behind the camera and to the right in this photo -- powers the toggle switch, seen here, via underground wiring that leads to that turned-off torch on the left. This is terrible and inefficient and miserable and you shouldn't do it; this is what happens when you design things as you go. Version 2.0 will be much cleaner, and version 3.0 will be far more compact. (That's the version that'll go on Dankcraft once the server updates to 1.6.)
This is how I track the number of times I've gone in a circle. This 3x3 setup -- of two torches that feedback into themselves -- is a 1-bit memory cell. This cell can hold one piece of data -- "on" or "off." It's "off" now; when you feed a charge into the lit torch closest to the camera, it lights the darkened torch in the center. (That's "on," if you were in suspense still.) To reset the circuit, feed a redstone charge to the center torch while it's lit. When this circuit is "on," it then sends a charge to a logic gate ...
That looks like this. This might be a little confusing, but this logic gate is actually in the "off" state. When the two torches on the stone blocks are depowered, it turns on the darkened torch in the front -- that's "on." One torch is depowered when our memory circuit from above is on; the other is depowered when the toggle switch from above is turned "on." When properly calibrated, this logic gate gets turned "on" after 1 revolution on the loop. It's connected to another memory circuit, which connects to another logic gate, which connects to wiring to switch the track. This chain is only limited by your space and patience -- redstone circuits aren't instant, but this system has a built-in resilience to desynchronization. However, it's space-hungry. (I'm going to try tinkering with a binary system. The upside to that system is that, with similar space, you can record many, many more revolutions; the downside is that it's very complicated and offers a poor return on your space / redstone investment until you're looking at 3+ memory circuit / logic gate combinations.)
When both my memory circuits / logic gates are lit, a final memory circuit provides an uninterrupted flow of power through this redstone ...
To this curved rail, forcing it to change to allow the cart to escape onto the new track.
This track has a third detector rail; when the cart passes over this, it resets all my memory circuits to "off." This also closes the loop again; if I had an odd number of rotations, I'd also want to wire this detector rail into a logic gate shared with the first detector rail. That way, this would reset the toggle switch to the default "off" position to keep the system synced up. (A desynced system won't matter when you're doing an even number of revolutions, but it would add half a revolution to systems designed for an odd number of revolutions. The end result would actually be an additional full revolution, meaning that a desynced three-revolution system would send the rider on four revolutions -- which would generate power while saving space, and may be worth considering if I can get a more-compact track.)
Back to the stars!
This system feels incredibly powerful -- I shot up these 18 points of vertical ascent without breaking a sweat. However, I don't know how good simple powered rails are now, and I didn't bother testing because I'm a tweedle-dum; I'll go back and check that later. This ramp will also get extended up another 70ish meters to see if this system can hit the ceiling of the map. Also, if it's not apparent from my items, this was all legitimately harvested and created. From start to finish -- loading up the map to end of experiment -- was about a 4-hour process. In other words, once there's an established blueprint, any miner worth his or her salt could get this guy up and running from scratch in about 2 hours. There's another system I'm going to try, in which the initial push-button booster triggers a delayed redstone charge circuit on a tiny, 8-square track. It's nowhere near as cool, but it's guaranteed to use far fewer resources and take up a ton less space.
And John's discovered the joy of taking everything in the game underground. Unlike myself -- who was hard at work updating then downdating then upgrading then downgrading -- John was hard at work on his dwarven fortress on our server. Pics, and my Nether portals experiments (they only crash the game half the time!) next time.
Remember, if you want to play with us, just shoot me a message and I'll add you to the whitelist. The IP? It's 50.23.67.132:25617, thanks for asking. (That port at the end -- the :25617 -- is necessary, because we're on a virtual server.)
Don't forget about my successful operation to steal cable from you using the Fargates. Which have nothing to do with the Stargates.
ReplyDeleteOh, and that does seem incredibly inefficient. I was thinking of making a cart system to carry people around on the dwarven highway, but yea, that looks crazy. Maybe I'll just throw in some quick and easy things before I go all out and make the Temple of Doom ride.
ReplyDeleteYou can do a far simpler thing using just powered rails and torches; this is a) to achieve a ton of vertical lift with limited gold (not a problem on our server) and b) because I could.
ReplyDeleteFound a little glitch -- I forgot to account for the memory circuit's continuous flow. Essentially, tripping one trips all of them immediately; the way to avoid this is to add inverters before the even-numbered logic gates, on the toggled input.
ReplyDeleteAn inverter turns an "on" signal into an off one; essentially, the logic gates will be half "on" as default, and when the "on" signal is sent from the toggle, that will flop the signal to full "off." The end result is the signal from the memory circuits is forced to stop and wait for the toggle signal at every logic gate.