1 - 20 of 45
jseyfert3
Insane amount of blocks indeed, because you didn't realize you typed that into your calculator wrong. If you go from a chunk height of 256 to 512 with the same base area (16x16), then you have twice the number of blocks, just like when you go from a height of 128 to 256. A chunk with a 16 x 16 base and 512 blocks high would be 131,072 blocks, not 67,108,864!
P.S. The main reason I want higher heights would be an epic automatically generated mountain terrain.
P.P.S. 512 x 512 x 16 x 16 = 67,108,864. And since 512 x 512 is a 262,144 blocks, you just gave the number of blocks in a 262,144 x 16 x 16 chunk by accident. That's one tall chunk!
EliteTNTGamingYou could dig down to get a larger space...
ParilI don't think you understand my remark exactly.
Block data sent to clients, for instance, is encoded in a special way so that it can send small amounts of data. Keep in mind that engines try to use shortcuts by cutting down data or encoding it in special ways (for instance, any chunk is 16x16x256 - you can encode this perfectly into an unsigned short, a 16 bit integer, by using the first byte for x z, and second byte for y). Allowing Y to be limitless pretty much wouldn't allow this optimization to take place.
Since MCEdit is a third party program it shouldn't be taken into account here. It's up to the maintainer of that program to keep up to date (if this was ever to happen) - it wouldn't affect the implementation of this sort of feature.
Size constraints can easily be overcome by just getting a bigger hard drive or whatever, but it will still drastically affect the size of existing worlds. As I said, it could easily quadruple the size just because chunks would now have to be sliced on the Y plane and can no longer easily slip into a byte (hence the "magic" 256 number - it's the upper limit of an unsigned byte). You could do optimizations to surpass this and make it bearable, but it would likely be at the expense of speed.
http://www.wiki.vg/Protocol#0x38 looking at some of these packets might reveal a bit more information about why/how this is done. There's a very specific reason why the number 256 (or 128 for the older map version) was chosen and why it can't be increased in vanilla gameplay, only decreased.
-P
+Sheena+No.
Whoever01No, 256 is a great build height. You will never need to go any higher. Anyway, any higher and the game will lag like hell no matter what the chink generation is. At least there could be more generated structures in the air. And by the way, you can build on 257 with water and lava.
-Who
minerat27you could go infinitely horizontally as well as vertically
shoundn't this be vertically as well as horizontally?
(this is 4th para 2nd to last line)
ParilMaps would be too big to be maintain. Chunks are written in a way so that the positional data can be pushed into an unsigned short; you'd essentially be quadrupling, if not more, the size of region files if it also had to account for a "limitless y".
It's certainly not impossible, just not exactly good for space.
-P
ColdTuberGaming
snip
No i make you other avatar but give me theme with that pic you give me i cant make you.Or give me render and make again but with that pic i cant
1 - 20 of 45
