The aim of this thread is to examine how Nether Portals are created and how they are linked to each other between the Nether World and the Normal World.
Basic Knowledge:
Nether World is related to the Normal World in the 1:8 ratio in terms of distances. When you move 1 block in the Nether, it corresponds to 8 blocks in the Normal World.
This does not apply on the Y-Axis, the Nether Realm has the full 128 layers and is 1:1.
Nether Portals transport you between the Nether World and the Normal World.
A Portal Block is the purple shiny non-solid block, and always exists in a 2(wide)x1(long)x3(tall) formation within an Obsidian frame (minimum 10 obsidian blocks).
Nether Portals do not remember what portal they are linked to in the other world, they perform the following whenever a portal is used by a player:
The following always happens when you enter a portal:
Summary version
Calculate the destination coordinate based on the entry coordinate. (X, Y, Z) <---> (X*8, Y, Z*8). That is, the X and Z coordinates are multiplied or divided by 8, depending on direction of travel. The Y coordinate is not modified.
At destination, the game looks for the closest active portal block within a 128 block radius of the player (257x257x128 tall area centered on destination coordinate). An active portal is defined as a portal block that does not have another portal block below it, thus only the 2 lowest portal blocks in the obsidian frame are considered. If one exists, teleport the player to the closest one.
If no active portal blocks exists in the above search region, the game creates one by looking for the closest possible valid position within a 16 radius column (33x33x128 tall area centered on the destination coordinate) that has enough space to spawn a portal and is on solid ground. The game prefers to create the exit portal with the same facing orientation as the entry portal, but will check the other 3 directions as well. Regardless of orientation, the closest valid position is always picked.
And if there are no valid spawn locations within the spawn region above, the game will finally create a portal at the destination coordinate (and clamp the Y-coordinate to between 70 and 118), converting any blocks (including air blocks) in the way into a portal. Such a portal has 4 extra obsidian blocks placed on both sides of the portal to prevent the player from falling.
Calculate the destination coordinate, based on the entry portal's position. X and Z coordinates are divided by 8 (not rounded down!) when entering the Nether. Conversely, X and Z coordinates are multiplied by 8 when entering the Normal World. The Y coordinate is not modified. Note that every portal has 2 possible entry coordinates as it is 2-wide.
In the destination realm, the game searches for an existing exit Portal to teleport the player to. This is performed by searching around the destination coordinate in a region 257x257x128 column centered on the destination (i.e. X and Z go from -128 to +128 around the destination, and the whole Y range is checked). The Euclidean distance to each existing portal is calculated and the closest one is picked.
The search for portals is an X(ascending), Z(ascending), Y(descending) loop (X outermost loop, Y innermost loop) in the 257x257x128 region centered on the destination.
For every block in the considered region, if the block is a Portal block AND doesn't have a Portal block below it, calculate the Euclidean distance (the 3D distance) of the Portal block to the destination coordinate. This means that only the bottom 2 Portal blocks of each active Nether Portal is distance-checked, and each Nether Portal is thus distance-checked twice.
The game picks the closest Portal Block to teleport the player to. If 2 Portal Blocks are equidistant, the first found is picked.
If no existing portal is found within the 257x257x128 region (this region is NOT chunk based) then the game spawns a Portal. It does this by looking for a suitable position in a 33x33x128 search region column around the player:
A "preferred" direction is chosen (whether the portal faces North, South, East or West), based on the entry Portal's orientation.
A search is performed within a search volume where X and Z vary from -16 to +16 relative to the destination coordinate, and Y varies the full 128 layers (X(ascending), Z(ascending), Y(descending) loop, with X being the outermost loop and Y being the innermost loop))
For every NON-AIR block in the search region that has an AIR block above it, a test is performed to see if a Portal can be erected at that location going in any direction (preferring the chosen one, but iterating through the three), such that the portal rests on solid ground AND exists in air AND that there's ground and air on both sides of it (i.e. a flat area 3 x 4 blocks in size with a clearance of at least 4 blocks vertically (the lower obsidian rim of the portal will be buried). The closest (Euclidean distance) potential site from the destination coordinate is remembered.
If the above search yields nothing, then it is repeated but only requiring sufficient empty space for the portal itself (i.e. a flat area 1 x 4 blocks in size with a vertical clearance of 4). Again the closest (Euclidean distance) potential site from the destination coordinate is remembered.
If neither search yields a clear site then the destination location and the preferred direction is used, the Y coordinate will be clamped such that it is between 70 and 118, and a small 3x2x3 volume will be constructed out of obsidian and air, such that the active area of the portal has an obsidian floor to step out on each side, and air to step out into. This replaces the original blocks in the original 3x2x3 volume.
Finally, a portal is built at the site, and then the "find nearest portal" code re-executes (and will find the new portal).
Example with math
Suppose you press F3 and see that you are at (10.2, 61.6, 20.7) just before you are about to zone from the overworld into the nether. Your feet is basically at (10.2, 60, 20.7). After dividing by 8, you reach (1.275, 60, 2.5875), and the game uses this coordinate as it is as a double without rounding down to integers.
Lets say (-2, 64, 2) is a nearby active portal block, the game would then calculate the squared distance between (1.275, 60, 2.5875) and (-1.5, 64.5, 2.5) in real numbers as a double (it doesn't bother with the squareroot). That is, it uses your expected exact coordinate and the exact center of blocks (which is the block's integer coordinate +0.5D):
The actual distance is 5.287559 after taking square root, but its not necessary to do that since the smallest distance is still the smallest regardless of whether you square root it or not.
Implications
Portal travel is coordinate dependent. That is (x,y,z) <---> (x*8, y, z*8) and every time you enter a portal. It is at the destination where the game then calculates where to actually put you. If there is a nearby portal within 257x257x128, it places you at the closest one, distance is calculated by real 3-dimensional distance. This can cause 2 portals in the Normal World to both link to the same Nether one. [Portals don't remember who they are linked to, it is calculated fresh on each use.]
In fact, 2 Normal World portals that are within 1024 distance of each other on either X or Z axis are almost always going to link to the same Nether realm portal on initial construction because 1024 translates to a distance of 128 in the Nether Realm, and the game checks for existing Portals within 128 radius around the destination (the 257x257x128 box).
To setup pairs of portals properly so that they reliably travel to each other, it is best to build both portals manually. Build at desired location X,Y,Z in the Normal World. Then travel to the Nether World. And then dig your way to X/8, Y, Z/8, and build a portal there. You can then destroy the initial auto-generated portal which is probably offset from the real intended destination portal location by a significant distance. [You should destroy the auto-generated portal because it creates a zone of exclusion for new portal pairs, see next paragraph.]
The portal spawning algorithm can only spawn portals that is within a 33x33 block column centered on the destination. This will often cause it to spawn a portal at a Y-level that is far higher or far lower than the "exact matching" level. Lets say this height difference is 60 distance difference. In order to maintain this pair of portals to link to each other reliably, no other portal must be constructed within a 60 distance radius of both portals in both worlds, otherwise they would be considered "nearer" and link to them instead. This in effect creates a 480 block exclusion zone in the Normal World (centered on the Nether->Normal expected coordinate) whereby a new pair of portals cannot be made without causing REALLY WHACKY portal behavior (seen all the complaints on the forums?). [Manually pair portals as close as you can in all 3 coordinate axes. It doesn't have to be exact, or even all that close, as long as you know/ensure that no other portals will be constructed in the exclusion zone created by the difference.]
The portal choosing algorithm can be used for long distance travel by manual construction at carefully selected coordinates. Say you have a Portal in Normal world at (0,64,0) but make a Nether Portal at (127,64,0). And then you have another Portal in the Normal World at (1016, 64, 0). The last 2 of these will be a perfect pair. But the portal at (0,64,0) will go to the Nether Portal correctly (1-way trip). So in about 15 seconds, you can travel 1016 blocks. [Fast travel by Portal is One-Way, and usually used to go from bedrock to surface in Normal World, by constructing a pair of near-perfect surface portals, then making sure the bedrock portal in the mines selects the nether portal of the surface pair as its closest.]
It is possible to end up in a situation where a Nether Portal "randomly" places you in 1 of 2 possible Normal World destination portals. This is simply because the Nether Portal has two effective coordinates as it is 2 blocks wide, say (X, Y, Z) on the left, and (X+1, Y, Z) on the right. If you entered on the left side, (X, Y, Z) ----> (X*8, Y, Z*8) and picks a portal closest to that. If you entered on the right side, (X+1, Y, Z) ---> (X*8+8, Y, Z*8) and the game picks a portal closest to that. This situation occurs when the Nether Portal's location is roughly equidistant between the 2 Normal World portals. For the 2-in-1 Nether portal to occur, the distance of one surface portal cannot be more than 8 blocks further than the other surface portal. [Having 2 Nether Portals side by side might be better for destination clarity, rather than a 2-in-1 portal. (I tested the 2-in-1 portal myself - it works!)]
Take care in coordinate calculations. When you press F3 standing at a portal block and see (35.5, 93.63, -29.5), then the block you are actually standing on is (35.0, 92.0, -30.0).
X, 35.5 ---> 35.0 Because the decimal part is chopped off.
Y, 93.63 ---> 92.0 Because Steve is 1.63 meters tall.
Z, -29.5 ---> -30.0 Because even though the decimal part is chopped off, it chops off to the next lower integer. If it doesn't, then -0.5 and 0.5 would both go to 0 and that's wrong. In coding terms, math.floor(-29.49) gives the result -30. That is, rounding down is not the same as rounding towards 0.
The portal spawning algorithm, IN THEORY (I didn't try it), can be used to access the Void below. Make a portal at the lowest possible level of bedrock (layer 1) in World A. Clear out the bedrock as best as you can in World B in the corresponding expected position. Make sure there are no nether portals in World B within a 257x257x128 region around the expected position. Because the spawning algorithm looks for the closest possible spawn position to the expected location, it would be the location at layer 0 (which is solid and has an air block above it), and replace the 4 bedrock blocks with obsidian during the creation of the portal. [Will someone care to test this theory of accessing the Void?]
It is possible for a destination Nether portal to spawn floating in air above a lava lake. This can only occur if there is no possible spawn location in the entire 33x33x128 column of search region to find a suitable spot to place a fresh new portal AND there are no existing portals within the 128 block radius to link to. [See Portal Spawning Algorithm at top of post.].
Credits:
Iriel for looking in the code.
erich666 for the powerpoint slideshow.
Edits:
Correct some spelling, etc
Add Credits
Add Summary Version
Add Slideshow by erich666
That was the biggest headache I have ever gotten. Could you please put up a more simplified version or add some pictures to break the wall of text. I appreciate your commitment to finding out this science but it won't do much good unless it can be translated into simple talk.
Is there anyway to build two portals topside within 1024 blocks and have them not connect for sure?
Also, just a fun question, can you light a portal within another portal, when two of the portals cross?
Read the post slowly then. It's a "Science" thread, meaning its explained in high detail, and not simplified. If you want to link and pair portals properly, you need to understand how it works.
You simply have to build each pair of portals manually. Each portal selects the closest one in the other realm. So to unlink the 2 portals topside within 1024 blocks from each other, they need to each have a corresponding nether portal as close as possible in their "expected coordinate position" in the nether.
As for lighting a portal within another when they cross, nothing happens when you try to light the second. The fire just burns and dies after a while.
Thanks to Xinhuan and Iriel for working all of this out, super useful information!
Where did you get the fact that Iriel wrote that? It's nowhere in the post. And the fact that you have 1 post and it just happens to be encouraging someones post makes it seem like you are a copy.
Rollback Post to RevisionRollBack
Quote from rikachu »
The Minecraft forums: Where we must know your age, gender, weight, and sexual preference.
Quote from institutions »
15 dollars isn't even that much.
I don't go on a tirade of rage and fury when I buy a pack of gum that tastes gross.
Where did you get the fact that Iriel wrote that? It's nowhere in the post. And the fact that you have 1 post and it just happens to be encouraging someones post makes it seem like you are a copy.
Thanks for posting. The 2-in-1 portal is a neat trick that I never properly understood. I appreciate your explanation of the portal spawning, although I manually place portals on both sides in order to avoid it. Manual placement avoids nearly all problems players have, but they must be placed properly on both sides to function.
Thanks for this! The two in one portal trick is particularly interesting.
The description is lengthy yet very much appreciated. I'm not sure how pictures (other than perhaps examples using plain grids) would help this description.
i understood about half of it....
or a quarter... or maybe less.....
but i can see you put a lot of work into this.
never really understood portals/redstone/ores/minecraft/life
Where did you get the fact that Iriel wrote that? It's nowhere in the post. And the fact that you have 1 post and it just happens to be encouraging someones post makes it seem like you are a copy.
Credits:
Iriel for looking in the code.
umm...
Rollback Post to RevisionRollBack
Quote from ms_fish »
At first i was scared of the endermen, then i saw your name was toilet.
I never have used the nether before since I mainly play in SMP. I was planning on making a nether travel system, but probably would have went about it the wrong way without reading this. I always assumed they were one-to-one. Nice, informative article.
...now I really-really want to make a 2-in-1 on purpose. I could use a perpendicular door to effectively "split" the entrance, to make it easier to discern which way I am going...
[*]Nether World is related to the Normal World in the 1:8 ratio in terms of distances. When you move 1 block in the Nether, it corresponds to 8 blocks in the Normal World.
Yes, but as you say, the co-ordinates do have to be very precise.
[*]This does not apply on the Y-Axis, the Nether Realm has the full 128 layers and is 1:1.
Again, true; but I don't agree that the Y axis is ignored entirely. It will be if you're careful about where you put your portals, but not if you aren't.
[*]A Portal Block is the purple shiny non-solid block, and always exists in a 2(wide)x1(long)x3(tall) formation within an Obsidian frame (minimum 10 obsidian blocks).
While you are correct that the minimum is 10 blocks for an initial portal, it is actually possible to construct a second, independent portal, using one of the same 3 block side walls as the first. This reduces the practical obsidian cost of the second portal to 7 additional blocks.
[*]Nether Portals do not remember what portal they are linked to in the other world, they perform the following whenever a portal is used by a player:
[/list]
This is good to know, and actually explains some of the random behaviour I've seen. I wonder if Notch initially experimented with hard linking?
[*]Calculate the destination coordinate, based on the entry portal's position. X and Z coordinates are divided by 8 rounded down when entering the Nether. Conversely, X and Z coordinates are multiplied by 8 when entering the Normal World. The Y coordinate is not modified. Note that every portal has 2 possible entry coordinates as it is 2-wide.
This would explain the behaviour observed, when standing on one side of a portal goes to one gate, and standing on the other goes to the other. The implications of this are very exciting. It may be possible to have as many as a single reliable portal every 8 overworld blocks.
[*]The game picks the closest Portal Block to teleport the player to. If 2 Portal Blocks are equidistant, the first found is picked.
My experience suggests that while X and Z take higher priority, if portals are the same distance apart on those axes, the Y is then checked, and if Y is closer, it is chosen.
[*]If neither search yields a clear site then the destination location and the preferred direction is used, the Y coordinate will be clamped such that it is between 70 and 118, and a small 3x2x3 volume will be constructed out of obsidian and air, such that the active area of the portal has an obsidian floor to step out on each side, and air to step out into. This replaces the original blocks in the original 3x2x3 volume.
[*]Finally, a portal is built at the site, and then the "find nearest portal" code re-executes (and will find the new portal).
Although it obviously isn't as ideal as building them yourself, it may be possible to exploit this system (at least to a degree) for automatic creation of portals in desired locations.
To setup pairs of portals properly so that they reliably travel to each other, it is best to build both portals manually.
This is consistent with my own experience, yes.
The portal spawning algorithm can only spawn portals that is within a 33x33 block column centered on the destination.
This was the missing piece of the puzzle. I had assumed that the system was chunk based; but that theory still could not account for some of the behaviour that I and other people had witnessed. It also explains, however, why the chunk-based seemed reliable; because 33x33 blocks is roughly two chunks.
[b][Manually pair portals as close as you can in all 3 coordinate axes. It doesn't have to be exact, or even all that close, as long as you know/ensure that no other portals will be constructed in the exclusion zone created by the difference.][/b]
It is possible to disregard the Y axis, if the portals are spaced sufficiently far apart in the normal world.
[b][Fast travel by Portal is One-Way, and usually used to go from bedrock to surface in Normal World, by constructing a pair of near-perfect surface portals, then making sure the bedrock portal in the mines selects the nether portal of the surface pair as its closest.][/b]
[media][/media]
Two way travel from sealevel to bedrock is entirely possible, with both portals at the same Y axis in the Nether. The overworld portals need to be spaced out appropriately, to prevent reliance on the Y axis. I haven't tested this with ranges of less than 40 overworld blocks apart, mind you, and your mention of the 33x33 number here tells me that that was with good reason.
For the 2-in-1 Nether portal to occur, the distance of one surface portal cannot be more than 8 blocks further than the other surface portal. [b][Having 2 Nether Portals side by side might be better for destination clarity, rather than a 2-in-1 portal. (I tested the 2-in-1 portal myself - it works!)][/b]
I've observed this effect myself, but I didn't obtain it deliberately. I would like to see if I can obtain it deliberately, and put it to use.
List tags are malformed.
That was the biggest headache I have ever gotten. Could you please put up a more simplified version or add some pictures to break the wall of text. I appreciate your commitment to finding out this science but it won't do much good unless it can be translated into simple talk.
The TL;DR version.
a} Drop a single obsidian block on the ground. (As one of the "floor" blocks of the portal)
b} Hit F3 while standing on said block. Notice the co-ordinates, and write them down in Notepad, with "overworld," next to them. So your first portal's co-ordinates might look like "overworld: 1x,64y,1z" in Notepad.
c} Use Google to multiply the first and third (x and z) numbers by 8. That will give you the co-ords you need to manually build the partner portal at, in the Nether. Write those down in Notepad, as "Nether: 8x,64y,8z."
d} Finish building that portal as normal.
e} Make sure you're carrying a diamond pickaxe, torches, a bucket, and probably around three stacks of cobblestone, and go into the Nether. Peaceful mode and a mod which allows flying will also likely be very useful for the next step.
f} When you arrive, stay standing inside the portal frame, and hit F3. If the co-ordinates are different to what you used Google to figure out, (and they most likely will be) use your diamond pickaxe to chop up that portal, but keep the obsidian blocks to use them for making a new one.
g} Walk to the co-ordinates you recorded in Notepad, as being the right ones for the Nether portal. Place your first obsidian block at those exact co-ordinates. Then build the rest of the portal, light it up, and walk through.
My experience suggests that while X and Z take higher priority, if portals are the same distance apart on those axes, the Y is then checked, and if Y is closer, it is chosen.
...
...
Two way travel from sealevel to bedrock is entirely possible, with both portals at the same Y axis in the Nether. The overworld portals need to be spaced out appropriately, to prevent reliance on the Y axis. I haven't tested this with ranges of less than 40 overworld blocks apart, mind you, and your mention of the 33x33 number here tells me that that was with good reason.
I've observed this effect myself, but I didn't obtain it deliberately. I would like to see if I can obtain it deliberately, and put it to use.
All the data I posted in the original post for Nether Portal linking and creation are based directly on reading the Minecraft code. They are then verified by actually constructing portals and watching where the destinations are and how they link. The 33x33 number is simply because the code says "for X-16 to X+16, for Z-16 to Z+16, for Y=0 to Y=127" to go through all the blocks. There is no chunk based system used. I don't know why the 16 radius was chosen, maybe Notch just felt its a nice number.
Similarly, this is the same for the portal search: "for X-128 to X+128, for Z-128 to Z+128, for Y=0 to Y=127". The 128 radius is probably chosen so that this resulting 257x257 region centered on the player always lies completely within the loaded 8 chunks radius of 272x272 centered on the chunk the player is in, even at the corners of the chunk.
There is no code that places X and Z on higher priority as you suggested, the 3D Euclidean distance is always used, and all 3 coordinates are important. But as you also said, the Y-coordinate can be ignored if the overworld portals are spaced out far enough apart so that it doesn't matter.
Basic Knowledge:
The following always happens when you enter a portal:
Summary version
If this is too confusing for you, erich666 has created a Powerpoint slideshow presentation with diagrams and pictures: http://www.slideshare.net/erich666/how-portals-work-in-minecraft
Long detailed version
Example with math
Suppose you press F3 and see that you are at (10.2, 61.6, 20.7) just before you are about to zone from the overworld into the nether. Your feet is basically at (10.2, 60, 20.7). After dividing by 8, you reach (1.275, 60, 2.5875), and the game uses this coordinate as it is as a double without rounding down to integers.
Lets say (-2, 64, 2) is a nearby active portal block, the game would then calculate the squared distance between (1.275, 60, 2.5875) and (-1.5, 64.5, 2.5) in real numbers as a double (it doesn't bother with the squareroot). That is, it uses your expected exact coordinate and the exact center of blocks (which is the block's integer coordinate +0.5D):
(1.275--1.5)^2 + (60-64.5)^2 + (2.5875-2.5)^2 = 27.985828
The actual distance is 5.287559 after taking square root, but its not necessary to do that since the smallest distance is still the smallest regardless of whether you square root it or not.
Implications
Portal travel is coordinate dependent. That is (x,y,z) <---> (x*8, y, z*8) and every time you enter a portal. It is at the destination where the game then calculates where to actually put you. If there is a nearby portal within 257x257x128, it places you at the closest one, distance is calculated by real 3-dimensional distance. This can cause 2 portals in the Normal World to both link to the same Nether one. [Portals don't remember who they are linked to, it is calculated fresh on each use.]
In fact, 2 Normal World portals that are within 1024 distance of each other on either X or Z axis are almost always going to link to the same Nether realm portal on initial construction because 1024 translates to a distance of 128 in the Nether Realm, and the game checks for existing Portals within 128 radius around the destination (the 257x257x128 box).
To setup pairs of portals properly so that they reliably travel to each other, it is best to build both portals manually. Build at desired location X,Y,Z in the Normal World. Then travel to the Nether World. And then dig your way to X/8, Y, Z/8, and build a portal there. You can then destroy the initial auto-generated portal which is probably offset from the real intended destination portal location by a significant distance. [You should destroy the auto-generated portal because it creates a zone of exclusion for new portal pairs, see next paragraph.]
The portal spawning algorithm can only spawn portals that is within a 33x33 block column centered on the destination. This will often cause it to spawn a portal at a Y-level that is far higher or far lower than the "exact matching" level. Lets say this height difference is 60 distance difference. In order to maintain this pair of portals to link to each other reliably, no other portal must be constructed within a 60 distance radius of both portals in both worlds, otherwise they would be considered "nearer" and link to them instead. This in effect creates a 480 block exclusion zone in the Normal World (centered on the Nether->Normal expected coordinate) whereby a new pair of portals cannot be made without causing REALLY WHACKY portal behavior (seen all the complaints on the forums?). [Manually pair portals as close as you can in all 3 coordinate axes. It doesn't have to be exact, or even all that close, as long as you know/ensure that no other portals will be constructed in the exclusion zone created by the difference.]
The portal choosing algorithm can be used for long distance travel by manual construction at carefully selected coordinates. Say you have a Portal in Normal world at (0,64,0) but make a Nether Portal at (127,64,0). And then you have another Portal in the Normal World at (1016, 64, 0). The last 2 of these will be a perfect pair. But the portal at (0,64,0) will go to the Nether Portal correctly (1-way trip). So in about 15 seconds, you can travel 1016 blocks. [Fast travel by Portal is One-Way, and usually used to go from bedrock to surface in Normal World, by constructing a pair of near-perfect surface portals, then making sure the bedrock portal in the mines selects the nether portal of the surface pair as its closest.]
It is possible to end up in a situation where a Nether Portal "randomly" places you in 1 of 2 possible Normal World destination portals. This is simply because the Nether Portal has two effective coordinates as it is 2 blocks wide, say (X, Y, Z) on the left, and (X+1, Y, Z) on the right. If you entered on the left side, (X, Y, Z) ----> (X*8, Y, Z*8) and picks a portal closest to that. If you entered on the right side, (X+1, Y, Z) ---> (X*8+8, Y, Z*8) and the game picks a portal closest to that. This situation occurs when the Nether Portal's location is roughly equidistant between the 2 Normal World portals. For the 2-in-1 Nether portal to occur, the distance of one surface portal cannot be more than 8 blocks further than the other surface portal. [Having 2 Nether Portals side by side might be better for destination clarity, rather than a 2-in-1 portal. (I tested the 2-in-1 portal myself - it works!)]
Take care in coordinate calculations. When you press F3 standing at a portal block and see (35.5, 93.63, -29.5), then the block you are actually standing on is (35.0, 92.0, -30.0).
X, 35.5 ---> 35.0 Because the decimal part is chopped off.
Y, 93.63 ---> 92.0 Because Steve is 1.63 meters tall.
Z, -29.5 ---> -30.0 Because even though the decimal part is chopped off, it chops off to the next lower integer. If it doesn't, then -0.5 and 0.5 would both go to 0 and that's wrong. In coding terms, math.floor(-29.49) gives the result -30. That is, rounding down is not the same as rounding towards 0.
The portal spawning algorithm, IN THEORY (I didn't try it), can be used to access the Void below. Make a portal at the lowest possible level of bedrock (layer 1) in World A. Clear out the bedrock as best as you can in World B in the corresponding expected position. Make sure there are no nether portals in World B within a 257x257x128 region around the expected position. Because the spawning algorithm looks for the closest possible spawn position to the expected location, it would be the location at layer 0 (which is solid and has an air block above it), and replace the 4 bedrock blocks with obsidian during the creation of the portal. [Will someone care to test this theory of accessing the Void?]
It is possible for a destination Nether portal to spawn floating in air above a lava lake. This can only occur if there is no possible spawn location in the entire 33x33x128 column of search region to find a suitable spot to place a fresh new portal AND there are no existing portals within the 128 block radius to link to. [See Portal Spawning Algorithm at top of post.].
Credits:
Iriel for looking in the code.
erich666 for the powerpoint slideshow.
Edits:
Correct some spelling, etc
Add Credits
Add Summary Version
Add Slideshow by erich666
Read the post slowly then. It's a "Science" thread, meaning its explained in high detail, and not simplified. If you want to link and pair portals properly, you need to understand how it works.
You simply have to build each pair of portals manually. Each portal selects the closest one in the other realm. So to unlink the 2 portals topside within 1024 blocks from each other, they need to each have a corresponding nether portal as close as possible in their "expected coordinate position" in the nether.
As for lighting a portal within another when they cross, nothing happens when you try to light the second. The fire just burns and dies after a while.
Where did you get the fact that Iriel wrote that? It's nowhere in the post. And the fact that you have 1 post and it just happens to be encouraging someones post makes it seem like you are a copy.
He plays on my multiplayer server.
The description is lengthy yet very much appreciated. I'm not sure how pictures (other than perhaps examples using plain grids) would help this description.
or a quarter... or maybe less.....
but i can see you put a lot of work into this.
never really understood portals/redstone/ores/minecraft/life
http://worldslongestwebsite.com/
Awesome ideas (not mine):
The Aether
Oceancraft
Geocraft
Farmcraft
Google these to find out what they are!
umm...
...now I really-really want to make a 2-in-1 on purpose. I could use a perpendicular door to effectively "split" the entrance, to make it easier to discern which way I am going...
I'm making a note here Huge Success
It's hard to overstate my satisfaction ...
wait.
Wrong portal :\
Yes, but as you say, the co-ordinates do have to be very precise.
Again, true; but I don't agree that the Y axis is ignored entirely. It will be if you're careful about where you put your portals, but not if you aren't.
While you are correct that the minimum is 10 blocks for an initial portal, it is actually possible to construct a second, independent portal, using one of the same 3 block side walls as the first. This reduces the practical obsidian cost of the second portal to 7 additional blocks.
This is good to know, and actually explains some of the random behaviour I've seen. I wonder if Notch initially experimented with hard linking?
This would explain the behaviour observed, when standing on one side of a portal goes to one gate, and standing on the other goes to the other. The implications of this are very exciting. It may be possible to have as many as a single reliable portal every 8 overworld blocks.
My experience suggests that while X and Z take higher priority, if portals are the same distance apart on those axes, the Y is then checked, and if Y is closer, it is chosen.
Although it obviously isn't as ideal as building them yourself, it may be possible to exploit this system (at least to a degree) for automatic creation of portals in desired locations.
This is consistent with my own experience, yes.
This was the missing piece of the puzzle. I had assumed that the system was chunk based; but that theory still could not account for some of the behaviour that I and other people had witnessed. It also explains, however, why the chunk-based seemed reliable; because 33x33 blocks is roughly two chunks.
It is possible to disregard the Y axis, if the portals are spaced sufficiently far apart in the normal world.
[media][/media]
Two way travel from sealevel to bedrock is entirely possible, with both portals at the same Y axis in the Nether. The overworld portals need to be spaced out appropriately, to prevent reliance on the Y axis. I haven't tested this with ranges of less than 40 overworld blocks apart, mind you, and your mention of the 33x33 number here tells me that that was with good reason.
I've observed this effect myself, but I didn't obtain it deliberately. I would like to see if I can obtain it deliberately, and put it to use.
List tags are malformed.
I think we can say that Xinhuan *does* deserve cake for this thread, though. :wink.gif:
The TL;DR version.
a} Drop a single obsidian block on the ground. (As one of the "floor" blocks of the portal)
b} Hit F3 while standing on said block. Notice the co-ordinates, and write them down in Notepad, with "overworld," next to them. So your first portal's co-ordinates might look like "overworld: 1x,64y,1z" in Notepad.
c} Use Google to multiply the first and third (x and z) numbers by 8. That will give you the co-ords you need to manually build the partner portal at, in the Nether. Write those down in Notepad, as "Nether: 8x,64y,8z."
d} Finish building that portal as normal.
e} Make sure you're carrying a diamond pickaxe, torches, a bucket, and probably around three stacks of cobblestone, and go into the Nether. Peaceful mode and a mod which allows flying will also likely be very useful for the next step.
f} When you arrive, stay standing inside the portal frame, and hit F3. If the co-ordinates are different to what you used Google to figure out, (and they most likely will be) use your diamond pickaxe to chop up that portal, but keep the obsidian blocks to use them for making a new one.
g} Walk to the co-ordinates you recorded in Notepad, as being the right ones for the Nether portal. Place your first obsidian block at those exact co-ordinates. Then build the rest of the portal, light it up, and walk through.
h} Eat cake, if you feel so inclined. :wink.gif:
All the data I posted in the original post for Nether Portal linking and creation are based directly on reading the Minecraft code. They are then verified by actually constructing portals and watching where the destinations are and how they link. The 33x33 number is simply because the code says "for X-16 to X+16, for Z-16 to Z+16, for Y=0 to Y=127" to go through all the blocks. There is no chunk based system used. I don't know why the 16 radius was chosen, maybe Notch just felt its a nice number.
Similarly, this is the same for the portal search: "for X-128 to X+128, for Z-128 to Z+128, for Y=0 to Y=127". The 128 radius is probably chosen so that this resulting 257x257 region centered on the player always lies completely within the loaded 8 chunks radius of 272x272 centered on the chunk the player is in, even at the corners of the chunk.
There is no code that places X and Z on higher priority as you suggested, the 3D Euclidean distance is always used, and all 3 coordinates are important. But as you also said, the Y-coordinate can be ignored if the overworld portals are spaced out far enough apart so that it doesn't matter.
Edit: Re-read and updated my reply :tongue.gif: