Yeah. Now when I try to use the new enchanting table, I can't get more than one enchantment. (And in my world, Lapis is pretty much extinct.)
Um... you can get more than 1 enchantment. The enchantment table only shows the 1 guaranteed enchantment. You still have a chance to get more enchantments in addition (you just won't know what, if any).
Enchant a few more times and you'll see.
Lapis can be obtained from trading with villagers.
Cubic chunks would have to implemented, but then the world height would be infinite.
And you just made the height-map data set problem even worse.
Using just 1 byte (256 possible value) per every 1 sq meter area on Earth would already require 500 TB of raw data.
The real-life earth has a natural elevation range from about 12 km (12000 meter) underwater (Mariana trench) to about 9 km above sea level (Mount Everest). With a total of 21 km, or 21,000 m, or variation, you need 2 bytes, or 1 Exabyte worth of heightmap data.
Note that he stated its a 1-to-1500 scale, not 1-to-1. 1-to-1000+ is feasible (in terms of storage requirement). 1-to-1 would not be practical for most machines.
61,721,384,400,000. That is the surface area of the an average Minecraft world. 2,212,236 is the calculated surface area in kilometers for an Earthgen world. 1,000 meters in a kilometer. So 2,212,236,000 is the surface area (in blocks) of an Earthgen 1:1 world. Remember, simple math is your friend.
Unless my math is wrong, which it probably is, I shouldnt be to far off. So generation isn't a problem. I guess I wouldn't mind a weird new generation.
The problem isn't that Minecraft can't support a 1-to-1 earth sized map (it can). The problem is the amount of raw data (height-map) alone needed to generate a 1-to-1 representation.
First of all,l your math is wrong by a factor of a thousand. There's 1000 meters in a kilometer, but there is 1,000,000 sq meters in a sq kilometer (note the sq, the ration is squared). Also I'm not sure where you get 2 million sq kilometers from, but the surface area of earth is about 500 million sq km, which is 500 trillion sq meters (500,000,000,000,000 sq meters). Assuming each 1x1 sq meter uses a single byte to store its height (256, the vertical limit of minecraft world in blocks), this would mean that JUST the height data alone will need 500 TB worth of data. Even with the most optimistic of compression ratio (90% compression), you still get something like 50 TB worth of data of JUST height map (no underground features, no non-sea-level lake/river, no buildings, ore, trees, biomes, etc). Consumer hard-drive only got to 10 TB just two month ago.
You have a valid point, mojangcrosoft (still not sure what to call it) would have the heightmap and either A: generate an algorithm (I think, I'm a coding noob) that tells the chunks what to generate, or B, have the worldgen just be fixed off of the hieghtmap that is stored in their computers, all we have is the algorithm/predefined chunk generation on our computers. And for the height? Cubic chunks would make the map height infinite. (Or so I've been told)
The problem is that the heightmap information alone, with a 1 meter horizontal resolution and a limit of 256 distinct height values, would require 500 TB (possibly 50 TB with some lossy compression). This exclude stuff like whether there's water, what biome is there, and the composition of the terrain (dirt, sand, stone, etc). If you want a 1-to-1 representation of earth (impossible, btw, due to height limit), you cannot avoid having at least 500 TB of raw height data.
Granted, all is not "lost" per say. Since minecraft vertical resolution is pretty much not enough to represent any earth mountain and ocean and will therefore not be 1-to-1, it would be reason to reduce the lateral resolution by a lot to cut down that size. Reducing the resolution to something like 1 square kilometer (storing height only on a square kilometer scale, or 1 km x 1 km) would cut that down to something like 500 mega-byte. Further more, since most mountain have a base area on the range of 100+ sq km, we can cut that size down even further by using even coarser resolution, something like 25 sq km (5 km x 5 km chunks), this would cut the final height-map size down to 4 mega-byte. Of course, at this point it would be a bit pointless to have for most player, considering that for 2500 blocks in all direction from the player, the terrain is essentially generated purely by minecraft (the heightmap only tells it how much to offset the entire 5000x5000 block region by).
For one, Minecraft height limit of 256 is insufficient to accommodate the vast height variations in the world. The average ocean depth is around 3.5 km, or 3500 meters (aka 3500 blocks deep). Hundreds of mountain rises above 1000 feet.
Even assuming that we scale the vertical height down, the height map would still take up an enormous amount of space. Assuming a simple height (not accounting real-life caves and overhangs), Earth covers 510,000,000 square kilometers, or 510,000,000,000,000 square meters, or 510 trillion square meters. Assuming we just store the height itself (256 possible values, or 1 byte), a complete heightmap of the world, uncompressed, would take about 510 TB. The best compression typically can only compress down to 10% of the original data, or 51 TB.
Typical modern harddrive range from 1 TB to 4 TB. You're going to need a couple computer holding nothing but harddrives just to store that heightmap.
I agree with Badprenup.
But there is one twent tiny problem. Actually, the majorest major problem.
...
Endstone is finite. D:
True, but with 3 endstone per portal frame, and 12 portal frame in total, one portal just need 36 endstones. The amount of Endstone in the End appears more than enough.
With uphill, a low signal strength would still accelerate you instead of having you go backwards, right?
Anyway, Support!
Yes. The logic for this rail is quite simple. If the minecart is below the target speed of the powered rail, it will try to acccelerate it up to the target speed. Conversely, if the target speed is too high, it will slow it down (but no reverse it).
Um, if my memory serves, wood block are placed with the non-bark side facing toward you and not based on which block it was placed on. So to keep log placed upright would be as simple as standing either below or above while placing it.
Currently powered rail behavior is binary. Fully powered accelerate minecart up to 8 blocks/second. Unpowered stop minecart (decelerate to 0).
The idea is quite simple, have powered rail tries to accelerate/decelerate minecart to a target speed based on its power level.
Redstone Signal = Target Speed (in m/s, assuming 1 block = 1 meter)
0 = Full Stop
1 = 1 m/s
2 = 1.5 m/s
3 = 2 m/s
4 = 2.5 m/s
5 = 3 m/s
6 = 3.5 m/s
7 = 4 m/s
8 = 4.5 m/s
...
15 = 8 m/s
In short, the general rule is Speed = (Signal - 1) * 0.5 + 1.
If a minecart is above the target speed while over the rail, the powered rail will try to decelerate down to the target speed. Conversely, if a minecart is below the target speed, the powered rail will try to accelerate it up to that speed.
A powered rail will power up to 8 connected power rail to the same level as itself (a powered rail with signal strength of 4 will power up to 8 connected rails to signal strength of 4).
If a powered rail can be powered by multiple signals, the stronger signal takes precedence. For example, if a power rail is connected (within 8 blocks) to a power rail at signal level 4 and another at signal level 8, the power rail in question will be powered to signal level 8.
The danger I see is with performance. Splitting out ores as meta data means that the rendering engine needs to perform two queries on an ore bearing stone to figure out what to display.
Instead of separate meta data and "ores in every block", I would suggestion the following.
Given that ALL ore block current have no Data Value (a 4-bits additional value that can be queried by Minecraft rendering engine at the same time as the block itself with little additional overhead) associated with them, instead of separating out ores as meta-data, allow each ore block to have a data value that changes their base texture. This has the restriction that each ore can only have up to 16 "base" blocks (in short, limits ores to appear in only 16 distinct type of blocks). However, this should be more than sufficient since there are few naturally spawned block that would have ores in them (dirt, stone, andesite, diorite, granite, sand, gravel, etc),
I would support this as a form of a preset option in the "Customized World" option.
Actually, it would be nice to include a way to share customization option. Encode the various settings in one string. Player who wants a similar type of world just copy that string into their game.
0
Um... you can get more than 1 enchantment. The enchantment table only shows the 1 guaranteed enchantment. You still have a chance to get more enchantments in addition (you just won't know what, if any).
Enchant a few more times and you'll see.
Lapis can be obtained from trading with villagers.
0
And you just made the height-map data set problem even worse.
Using just 1 byte (256 possible value) per every 1 sq meter area on Earth would already require 500 TB of raw data.
The real-life earth has a natural elevation range from about 12 km (12000 meter) underwater (Mariana trench) to about 9 km above sea level (Mount Everest). With a total of 21 km, or 21,000 m, or variation, you need 2 bytes, or 1 Exabyte worth of heightmap data.
0
Note that he stated its a 1-to-1500 scale, not 1-to-1. 1-to-1000+ is feasible (in terms of storage requirement). 1-to-1 would not be practical for most machines.
The problem isn't that Minecraft can't support a 1-to-1 earth sized map (it can). The problem is the amount of raw data (height-map) alone needed to generate a 1-to-1 representation.
First of all,l your math is wrong by a factor of a thousand. There's 1000 meters in a kilometer, but there is 1,000,000 sq meters in a sq kilometer (note the sq, the ration is squared). Also I'm not sure where you get 2 million sq kilometers from, but the surface area of earth is about 500 million sq km, which is 500 trillion sq meters (500,000,000,000,000 sq meters). Assuming each 1x1 sq meter uses a single byte to store its height (256, the vertical limit of minecraft world in blocks), this would mean that JUST the height data alone will need 500 TB worth of data. Even with the most optimistic of compression ratio (90% compression), you still get something like 50 TB worth of data of JUST height map (no underground features, no non-sea-level lake/river, no buildings, ore, trees, biomes, etc). Consumer hard-drive only got to 10 TB just two month ago.
1
That's... potentially worse. Adding back in gameplay element that was removed for balance reason is not a good idea.
0
The problem is that the heightmap information alone, with a 1 meter horizontal resolution and a limit of 256 distinct height values, would require 500 TB (possibly 50 TB with some lossy compression). This exclude stuff like whether there's water, what biome is there, and the composition of the terrain (dirt, sand, stone, etc). If you want a 1-to-1 representation of earth (impossible, btw, due to height limit), you cannot avoid having at least 500 TB of raw height data.
Granted, all is not "lost" per say. Since minecraft vertical resolution is pretty much not enough to represent any earth mountain and ocean and will therefore not be 1-to-1, it would be reason to reduce the lateral resolution by a lot to cut down that size. Reducing the resolution to something like 1 square kilometer (storing height only on a square kilometer scale, or 1 km x 1 km) would cut that down to something like 500 mega-byte. Further more, since most mountain have a base area on the range of 100+ sq km, we can cut that size down even further by using even coarser resolution, something like 25 sq km (5 km x 5 km chunks), this would cut the final height-map size down to 4 mega-byte. Of course, at this point it would be a bit pointless to have for most player, considering that for 2500 blocks in all direction from the player, the terrain is essentially generated purely by minecraft (the heightmap only tells it how much to offset the entire 5000x5000 block region by).
0
Depending on implementation, not really. It could just be a different skybox texture.
0
For one, Minecraft height limit of 256 is insufficient to accommodate the vast height variations in the world. The average ocean depth is around 3.5 km, or 3500 meters (aka 3500 blocks deep). Hundreds of mountain rises above 1000 feet.
Even assuming that we scale the vertical height down, the height map would still take up an enormous amount of space. Assuming a simple height (not accounting real-life caves and overhangs), Earth covers 510,000,000 square kilometers, or 510,000,000,000,000 square meters, or 510 trillion square meters. Assuming we just store the height itself (256 possible values, or 1 byte), a complete heightmap of the world, uncompressed, would take about 510 TB. The best compression typically can only compress down to 10% of the original data, or 51 TB.
Typical modern harddrive range from 1 TB to 4 TB. You're going to need a couple computer holding nothing but harddrives just to store that heightmap.
1
True, but with 3 endstone per portal frame, and 12 portal frame in total, one portal just need 36 endstones. The amount of Endstone in the End appears more than enough.
0
Yes. The logic for this rail is quite simple. If the minecart is below the target speed of the powered rail, it will try to acccelerate it up to the target speed. Conversely, if the target speed is too high, it will slow it down (but no reverse it).
0
1
Currently powered rail behavior is binary. Fully powered accelerate minecart up to 8 blocks/second. Unpowered stop minecart (decelerate to 0).
The idea is quite simple, have powered rail tries to accelerate/decelerate minecart to a target speed based on its power level.
Redstone Signal = Target Speed (in m/s, assuming 1 block = 1 meter)
- 0 = Full Stop
- 1 = 1 m/s
- 2 = 1.5 m/s
- 3 = 2 m/s
- 4 = 2.5 m/s
- 5 = 3 m/s
- 6 = 3.5 m/s
- 7 = 4 m/s
- 8 = 4.5 m/s
- ...
- 15 = 8 m/s
In short, the general rule is Speed = (Signal - 1) * 0.5 + 1.If a minecart is above the target speed while over the rail, the powered rail will try to decelerate down to the target speed. Conversely, if a minecart is below the target speed, the powered rail will try to accelerate it up to that speed.
A powered rail will power up to 8 connected power rail to the same level as itself (a powered rail with signal strength of 4 will power up to 8 connected rails to signal strength of 4).
If a powered rail can be powered by multiple signals, the stronger signal takes precedence. For example, if a power rail is connected (within 8 blocks) to a power rail at signal level 4 and another at signal level 8, the power rail in question will be powered to signal level 8.
0
Support
0
The danger I see is with performance. Splitting out ores as meta data means that the rendering engine needs to perform two queries on an ore bearing stone to figure out what to display.
Instead of separate meta data and "ores in every block", I would suggestion the following.
Given that ALL ore block current have no Data Value (a 4-bits additional value that can be queried by Minecraft rendering engine at the same time as the block itself with little additional overhead) associated with them, instead of separating out ores as meta-data, allow each ore block to have a data value that changes their base texture. This has the restriction that each ore can only have up to 16 "base" blocks (in short, limits ores to appear in only 16 distinct type of blocks). However, this should be more than sufficient since there are few naturally spawned block that would have ores in them (dirt, stone, andesite, diorite, granite, sand, gravel, etc),
0
Netherbrick fence don't even look like they're made of brick, but some sort of really, really dark wood.
0
Actually, it would be nice to include a way to share customization option. Encode the various settings in one string. Player who wants a similar type of world just copy that string into their game.