Behold! I've created TaviRider's World of Science, current version 1.1. It's full of experiments for exploring the behavior of minecarts and pistons in Minecraft, and you can download it.
Videos
It was the basis of most of the tests in these videos:
Minecart Conclusions
To keep a minecart at top speed on level ground, repeat a pattern with one powered rail followed by 37 unpowered rail. Here's the raw data I used to determine this, with a nice science-y chart: Minecart 2km travel times
Minecart collisions on straight track traveling east/west cause the minecarts to stop in place.
Powered rail became 12.222% more powerful in version 1.6.
Sloped track is approximately 40% longer than flat track
Occupied carts accelerate more slowly than unoccupied
Piston Conclusions
Pistons cannot push: bedrock, dispensers, note blocks, obsidian, dungeon spawners, chests, furnaces, jukeboxes, portals, signs, extended pistons, and chains of blocks longer than 12.
Objects are almost always destroyed if they are pushed into invalid places, such as pushing a cactus into open air. The one known exception is minecart tracks.
Pistons break redstone connections in 0 ticks and connect them in 2 ticks.
Players, objects, and mobs fall through a single block, but do not fall if they straddle two moving blocks.
Pistons do not do damage to players or mobs, but they can damage players or mobs by pushing blocks into them.
In Windows press Windowskey-R to open the Run dialog, type %appdata% and press Enter. Go into .minecraft/saves.
In MacOS go to ~/Library/Application Support/minecraft/saves
In Linux go to ~/.minecraft/saves
Unzip the contents of the .zip file into the saves directory.
Launch Minecraft and select Singleplayer. You should now see a new world called TaviRider's World of Science. Select it and start exploring!
Thank you TaviRider. Will be waiting for your download link!
Are you able to provide a 1.5 compatible version of the map for download too (so I can fiddle around with a 1.5 copy for comparison)?
The download link is up!
As far as I know you can plop this map into 1.5 safely, but you'll have to tune the starts of some of the tests to make sure you don't have excess momentum built up. See the first video (link will be there momentarily) for details about that.
hey tavi, love your vids. i though i found your world of redstone but i only found about 8 small redstone circets. there was just an update but i couldnt see anything in the distance. did i find the right one? anyway im going to take your challenge on about making it go further. also id like to see some tutorials. but for now ill have to keep looking for the right version of the world of redstone and try and copy it the desighn. and again thanks for the usefull and entertaining videos.
Played with your world a bit Tavirider. On a hunch about how the momentum system works, I took the upslope challenge and rearranged it like this (see topmost track).
The basis here is that we want maximum momentum when we reach the white starting line, so we want to bunch as much powered rails as we can against the white starting line. Thus, the goal is to use as little powered rails as possible to reach the white starting line, then put all the remainder powered rails against it.
The single lonely powered rail is about as far up the slope as I can place it without the cart sliding back down. The last 7 are all bunched up against the starting point (at which the cart barely made it up the rest of the slope before touching the 7).
This reached almost 7 meters further than your furthest one:
The placement of the 7 powered rails didn't matter much at the top, moving the single non-powered rail around resulted in at most half a block of difference (but the furthest one is the one all bunched against the starting white line, the closest being all 7 bunched away from the starting white line).
If your theory on the 3232323 or the 454545 pattern is correct, then if the spacing of powered rails is an even number, you would have a 50% chance of getting the prail boosts always on 2-ticks the entire track, and 50% chance of getting 3-tick boosts the entire track. Obviously this doesn't quite work out since travel times are consistent and isn't 50/50 sometime taking very long, sometimes not.
Also, 10 ticks occur in a second, not 20 (or 2 as said in your post).
If the cart travels 0.8m/s over 1 tick (which is 0.1s), then every 4 tracks, it would go over a track piece to gains 2 ticks, so the pattern is more like
21112111
Again this suffers the same problem, if prails are spaced out in a multiple of 4 (such as 1 every 36), then it would have a 1/4 chance of being extremely fast and 3/4 chance of being extremely slow.
To add my own input, I've come up with a theory of my own which seems to fit. After several tests (many of which involved butchering up the world of science :tongue.gif:) I beleive the real culprit here are ticks and how ticks work.
This is beautiful work!
The way that Minecraft determines which block a minecart is on may be a bit more complex than you theorize. I think so because of one specific example:
Someone recently demonstrated a redstone-less minecart launcher. It involved a block with a stone pressure plate on it, and a sloped powered rail leaning against the block. A minecart could be positioned so that it was both on the unpowered powered rail (and therefore stationary) and on the stone pressure plate. When the player climbs into the cart, it depresses the pressure plate, powering the powered rail, and the cart moves.
So it may be taking into account the size of the minecart, not just on which block its center lies.
I have also just verified with your map that 37 interval does take 251 seconds, and 38 interval takes 258 seconds to travel 2km (didn't do the rest).
This confirms your findings that
A) Minecarts travel at 8m/s.
:cool.gif: 1 in 38 makes is about 3% slower.
(I didn't actually check the spacing of prails, but I will assume you did it right :smile.gif: )
Thanks for the independent verification. Science in action!
I'm pretty confident in the rail spacing because it didn't involve me counting anything. I used MCEdit's clone feature, with a repeat count that I would type in manually. The number was also verified as I then duplicated each length of track for 2km.
Hey everyone, I've updated the World of Science to version 1.1, with a new section on pistons, a new set of conclusions, and a video. See the first post for details.
Objects are almost always destroyed if they are pushed into invalid places, such as pushing a minecart track into open air. The one known exception is minecart tracks.
This sounds to use minecart track as the example, then use minecart track as the exception.
Not entirely true either. To be more specific, pistons extend in 1.5 redstone ticks (or 3 minecraft time ticks). However, retraction is a bit more complicated. If retraction of a block causes a circuit to break (by pulling a powered block back) or causes a circuit to form (by pulling said block over a torch or next to a repeater that is on), said circuit responds in 0 ticks. The actual retraction is not 0 ticks though (that is, you can't push the retracted block immediately until some ticks later without causing bugs such as the block being non-sticky).
Details in page 17-18 or so of Grizdale's piston logic compendium thread in the Redstone forum: http://www.minecraftforum.net/topic/413949-grizdales-piston-logic-compendium/page__st__300 (See #post 320 for the proof) with a bit of back and forth argument before/after that post, see the next 3 pages at least, with some linked videos. There's even a video demonstrating a 0.015s time taken to transmit a redstone signal a distance of a couple hundred blocks (although it takes significantly more time to reset said device).
Also, using noteblocks to test the time delay between 2 circuits is questionable, because in another thread, it has been shown that if a piston loses power from one side at the same time the same piston gains power from the other side, the piston will act as though it lost power momentarily.
Players, objects, and mobs fall through moving blocks.
Not always. If you stand in certain positions between 2 blocks that are moving, there are spots you don't fall through (wasn't it your video that showed this too?). This is why a spider will never fall through a floor that is completely moving (http://www.minecraftforum.net/topic/418026-piston-mob-farm/) while all other creatures will.
You might also want to explore the "northwest rule" for pistons. That is, if a block is going to be pulled by many sticky pistons at the same instant, the block prefers to be pulled up, north, west, south, east in that order (not sure about down).
Now, my theory on the sloped power tests. First a set of rules for minecarts (just my guess based on your tests):
- Consecutively placed (touching) boosters add to the final momentum (or top speed) of the minecart when it leaves the boosters.
- Separated boosters do not add as efficiently as consecutive boosters. (the more separated the less effective)
- A minecart on a slope will have acceleration to natural top speed (top speed without boosters) or deceleration to 0.
- Boosters on slopes affect the carts approx. the same as flat boosters (adding acceleration/momentum).
Now the explanations of results.
Downhill:
1- Ended with 8 consecutive boosters and ended farthest down the track.
2- Ended with 8 consecutive boosters and ended the furthest BACK on the track.
3- Ended with 8 consecutive boosters and ended at the end of the slope.
4- Boosters separated by two but booster acceleration was combined with slope acceleration resulting in an unnatural top speed.
5- Boosters separated by 1 and there was no combination of gravity and booster accelerations allowing the slope to "accelerate" (or decelerate) the cart to a natural top speed.
Uphill:
1- Ended with 8 consecutive boosters and ended farthest down the track. Had the cart made it, it would have been the farthest.
2- Ended with 8 consecutive boosters and ended before the deceleration.
3- Ended with 8 consecutive boosters and ended at the end of the slope deceleration.
(now here are the strange ones)
4- Boosters separated by two but the combination of the separation and the uphill deceleration nigh unto nullifies the uphill acceleration and deceleration. Ends with two boosters separated by two farther back than track 5.
5- Boosters separated by 1 with the boost before the deceleration of the slope gave enough speed and momentum (more than 4) to get it up the hill with a resulting speed (right after the deceleration of the slope) approx. the same as 4, and ends with 4 boosters separated by 1 as apposed to 2 boosters separated by 2 resulting in much greater momentum.
Hope you are able to catch all of that. I might just look at the minecart source code and come back to see how each bit affects the speed momentum etc.
One important thing to be careful about when placing powered rails is that the boosing effect of a powered rail is not always the same, but depends on how many ticks the minecart spends on it. A minecart travelling at maximum speed on a straight track spends either 2 or 3 ticks alternating on each block, so powered rails should only be placed at 3-tick positions for the best effect. Moving a powered rail forward or back one block along the track can make a big difference.
Here's how occupied minecarts work according to the decompiled source.
During each tick update (20 times per second), the minecart's momentum (considered to be a scalar here for simplicity) and position are modified as follows:
If the minecart is on a sloped track, the momentum is increased or decreased by 0.1171875 m/s (15/128).
If the minecart is on an inactive Powered Rail, the momentum is halved, or set to zero if it was less than 0.45 m/s.
The minecart's position is corrected to bring it to the middle of the track, by moving it perpendicular to the track direction. For curves the track is treated as a diagonal straight line, e.g. from (0,0.5) to (0.5,0).
The minecart is moved according to its momentum (that is by 1/20 of its momentum) in horizontal track direction, with the movement limited to 0.4m in each N-S and E-W direction. The vertical position is set according to the track's slope at the new position.
The momentum is scaled by 0.997 ("friction").
If the vertical position changed due to a sloped track, the momentum is increased or decreased by 0.75 m/s for each meter of height difference.
If the minecart was on an active powered rail before the update, and the momentum is greater than 0.15 m/s, it is increased by 0.9 m/s. If it was on a flat powered rail with less momentum, and there is a normal block at one end of the powered rail, the momentum is set to 0.3 m/s.
Some efficient powered rail placement sequences for travelling at maximum speed derived from this, under the assumption that the minecart starts with enough momentum for maximum speed and that its motion is correctly synchronized to spend 3 ticks (and not just 2) on the first powered rail:
One powered rail every 38 blocks, or P N^37 (where P means powered rail, N means normal rail, and N^37 means 37 normal rails) for straight tracks,
Even more efficient for straight tracks: P N^37 P N^37 P N^39,
For uphill tracks: (PN)^5 NN (powered rail on every other block, but instead of every sixth powered rail use a normal rail). The momentum needs to be at least 8.117 m/s at the first tick on each powered rail, otherwise the slope would cause it to drop below 8 m/s before the acceleration is added.
Or even better for uphill: ((PN)^5 NN)^4 (PN)^4 NN.
For diagonal tracks: P N^53. N's mean alternating left/right curves here; the momentum at the first tick of a powered rail must be at least 11.28. Since 53 is odd the straight powered rail will be rotated by 90 degrees after each iteration, so this will go strictly diagonal.
Better for diagonal tracks: P N^53 P N^56, will also go strictly diagonal.
Even better for diagonal tracks: (P N^53 P N^56)^2 P N^56, but this will drift away from the diagonal.
All excellent points. I've clarified the language to this:
Quote from TaviRider »
Objects are almost always destroyed if they are pushed into invalid places, such as pushing a cactus into open air. The one known exception is minecart tracks.
Pistons break redstone connections in 0 ticks and connect them in 2 ticks.
Players, objects, and mobs fall through a single block, but do not fall if they straddle two moving blocks.
That's what I get for not proofreading it one last time before posting it. Thanks for the corrections.
You might also want to explore the "northwest rule" for pistons. That is, if a block is going to be pulled by many sticky pistons at the same instant, the block prefers to be pulled up, north, west, south, east in that order (not sure about down).
The southwest rule doesn't affect that situation. What I have noticed several times is that the distance from the source of power to the piston affects the result. I think the winner simply depends on which piston gets updated first while Minecraft is processing a single tick.
Videos
It was the basis of most of the tests in these videos:
Minecart Conclusions
Piston Conclusions
How to get the World of Science
In MacOS go to ~/Library/Application Support/minecraft/saves
In Linux go to ~/.minecraft/saves
Raw data
Some people have asked for more specific data on the minecart tests. You can view a spreadsheet containing the raw data, or download an .xls spreadsheet containing the raw data.
Are you able to provide a 1.5 compatible version of the map for download too (so I can fiddle around with a 1.5 copy for comparison)?
The download link is up!
As far as I know you can plop this map into 1.5 safely, but you'll have to tune the starts of some of the tests to make sure you don't have excess momentum built up. See the first video (link will be there momentarily) for details about that.
The basis here is that we want maximum momentum when we reach the white starting line, so we want to bunch as much powered rails as we can against the white starting line. Thus, the goal is to use as little powered rails as possible to reach the white starting line, then put all the remainder powered rails against it.
The single lonely powered rail is about as far up the slope as I can place it without the cart sliding back down. The last 7 are all bunched up against the starting point (at which the cart barely made it up the rest of the slope before touching the 7).
This reached almost 7 meters further than your furthest one:
The placement of the 7 powered rails didn't matter much at the top, moving the single non-powered rail around resulted in at most half a block of difference (but the furthest one is the one all bunched against the starting white line, the closest being all 7 bunched away from the starting white line).
This confirms your findings that
A) Minecarts travel at 8m/s.
:cool.gif: 1 in 38 makes is about 3% slower.
(I didn't actually check the spacing of prails, but I will assume you did it right :smile.gif: )
Also, 10 ticks occur in a second, not 20 (or 2 as said in your post).
If the cart travels 0.8m/s over 1 tick (which is 0.1s), then every 4 tracks, it would go over a track piece to gains 2 ticks, so the pattern is more like
21112111
Again this suffers the same problem, if prails are spaced out in a multiple of 4 (such as 1 every 36), then it would have a 1/4 chance of being extremely fast and 3/4 chance of being extremely slow.
This is beautiful work!
The way that Minecraft determines which block a minecart is on may be a bit more complex than you theorize. I think so because of one specific example:
Someone recently demonstrated a redstone-less minecart launcher. It involved a block with a stone pressure plate on it, and a sloped powered rail leaning against the block. A minecart could be positioned so that it was both on the unpowered powered rail (and therefore stationary) and on the stone pressure plate. When the player climbs into the cart, it depresses the pressure plate, powering the powered rail, and the cart moves.
So it may be taking into account the size of the minecart, not just on which block its center lies.
Thanks for the independent verification. Science in action!
I'm pretty confident in the rail spacing because it didn't involve me counting anything. I used MCEdit's clone feature, with a repeat count that I would type in manually. The number was also verified as I then duplicated each length of track for 2km.
Yes, that's Tyken's Test World.
This sounds to use minecart track as the example, then use minecart track as the exception.
Not entirely true either. To be more specific, pistons extend in 1.5 redstone ticks (or 3 minecraft time ticks). However, retraction is a bit more complicated. If retraction of a block causes a circuit to break (by pulling a powered block back) or causes a circuit to form (by pulling said block over a torch or next to a repeater that is on), said circuit responds in 0 ticks. The actual retraction is not 0 ticks though (that is, you can't push the retracted block immediately until some ticks later without causing bugs such as the block being non-sticky).
Details in page 17-18 or so of Grizdale's piston logic compendium thread in the Redstone forum: http://www.minecraftforum.net/topic/413949-grizdales-piston-logic-compendium/page__st__300 (See #post 320 for the proof) with a bit of back and forth argument before/after that post, see the next 3 pages at least, with some linked videos. There's even a video demonstrating a 0.015s time taken to transmit a redstone signal a distance of a couple hundred blocks (although it takes significantly more time to reset said device).
Also, using noteblocks to test the time delay between 2 circuits is questionable, because in another thread, it has been shown that if a piston loses power from one side at the same time the same piston gains power from the other side, the piston will act as though it lost power momentarily.
Not always. If you stand in certain positions between 2 blocks that are moving, there are spots you don't fall through (wasn't it your video that showed this too?). This is why a spider will never fall through a floor that is completely moving (http://www.minecraftforum.net/topic/418026-piston-mob-farm/) while all other creatures will.
Now, my theory on the sloped power tests. First a set of rules for minecarts (just my guess based on your tests):
- Consecutively placed (touching) boosters add to the final momentum (or top speed) of the minecart when it leaves the boosters.
- Separated boosters do not add as efficiently as consecutive boosters. (the more separated the less effective)
- A minecart on a slope will have acceleration to natural top speed (top speed without boosters) or deceleration to 0.
- Boosters on slopes affect the carts approx. the same as flat boosters (adding acceleration/momentum).
Now the explanations of results.
Downhill:
1- Ended with 8 consecutive boosters and ended farthest down the track.
2- Ended with 8 consecutive boosters and ended the furthest BACK on the track.
3- Ended with 8 consecutive boosters and ended at the end of the slope.
4- Boosters separated by two but booster acceleration was combined with slope acceleration resulting in an unnatural top speed.
5- Boosters separated by 1 and there was no combination of gravity and booster accelerations allowing the slope to "accelerate" (or decelerate) the cart to a natural top speed.
Uphill:
1- Ended with 8 consecutive boosters and ended farthest down the track. Had the cart made it, it would have been the farthest.
2- Ended with 8 consecutive boosters and ended before the deceleration.
3- Ended with 8 consecutive boosters and ended at the end of the slope deceleration.
(now here are the strange ones)
4- Boosters separated by two but the combination of the separation and the uphill deceleration nigh unto nullifies the uphill acceleration and deceleration. Ends with two boosters separated by two farther back than track 5.
5- Boosters separated by 1 with the boost before the deceleration of the slope gave enough speed and momentum (more than 4) to get it up the hill with a resulting speed (right after the deceleration of the slope) approx. the same as 4, and ends with 4 boosters separated by 1 as apposed to 2 boosters separated by 2 resulting in much greater momentum.
Hope you are able to catch all of that. I might just look at the minecart source code and come back to see how each bit affects the speed momentum etc.
Quoted from post #103 here: http://www.minecraftforum.net/topic/270836-all-about-powered-rails-thread/page__st__100
All excellent points. I've clarified the language to this:
That's what I get for not proofreading it one last time before posting it. Thanks for the corrections.
The southwest rule doesn't affect that situation. What I have noticed several times is that the distance from the source of power to the piston affects the result. I think the winner simply depends on which piston gets updated first while Minecraft is processing a single tick.