Talk:Powered Rail/Archive 1

Reason to have gold
Finaly, a useful use for gold! --Biofan30 14:55, 16 April 2011 (UTC)

Yeah! I'm taking out my STACKS AND STACKS of gold that I never used now. --R ocĸetor talk  11:46, 24 April 2011 (UTC)

Gold tracks
Can we please remove that gold part until it is either confirmed by Notch or Jeb_, or it is actually in the game? Levy 17:39, 17 April 2011 (UTC)

It was tweeted in the very first discussion. I've added links to the entire conversation now; it's definitely crafted using gold as opposed to iron, but we don't have any evidence about the specific crafting pattern other than that there's no reason for it to be different. —KPReid 18:35, 17 April 2011 (UTC)

Boosting Effect
It looks like powered track actually will start a minecart moving if the direction is unambiguous, such as when the cart is at the end of the track. Harbinger0x7c0 16:30, 19 April 2011 (UTC)

Heh... Page got updated while I wrote the comment. Harbinger0x7c0 16:50, 19 April 2011 (UTC)

Added a short video on crafting and properties.SniperCharlie 19:20, 19 April 2011 (UTC)

It's so ineffective... Boosters give a much nicer speed then theese and are not hard to build at all. Gold still useless.--Atr755 20:39, 19 April 2011 (UTC)

Images
I can't upload images for whatever reason, so here's the large images. If someone could upload them and put them into the article, that would be great. Both are already run through OptiPNG.

On: http://i.min.us/ikCzYK.png

Off: http://i.min.us/ik8hAC.png

EvilHom3r 18:08, 19 April 2011 (UTC)


 * Thanks, uploaded both. Using the "Off" one for the image for now.  Like the Sapling image, this should probably be turned into an animated gif eventually.  -- Theothersteve7 18:24, 19 April 2011 (UTC)


 * Here is a gif, if you think that's better - http://wkter.com/dw/powered_rail.gif -- Wkter 18:44, 19 April 2011 (UTC)


 * Beautiful! Thanks.  --Theothersteve7 19:22, 19 April 2011 (UTC)

Powered Rails uphill
Has anyone found a good way to use these for hill climbing? At the moment it seems very difficult, almost pointless, to climb hills with these.
 * It seems like the detector rails doesn't work on slopes, so I just use powered tracks all the way up... Of course, that will get very expensive in the end. Your other choice is to use 1 powered, 1 regular, like this: http://wkter.com/dw/2011-04-19_22.27.16.png, however, it seems like it's cheapest and easiest to continue using boosters here. Wkter 20:34, 19 April 2011 (UTC)

If you use redstone to power it instead of the detector it works much nicer, and you only really need 1 booster every three blocks unless you would like to actually pick up speed going up the hill. Shenaniguins 04:33, 22 April 2011 (UTC)


 * short answer - gain more momentum before the uphill bit ...

I can reach clouds from sea level with just 4 boosters, a loop and a delay to switch track (credits to Alfalis for showing this trick) Lalophobia 11:13, 3 May 2011 (UTC)

I have just run some tests on the uphill movement of empty minecarts. So I have come to the conclusion that on flat ground an empty minecart can have 8 regular rails in between the powered rails. As well I have found out that going uphill with and empty minecart you need to have it set up like this (P)(R)(R)(P)(R)(R)(P)(R)(P)(R)(R)(P)(R)(R)(P)(R)(P)do you see the pattern? (P) = powered rail (R) = Regular rail. So that's the most efficient for an EMPTY minecart. (personally I just get annoyed and use 100% powered rails up hill)

"Slanted power rails" DO boost
I'd rather not go around editing when I don't now what I'm doing but it states that they do not which is incorrect. Try it out yourself. Put a bunch of normal flat rails, then have powered boosters going up. --Multisensory 19:15, 20 April 2011 (UTC)
 * I happened to do this too earlier, they do power uphill. I'll edit it and see if it sticks.
 * I can confirm they do power uphill. Look at my screenshot above. Wkter 21:29, 20 April 2011 (UTC)


 * My whole minecart track is a steep slope out of my mine. They definately power uphill (and downhill) it's the only way my track would even start! – ultradude25 ( T at 01:42, 21 April 2011 (UTC)

My test.
I have done a few small test and noticed that a powered minecart uses less coal when it goes over a Powered Rail. Please Confirm.

-Test was done on two 12 length loop tracks with one having one powered track and the cart being set off at almost the same time, time difference is a lost 3 mins longer.

Powered Minecarts also stop when the go over a Off Powered Rail.

On normal rails 1 bump from the side is enough to move a cart forward on a rail. It takes 2 to 3 bumps on a Off Powered Rail, while only 2 on a dirt tile and 1 on ice.

Anyone had the problem yet where the Powered Rail does slope on an angle if there is a no air tiles on it left/right side ? It stays flat in a sloped tunnel when I start from bottom and go up.

and my test video part one

--Axeblade346 03:12, 21 April 2011 (UTC)

Since powered minecarts use a coal over time system it would make sense that less coal would be used over a distance since it is going faster. They are both slower and heavier than an occupied minecart so when they encounter a resistance (off powered tracks resist) they are slowed a greater deal, to a stop. And yes I have that bug as well except it isn't just powered tracks no tracks will lay slanted if you go from bottom to top. Shenaniguins 04:44, 22 April 2011 (UTC)

Pictures and Series Launcher design
I don't seem to be able to add pictures, but here's a basic push-button launcher. Pic (with attached booster down the track)

And here's a series launcher design I made. You can link them together to create stations at various points on a railtrack. Pic

Avalorn 10:37, 21 April 2011 (UTC)

Powered rails can curve
Link to forum thread: http://www.minecraftforum.net/viewtopic.php?f=1020&t=300356

You can also verfiy this easily by testing in game. I edited the trivia bit in the page to add this discovery. Feel free to modify it if you don't like how I worded it, or if you can be 100% certain they always behave like normal rails (preferences of directions, and stuff like that). Bromazepam 13:38, 21 April 2011 (UTC)
 * Powered rails and detector rails do have curve pieces BUT only for two corners; northeast and southeast. It is this way because the 0x8 bit is used for the on/off state. 0x6 through 0x9 are normally used for the curves but with these only 0x6 and 0x7 work.
 * I posted a demonstration of the two possible curves for these rails on the thread, can't link it here due to spam filter.
 * Feel free to upload the gif for the wiki if it's useful. I can't do it because my account is new, I think. Mouzi 14:51, 2 May 2011 (UTC)

"Curved power rails currently only exist in the case of a T-junction. They do not currently function like regular rails in a curve (without being in a junction). It is possible to make a one-way curved railway using power rails, but not a bi-directional one." Also this whole line is false. The curves do work for NE and SE corners even if it's not a T-junction AND they are bidirectional. See the thread for proof. Mouzi 09:51, 12 May 2011 (UTC)

Powered Rails versus Boosters
Made a map that clearly shows the difference between using boosters or powered rails as a propulsion system.

Mediafire Link

Result: Powered Rails in 2 settings (1 recommended on this wiki, and the other impractical) and the single cart booster don't even make it up the slope. The double cart booster makes it up and down twice, then a 5th or so back up. Triple cart makes it over 4 times, and adding more carts apparently increases the momentum.

The momentum generated from the double cart booster is more than any practical user would ever require and a triple is sufficient enough to declare it overkill and unnecessary.

Also note that going to the top, then sliding off in a minecart from just a push generates nearly the same momentum as the first Powered Rail setting that is set to the recommended 1 Powered Rail per 25 rails with 4 Powered Rails starting it.

As far as using Powered Rails for an economical and practical propulsion system, it's just disappointing. Double Boosters are the way to go and adding 1 more cart virtually guarantees unlimited speed and momentum for any practical track system. MDR 17:01, 21 April 2011 (UTC)


 * Also thought it fitting to add an important note that displays the important differences between the 2.
 * A Triple Cart Booster can propel a manned minecart higher than 500 blocks. Powered Rails require another Powered Rail every 2-6 Rails (depending on entering momentum) just to keep the momentum up enough not to slide back down. MDR 19:17, 21 April 2011 (UTC)


 * An image or diagram might be more useful than providing the map, and "booster" is kinda vague, since how long it's boosting isn't stated. --JonTheMon 19:19, 21 April 2011 (UTC)


 * The point is space and looks, not how much it boosts. To have a constantly working booster track you just need to have a redstone torch under the block it's on, that can be completely hidden from view, which is much better than having a large ugly booster next to the track that you can't hide. – ultradude25 ( T at 03:27, 22 April 2011 (UTC)


 * Umm not really. The booster is only required from the launching zone, takes less and more available supplies to produce, and despite your belief, can easily be hidden from view in various ways. Why would you want/need a constantly "working" booster? The booster get's set on a loopback and when you require it to actually boost a cart, you send a redstone signal to the loop back track to have it switch to track that follows along the cart you wish to boost. The double cart booster takes very little space and can propel a cart much farther than 1000 blocks without losing the max speed it achieved at the point of getting boosted. Since the user above your reply requested numbers, I've decided to compare a double cart booster to a set of 4 Powered Rails which the wiki states has enough to propel the cart at maximum velocity.


 * These tests were done on a completely flat surface with no slopes or any bordering objects that could all slow down the cart.
 * Results


 * Single Cart Booster: 562 Blocks traveled (excluding the block it was on when it received it's boost) before coming to a complete stop
 * Double Cart Booster: 1531 Blocks traveled (excluding the block it was on when it received it's boost) before coming to a complete stop


 * 4 Powered Rails: 183 Blocks traveled (including the 4 Powered Rails) before coming to a complete stop.


 * At this rate, in order to travel the same distance at the same speed as the double cart booster did, according to the wiki's information you would require about 64 Powered Rails (4 being the starting force, the rest spread across the track to keep up the speed). That's 66 gold bars, 11 redstone ore, and 11 sticks without mentioning the power supply to all of those rails which would take at least 61 redstone torches. The double cart booster takes 27 iron ingots, 2 sticks, 5-15 redstone ore, 1 restone torch, 1 power trigger (botton/lever/whatever), and about 4-8 solid blocks of any kind that can freefloat without support. If you factor in the protruding space of both systems, the double cart booster still takes up less space since the initial boost is all it needs to travel that distance. MDR 11:39, 24 April 2011 (UTC)


 * Here's my two cents: we're arguing over which of these is "better". I don't think either is inherently better. I've discovered that, used in combination, power rails and boosters are very efficient. Rather than using a loopback system for my booster, I leave my double booster carts on top of a power rail which can easily and instantly be turned on. I hit the button, and I get an instant and very powerful boost without the hassle of having to make a looping booster which can switch tracks and all that other stuff. It makes for a very tidy system. I agree that double boosters are much better and resource-efficient in terms of sheer momentum gain, but power rails can be put in places where sending a booster would be impractical. You have access to both. Use them contextually. Eruerthiel 00:28, 12 May 2011 (UTC)

Levers
Instead of using redstone torches which can't be placed as easily, why not use levers? All levers use are cobble and sticks, both of which are very easily attainable resources, as apposed to redstone, which is found deep in caves. Levers can also just be placed on the side of the block the powered track is on or beside the track, making for much easier placement. On another note, powered rails that are off and sloped will stop downward movement, making small minecart stations, that hold a single minecart and release on the push of a button, quite easy. 3nd0fw0r1d

These tracks are acting REALLY odd
This is really hard to explain, but basically I have a powered rail that only accepts power from a redstone torch underneath it, or a stone button connected by wire. Even moving the stone button, but still supplying it with power through a wire doesn't work. Even putting a redstone torch on the bit of wire that the stone button uses to supply power to the track doesn't work. It just doesn't make sense...

I really have no clue what is going on. – ultradude25 ( T at 05:06, 24 April 2011 (UTC)


 * Works fine with me, place a redstone torch next to a power rail and it and any rails 8 blocks away from it will be powered. If its still not working, go ask Jeb or Notch. --R ocĸetor talk  11:44, 24 April 2011 (UTC)


 * I don't think you understand. I have a bit of redstone wire under the block the track is on, this works fine with the button I have, but if I use any other thing to supply power to that wire, it doesn't work. (the wire has power, but the rail ignores it)
 * I took some images, here the wire is powered by a stone button and the track lights up fine, here the wire is powered with a redstone torch, but the track ignores it... – ultradude25 ( T at 12:01, 24 April 2011 (UTC)


 * Wires don't always power objects above it, might have something to do the pulse power provided by the button but the toggle power from nearly anything else. Obviously there's a bug somewhere but for the time being I could only recommend using torches along your line which would require you to dig another block down since redstone wire only toggles torches when lead directly into a block with a torch above it.
 * MCP isn't out yet so I'm not gonna fiddle around trying to locate the problem although I'm sure after it's release it should be easy to see why buttons work and others don't, then create a "patch" to solve your problem. MDR 12:26, 24 April 2011 (UTC)


 * Wires never power objects above them. They can only receive power from above, not send. The reason the button in that pic is working is that powered rails are two blocks high (for the purposes of receiving power) and the button itself is touching the upper part of the rail. --Last username 16:16, 28 April 2011 (UTC)


 * Nope. Removing the wire under the track stops the button from working. – ultradude25 ( T at 03:11, 29 April 2011 (UTC)

speed / momentum
What I think is happening When you go over a (powered) Powered Rail, the momentum of the cart gets booster - not the speed.. The speed hits a cap but if you have surplus momentum you get a lot more distance ! Making this quote from the page utter rubbish.. powered rails will not provide the cart with much momentum past the cart speed limit of 8 m/s They DO! get a lot more momentum but it's not visible due to the speed cap Very crude sketch here http://dl.dropbox.com/u/16443259/speedythinggoesinspeedythinggoesout.JPG and some experiments and results in this youtube here http://www.youtube.com/watch?v=ZtY-tXBzXso Using a trick showed by Alfalis in the MC forum using a loop,couple redstone delay to switch track, and !! 4 !! Powered Rails you can go from sea to clouds, no sweat. just by building up momentum Lalophobia 14:49, 2 May 2011 (UTC)
 * Ok, while that is useful information, that video isn't. It's slow, meanders, and the really important part is done after dark. --JonTheMon 15:14, 2 May 2011 (UTC)
 * In my preview it was a lot brighter.. youtube appearantly hates low lighting scenes..
 * Already planned to retake that dark bit - but haven't been able to reshoot it yet. (video is only up for 1 day) ~ still it goes from sea level to clouds, you can quite simply recreate it in your own world,  loop with 4 boosters,  redstone delay to switch the track from loop to main track so it has a bit of time to gather momentum - and away you go :)   - thanks for the feedback 'tho ;)   Lalophobia 15:27, 2 May 2011 (UTC)
 * Probably another way to show this would be a 20-40 length track, one with all power rails and 1 with every-other power rail, and see how far each one goes up a ramp. --JonTheMon 15:55, 2 May 2011 (UTC)

I'll see what I can do and when I get a moment for it.. Preparing tracks, recording something, editing it, uploading, it all takes time.. And as you notice I'm not that great at it yet,. that 4 minute clip took me about an entire evening :| Lalophobia 10:31, 3 May 2011 (UTC

Cheers, I did some research that I might think could contribute to this section. I wanted to examine the maximum momentum that an occupied minecart could gain, so I made a small experiment. I did eleven different tracks, ranging from 1 powered rail to 640 powered rails and measured the meters the cart would travel. The results are as follows:

First column is the number of powered rails to accelerate the cart to maximum speed.

Second column is the amount of meters the mine cart traveled (on ordinary rail) before reaching a full stop.

Third column is the distance traveled (on normal rail) per powered rail.

Forth column is how far the mine cart traveled at full speed. Note that there is no data for 1 and 2 tracks. This is because the mine cart never reached full speed from the acceleration gained from those tracks. My experiments showed that a cart would decelerate for 128 meters before reaching a full stop.

I added the Fifth column just to show the diminishing returns in relation to the amounts of tracks used, using 4 tracks and 16.50 tracks traveled at maximum speed as 100%.

Feel free to use these numbers. I just wanted to share it with you guys.

Cheers,

Chris

Memory Usage
Power rails appear to increase memory usage by Minecraft exponentially based on length of track. I'm not sure if this has to do with Minecraft having to update the On/Off state of every rail as it comes into view distance or not. There is a Java issue that this links into, but while testing for bugs on my two test worlds I continue to stumble across this.

Usually it takes about 800 blocks of length (or 1,600 powered rails, two tracks parallel to each other) before Minecraft crashes. This length drops sharply the more power rails I have nearby, such as overpasses and large cargo lines, down to as little time between crashes as 100 blocks of movement or even 50.

From watching my resource use, I see that Minecraft peaks out the 1.3 Gig Java limit very quickly this way. Weather also increases the speed at which I hit the cap, sometimes with the two city test worlds I'll simply walk to the 'transit' and Minecraft will crash, causing minecart spawning and other odd glitches. What makes this irritating is that it's never time based, I can't seem to replicate the exact amount of time it takes to crash with any success. HoodedWraith 23:53, 8 May 2011 (UTC)

After testing again, I've noticed that this issue appears to be somewhat alleviated when one turns every graphics setting as low as they'll go, I top out at using roughly 500 MB, instead of hitting the crash ceiling. This isn't much of a solution, really, more of a stopgap until a better workaround comes up. HoodedWraith 01:50, 9 May 2011 (UTC)

diagonally upslope??? 11.3 m/s??
What? where? how??

diagonals are made by putting corner after corner after corner .. if you add straights (which the powered rail are) to climb ..it's not a diagonal any more, the exploit with corners being able to go up, although visibly they seem to be flat, doesn't work with powered rail since powered rail are straight..

since i know powered rail can act as corners, albeit not two ways and its bound to the south/west thing.. doesn't make them able to do a diagonal.. --- at least my tests after reading this failed...

So what the f is diagonally upslope, add some pictures or something ??

not to mention, it's already established in the article that the max speed is 8 m/s ..how do they all of a sudden go 11.3 m/s ? –The preceding unsigned comment was added by Lalophobia  (Talk . Please sign your posts with


 * I think they just mean going uphill. Since you're going up a 1:1 incline and you can go up to 8 m/s horizontally and 8 m/s vertically, that's a net vector of 11.3 m/s. --JonTheMon 21:34, 12 May 2011 (UTC)


 * It got partly improved by now, but i would still just leave it something like this since its more to do with speed/axis of minecarts in general and nothing with powered rail - for starters they cant bend that way so its just an observation that the value for distance is skewed on the diagonal and therefor elaborating on the distance results adding "The optimal spacing of powered rails between sections of such diagonal track" .. - also it needs a few references to the normal wikipedia for euclidean math, orhogally, etc..  It's a minecraft wiki, not a bleeping math test..

''With regular tracks it was already discovered that minecarts actually travel at a certain speed per cardinal axis, and so minecarts traveling diagonally on diagonal tracks (meaning a track consisting of the pattern 'left corner' attached to a 'right corner' attached to a 'left corner' ... and so on) travel more blocks in distance at the same apparent speed as they would on a single cardinal axis. Because the speed of a cart boosted by a powered rail is determined at the speed 8 m/s per axis one could say they travel at a speed of 11.3 m/s on diagonal tracks.''

The optimal spacing of powered rails between sections of such diagonal track is 1 every 36 blocks (counting orthogonally, if you count diagonally instead it is 1 every 18 blocks).


 * and i have no idea if this is worth noting in relation to minecraft - maybe worth noting if you like math..

It is worth noting that 36 is roughly equal to 26 multiplied by the square root of 2, which is the actual distance one would travel diagonally (by Euclidean math) if a player moved 26 blocks on both coordinate axes.


 * I went ahead and rewrote it

bug boosters
His exact quote is "From my changelist: "* Fixed minecarts next to each other causing extreme velocities (sorry!)"

All we can draw from that is that bug boosters will not give extreme velocities - it does not state it will stop boosting altogether. so we might best be cautious drawing the conclusions ..

It might be that the momentum boost will still occur but the bug boosted carts hit the same speed limit as the powered carts seem to.


 * It's unlikely that this bug will remain at all, according to him saying "bugs that feel wrong get fixed. The boosters have never ever felt right." (source) --Jimeowan 12:16, 13 May 2011 (UTC)


 * Don't get me wrong, you're likely right. But I don't like stating things as fact before before they are ;) Lalophobia 13:37, 13 May 2011 (UTC)

someone stop this edit war ffs
I'm getting a bit bored here, some things keep getting put back in by some people that should not be put back in. I dont care if you reformat my text, pick at grammar and whatnot but stop putting back %^$^ that isn't true..

Optimal use: Diagonal travel first talks about horizontally diagonal track, which is fine it's a subsection of the conclusion how much of a gap there can be on a horizontal track / flat diagonal but then jumps to sloped track, which is confusing at best and entirely discussed elsewhere in the page .. and this is kept being put in preferable to have powered rails constructed 2 every 4 blocks on a slope which is not true for starters as shown in other bits of the page, because this is hugely inefficient for your gold and the best thing is to gain momentum before the uphill section.. and confusing since it jumps from one topic to another .. It does point out without having sufficient stored momentum so why is the conclusion not thus it the bare minimum, in case you do not already have sufficient momentum, is 2 every 4 blocks on a slope; however it is much more recommended to gain more momentum before an uphill section .. or something along that lines...

Powered rails can be used in SMP to create train stations, though it can lag on a slower server than a faster one. This could cause the game to occasionally "crash". no reference ? no source? uuhm ?

Just tried this with 3 flat and 3 sloped downward. Didn't give me any extra height) Video proof -  http://www.youtube.com/watch?v=qtpCzT2kY-0 (besides I was comparing 6 flat/sloped up  versus 3 down, but hey .. w/e..)


 * Ok, I think we're thinking of different scenarios. My point was that sloped down are not any better than flat boosters. Your point was that carts get both the momentum from being sloped down and from the booster. --JonTheMon 15:50, 15 May 2011 (UTC)
 * Well whatever way you want to put it, the outcome is more momentum when compared so i'm sure for that reason they are 'better' ;p . I'm just glad that at least most of the page is now showing that there is a difference between speed and momentum and that when people keep that in mind it doesn't require a fortune in materials to climb a hill. Its just a bit frustrating if people edit it back to show you need a gazillion gold to climb a hill which is just bull....
 * Bear in mind that after Notch ups the power of powered rails, all this will have to be re-evaluated. --JonTheMon 16:29, 15 May 2011 (UTC)
 * Oh well, no ETA on that patch right now, so it may be a while..


 * Lalophobia, you got to realize that not everyone likes circling a cart in a loop around and around for 10-20 seconds just to get it to go over a hill - especially if you're sitting in it - that is far from optimal if the definition of "optimal" is taken to mean taking the least amount of time to travel, and minimizing the amount of gold used in the process - this is the usual practice. - Xinhuan 16:02, 31 May 2011 (UTC)

trains without the powered minecart
this one is simple-have an incline of unpowered power rails and place either a storage or empty minecart (no furnaces). then power the rails using a lever or button( preferably lever). make sure you are in the front seat and enjoy!!

The 1.6 numbers
According to http://www.youtube.com/watch?v=F7CyaCeS3fY the best practices numbers for 1.6 are:


 * Unoccupied/storage, uphill: 3 powered, 1 unpowered
 * Occupied, uphill: Alternate powered and unpowered
 * Unoccupied/storage, flat: 1 powered, 2 unpowered
 * Occupied, flat: 1 powered, 27 unpowered

The buff comes out to a 12.222% increase in acceleration.

Oboewan42 21:36, 26 May 2011 (UTC)

These numbers seem off to me. Here's what I have:

In 1.5, unmanned carts accelerated to cover 6-7 blocks after passing covered rail. In 1.6, this number is boosted to 12 blocks maximum.

Manned carts don't get the buff.

STrRedWolf 22:26, 26 May 2011 (UTC)

I can run detectors on level ground 32 standard and 1 powered and increase overall speed. Darkid 03:39, 27 May 2011 (UTC)
 * Ah-I should note that was a 1.5 server. However, rails were certainly not nerfed. So... hrm.


 * "best practices" ? you mean "results from the test without initial momentum" ? -  I really encourage staying well away from wording that can be interpreted as suggesting people to use a bunch of powered rail, just a few simple changes causing more initial momentum before an uphill section works a lot more effective and cheaper ;)  - no offense ;) Lalophobia 14:39, 27 May 2011 (UTC)


 * Oboewan42, The numbers in the video are off because he didn't not take into account stored momentum from all the powered rails before his "starting point". I have conducted several hours of tests and updated the new values. Tests can be see here: http://www.minecraftforum.net/topic/270836-all-about-powered-rails-thread/page__view__findpost__p__4991865. Using one every 27 is completely off, the optimal spacing is 1 every 42 or possibly even 43 (untested).


 * The 12.2% figure is also misleading, because it is measured distance for the minecart to completely come to a stop. In practical use, nobody waits for a minecart to completely come to a halt, you want to travel at or near maximum speed most of the time. Furthermore, the minecart's maximum speed is not changed, it is the powered rail momentum boosting that got changed. As such I have removed the video link and I am currently contacting the TaviRider on the issue so that he can adjust his video and not spread incorrect information to his 10k subscriberson Youtube. - Xinhuan 11:25, 29 May 2011 (UTC)


 * Update: His 1-in-27 isn't really wrong for optimal spacing, since 1-in-28 supposedly is 1 pixel slower. However, we will perform another set of tests on a 3km long track to find the practical speed differences and practical optimal spacing. My own tests are flawed due to the diagonal corners, as such 42 is probably not the optimal number. - Xinhuan 18:28, 29 May 2011 (UTC)


 * I think the disagreement / confusion here all stems from trying to give an "optimal" value. "Optimal" (i.e. best) is a value judgement, and depending how much a person values speed vs gold they will judge that differently. The only objective number that can be reported is the maximum speed, which appears to be from the 1-out-of-every-28 ratio. I think it would be best to simply give a table of powered-rail ratios and their corresponding speeds. People can decide what they consider optimal for themselves.--Ericjs 01:02, 3 June 2011 (UTC)


 * Table given as requested. - Xinhuan 00:54, 10 June 2011 (UTC)

Uphill
The upslope number of 1 powered rail every 4 blocks is definitely wrong for 1.6.6. It's not just not enough for maximum speed, but also not enough to get up at all; after a while (depending on initial speed) the cart will stop and fall back down.

One every three blocks (1 powered rail, 2 normal rails) works, but only at some average speed that is slower than maximum speed, about 5 blocks/s (when starting slow it gradually accelerates to that, when starting at maximum speed it slows down). With two powered rails per 5 blocks (one or two normal rails between powered rails alternating) the average speed is roughly 6.1 blocks/s, with 2 per 7 blocks (2 or 3 normal rails between) it is about 3.8 blocks/s. (These measured speeds are not very accurate, maybe +/- 0.5)

One powered rail every other block seems to give the maximum speed (8 blocks/s), which is also what TaviRider's video says. --Daniel9001 18:57, 1 June 2011 (UTC)


 * I've removed the incorrect information until more accurate information can be obtained about upslope optimal spacing. - Xinhuan 00:53, 10 June 2011 (UTC)

Speed/Efficiency for unridden carts
The data on optimal use is great, but it's missing data for carts you're not riding. I've built a behind-the-scenes rail system to carry a large collection of minecart-chests between my mine, mob murdering machine, and warehouse. Other people may have similar systems for carts they're not using that they want to convert to the modern system now with boosters getting nerfed. I can pull a functional system together on my own, but it'd be nice to have the data. (I don't know what the experimentation procedure for the regular carts, or I'd do it myself.


 * Use the method here - http://www.minecraftforum.net/topic/366339-taviriders-world-of-science/ That is, build tracks 1 to 2 km long and time them with a stop watch. - Xinhuan 00:52, 10 June 2011 (UTC)


 * Using the long straght track method, I was able to determine that, to maintain maximum speed of 8m/s, 1 powered every 3 unpowered is necessary for level terrain, and drops off significantly after that. Since my use for empty mine carts is basically an ore skip and construction material mass trasport, I also wanted to know what was necessary for infinite sustained movement.  To test this, I set up x by x squares with regular track making a loop, with a powered rail (with power, obviously) as the first block in the direction of motion after each corner (since powered rails don't gracefully handle cornering).  I set up a feed system to send minecarts in to each square with plenty of speed, and intend to leave the game running overnight and will check on what carts are still running in the morning.  So far, the 10x10 and above squares have stopped, and the 9x9 cart _almost_ stops before it reaches the next powered rail (10x10 only just misses reaching the rail - it's so close that I've moved the powered rails to the 2nd block after the corner to see if cornering has any effect - it doesn't; the cart still stops with the player-in-cart position as 1/8th of the way onto the powered rail's block (I'd guess 0.25 on is the threshold of the effect, but that's just conjecture).  For now, 8 normal rails to 1 powered rails appears to be the ratio, but I'm holding off on a firm conclusion for a few more hours. I won't be testing doubled/tripled rails - I think they'll do more harm than good with unloaded carts.  (I've also confirmed in my tests that storage carts, unloaded normal carts, and loaded carts all have the same top speed, just to be doubly sure my results are accurate before I waste an hour or two building a non-functional storage cart ore skip.) - Rashkavar 05:29, 7 October 2012 (UTC)
 * I am now confident that 1 powered rail every 9 blocks will run indefinitely, if very slowly. I'd create a video of my testing rig, maybe even a timelapse of it running for a long time, but I've never found a screen recording program that doesn't do cruel and unusual things to my computer.  (I've tried fraps, hypercam, and a couple of others without success. If someone who's computer isn't camera shy wants to create documentation for the test, just make a 10x10 box of rail and an 11x11 box of rail, each of which has 1 powered rail per side.  The 10x10 box will run indefinitely; the 11x11 box won't.  (I know I just said 1 every 9 - if you actually count the rails on the perimeter of a 10x10 square, there's 36, not 40.)  I'll update the appropriate portion of the main page to reflect these results. Edit: nevermind - this has already been done.Rashkavar 05:28, 8 October 2012 (UTC)

"Optimal Use"
There seems to be something wrong with this chart.

For starters, a train traveling at higher speed shouldn't take longer to travel the 2km distance. As it says when comparing 1 every 37 blocks, takes 252 seconds at 8m/s speed, while 1 every 38 blocks takes 251 seconds at 7.97 speed.

And how come using less powered rails gives less speed loss? Comparing 1 every 35 blocks and 1 every 37, latter which gives full speed all the time and former having speed loss of 1.2%? Could someone please do some math and tell me what I am not getting?

Besides, are the values the average of several measurements (running the whole 2km track) or did he just run the track once? Sanzennin 11:08, 21 July 2011 (UTC)
 * I got to agree that those Numbers just look wrong. But you don't need to average them as this is a computergame. There is no influences likes windspeed, grip, shifting gears or anything. So 1 run is enough.


 * Still he seems to have done it wrong. Depending how much time i got over the weekend, i might pick some of the data and do my own test to see if i can back up his numbers, and if the wrong looking ones actually are a problem in the game mechanic. --Andy hc 12:42, 2 August 2011 (UTC)


 * With numbers like that, with how it seems to jump back up and then down, I would mark the numbers to human error in how the test was set up (maybe a cart not being in EXACTLY the same start position, etc). Assuming all things constant in the game, a stray code or computer fluctuation (lag), or maybe a bione condition activating (raining), and the code load lagged just a tad to through things off.

I've noticed a pile of discrepancies from "1 every 37 meters" to "1 every 33 meters". They shouldn't be less effective than 1 every 38 meters. They should have higher speed. They should also have less slowdown. The data here should be one-directional, that is, as you space the rails further and further apart, the results should be lower and lower, not sometimes lower and sometimes higher. It smells like either someone griefed the table or someone slipped up when making the table. 98.239.103.193 15:12, 15 October 2011 (UTC)

I think the reason for the difference in numbers is the number of ticks spent on each rail. Some configurations may lead to only 2 ticks spent on a powered rail instead of 3, causing less momentum gain, so closer rails may in fact cause less gain. To know for sure I would need to do some tests and some math. I agree "1 every 37 blocks, takes 252 seconds at 8m/s speed, while 1 every 38 blocks takes 251 seconds at 7.97 speed." looks wrong, there may be an error there.


 * Wait, wait... If optimal use is 1 powered track per 38 tracks, then why does it also say optimal placement for red torches are supposed to be 1 per 13 blocks? Why would you use a red torch if you are putting a powered track 3x apart?
 * Because it says the optimal spacing for _torches_ is 13, not red torches. This is assuming you have a 2 block high, 1 block wide tunnel underground and are lighting it to prevent monster spawns in the subway system.  (Redstone torches, or switches, would be positioned evenly with the powered rail (preferably 2 blocks down and covered if you're concerned about the aesthetics issue.  Switches have to be mounted on the block under the powered rail, so if you want it directly under, you have to get below the block and mount it on the bottom face.  Given how common redstone is once you have an ores mine set up, I'd say just go with the torch.  Omnidirectional power is far more convenient.) Rashkavar 05:39, 7 October 2012 (UTC)

Power
Maybe this changed in version 1.0, but I tried various ways of powering these rails before coming here for solutions, but I found that only a power source next to the rail will power it; underneath won't. Levers, redstone torches, and wires connected to power supplies all work for me if they're next to and on the same level as the track, but placing the redstone torch or a wire underneath the block the tracks are on doesn't power it for me. 78.105.8.153 15:59, 22 November 2011 (UTC)
 * Odd, I tried again but also put a redstone torch to the side; the redstone torch to the side made it come on, but taking it away left it on, presumably due to the one underneath the ground. Maybe that's me misunderstanding how the torches work, or maybe it's a bug. 78.105.8.153 16:04, 22 November 2011 (UTC)
 * So it turns out that the powered rail only recalculates its state when a block adjacent to it changes. Placing a dirt block next to the rail and then removing it again will force it to recognise that it should be powered. 78.105.8.153 14:55, 24 November 2011 (UTC)

Survival Mode
With Abandoned Mines, making extensive rail networks and the like is practical in Survival Mode (since abandoned mines can contain quite a bit of pre-made rail). Has anyone explored the feasibility of using powered rail in survival mode—it seems like the quantity of gold required could be a problem? (Is it feasible to attempt to send storage carts this way, as well, or is it best to put them in front of a powered cart, even on powered rail?) 109.246.254.186 14:41, 29 January 2012 (UTC)

Storage Minecarts & Boosters
I can't get storage carts to work with boosters. Is it possible that someone investigates the acceleration effects on storage-carts and writes a tutorial on how to use them? That would be nice...
 * If you mean boosters as in the old method of speeding carts along, they don't work anymore.
 * If you mean boosters as in powered rail setups to give lots of momentum to a cart before sending it off, they're only practical for person-carrying carts. Empty carts (including carrying anything except a player (and perhaps a mob - I've never tested that or read about it), like storage or powered carts) lose momentum ridiculously fast.  It might be doable, but you'd have to leave it in the momentum generator so long you might as well manually cart your loot up to where it's going yourself.
 * For a distributed powered rail system, I've been able to determine that to sustain maximum speed, you need a powered rail every 3 rails (so normal-normal-powered-normal-normal-powered), assuming regular patterns only (I wouldn't use a 2/7 powered and evenly spaced setup or the like, so I'm not going to test it), and it seems like 1 every 9 (8 normal, then 1 powered) to sustain movement if speed is not an issue. I'll be adding that information to the main page in the morning - my perpetual motion test is still ongoing.
 * Rashkavar 05:49, 7 October 2012 (UTC)

Adjacent parallel Rails
I have retextured rails to solar panels for a map I am making and I am currently having difficulty trying to place two diagonal rails next to each other, when I place two rails next to each other, they automatically link up, creating a two long horizontal piece of rail. I have tried using pistons. Please advise.
 * The game really doesn't handle turning powered rails gracefully, which might be the issue. Presumably this will be fixed eventually, but it's been a problem since they were added.  For regular rails, as long as you don't put a piece of the 2nd track next to an open end of the first track, you shouldn't have an issue.  Once the game decides a rail is curved, it stays curved in that direction even if you put other rails nearby, so things like parallel rails or subway stations are much easier to build.  (Preferential direction issues are only of import when a cart encounters a 3 way or  4 way junction, or if you're laying a track down for such a junction with the tracks leading to it already laid.)

Doesn't Drop Resource
I broke one with a pickaxe and to my surprise, it's now gone forever. It doesn't drop the resource when broken. How come there is no mention whatsoever about this in the article? It would be extremely useful to know ahead of time. 71.103.162.226 07:46, 28 July 2012 (UTC)

Xbox 360
The 3x3 powered rail loop does not appear to work on the Xbox 360 version; it does not accumulate momentum, just acts as 4 powered rails.

Hitbox on slope
Article says under trivia: "If a powered rail is on a slope, it has the hitbox of a normal, unsloped rail." Pretty sure this is no longer the case. Any idea what version this was in? Then we could put that - or just delete it?

Outdated info on storage minecarts (chest/hopper) as of 1.6.2
As of 1.6.2 (and probably since the introduction of hoppers/mincart with hopper in the 1.5 redstone update), storage minecarts (that is, minecarts with chest/hopper) no longer behave identical to empty minecarts. Storage minecarts' performance with powered rails now depends on their load (also see the discussion of MC-7799).

I propose that comprehensive information on storage minecarts' behaviour be collected here, to be eventually integrated into the page. IMO, it would be best to have a Minecart Mechanics page sometime in the future, into which all info on moving minecarts (powered rails or powered minecart combined with all minecart types) could be consolidated; all the minecarts' pages could then link there.

Here is a simple comparison of minecart behaviour. Setup is, all in a straight line: solid block, one powered rail, many normal rails. The minecart sits on the powered rail, against the solid block. The solid block then receives power from a stone button. The following table records how far the minecart travels after the button is pressed (i.e., "8" means that the minecart comes to a standstill on the 8th rail after the powered rail). "Minecart" means an normal minecart ("full" means occupied by the player); "Storage Minecart" means both a Minecart with Chest and a Minecart with Hopper, as these behave identical. A Minecart with TNT behaves identical to an empty normal minecart.

Thus, regarding powering requirements, a fully loaded storage minecart represents the worst case; anyway, even a fully loaded storage minecart performs way better than an emtpy minecart. I have done some tests on the effect of different powered rail spacings with fully loaded minecarts; I will insert the results here when I find the time. Haven't done slopes yet, not sure if I will find the time. Anyway, the information would probably be much more comprehensive and accurate if it would be deducted from the code. Does anyone have the capacity and time to do so?

--Thilo77 (talk) 05:59, 25 October 2013 (UTC)