I hope notch can find SOME way to expand the ceilings easily...
Thats the whole idea behind this
That and I love the idea of deep sea evaporation and building
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
I'm by no means a competent programmer, but I understand enough to know why this thread's suggestion is not very helpful:
The problem of how to encode the data of a raised height limit is almost trivial compared to the necessary engine rewrite to operate with a raised the height limit. The existing logic will have been written using assumptions about the data set it will be operating on, so changing the structure of the data set means finding and changing the logic everywhere that that hidden assumptions within it are now changed.
This is the actual problem. It is not at all trivial.
I deeply hope that we will eventually be able to build truly massive structures in Minecraft, but understand that what we want probably involves rewriting the game from scratch.
Well the sugestion of cubic blocks is my best hope to reduce the amount of reprograming needed too aswell.
But then again i'm no programer ether so *shrugs*
The game needs reprogramed anyway in something other than java x.x
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
I don't know if this is still of any reliance but I am wondering what work has been done into espanding height.... or block count?
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
all that would need to be done is the chunks save lighting data from the bottom layer and then send it down to the chunk bellow so the chunk don't have to load to know the light
same with sending the open space for falling blocks up.....
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
all that would need to be done is the chunks save lighting data from the bottom layer and then send it down to the chunk bellow so the chunk don't have to load to know the light
same with sending the open space for falling blocks up.....
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
I support this idea. It would take some serious rewriting in the code, but I believe it would be worth it. As computers get faster and minecraft hopefully one day becomes multi-treaded, players will expect to be able to build taller and taller structures.
I hope I have some of this information right, or my post is going to become very irrelevant, very fast...
I like the idea that the world height will be expanded, but I don't know how much work it would take to do this. Even with this theory, it would be difficult to write the code without causing lag. Think about it, in order to take information from the bottom layer of a cubic chunk so the game can check and save the lighting details, it would first have to load the entire chunk unless the entire system is rewritten, then unload the chunk. This could cause severe lag if it's doing this multiple times (for instance, while sprinting or sprint-flying in Creative). Not to mention, like it's been pointed out before, this would require a massive overhaul, and the game would have to be rewritten from the ground up. Doubt it'll happen.
And what happens if the world height is increased and, somehow, a cave spawns that's even taller than anything ever thought possible. If the game checks the bottom layer of a chunk and reports it as empty air, it'll light up the cave as if it's not a cave. But, what happens when you eventually reach the bottom of the chunk that reports that there is a roof to the cave. Then, boom, the entire visible area is suddenly pitch black, and you're surrounded by fifty Creepers (exageration, I know). I know this has been pointed out before, but your suggestion to solve the previous idea doesn't take into account extreme cases.
I like the idea, it's just going to be way too difficult to write the code to encorporate cubic chunks.
^ Actually, its been pointed out that the current map would only be 8 chunks high. We could load all of those (or most, maybe rounding corners on the cube that surrounds the player). So why do it if it doesn't save time? Because then it would be really really easy to add more chunks if the player chose to build a tall tower. So most of the map would load in the same time it does now, but a few places would load a few extra chunks as needed. Servers could set a max height to combat lag and single players can build as high as their processors allow.
Rewriting the chuck code would also be a great time to optimize the code. *cough* multi-thread *cough*
well there would be a limit to how high mountains get.... and yess it would take a big overhull
the idea though would be that chunks would have that data saved so it could load the lighting/fall data with out loading the whole chunk
when generating new ground... it would load everything above you up to open sky and maybe one chunk bellow and such.... but once the chunks are created it wouldn't have to load all of them ..... creating new area's will allways be lagggy,,,, but this can cut down on lag of going places you have already been big time...
and yes.... the code needs a lot of work..... and if you could work something like this in and fix all the problems in the code at the same time.... a full re-rite would be worth it if you ask me
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
What about having the normal chunks stay as they are, and then just adding 16^3 chunks above y256? The game starts adding new "sky" chunks within say 32m of the player, if a chunk is empty when the player leaves, and has only empty chunks above it, it's deleted outright, and all chunks from the current chunk down stay rendered to "soft-cap" the world with lag if you go too high. Approaching a ground-level chunk automatically checks for chunks above.
no it's not.... thats about taller chucnks or something this is about cubed ones, and it's two years older than that thread lol
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
I like the idea. The game could get around the problem of having to generate the chunks "above" in order to determine daylight by generating all of the chunks above until it finds daylight, then saving the "daylight can/cannot reach here" flag as part of each lower chunk before saving and unloading the unneeded chunks.
There would be a moment of lag as the new chunks are generated, but then there would be no more lag until a recalculation might be needed due to blocks above being destroyed or placed. In any case, the lag would probably be minimal since the recalculation could wait until the player gets close enough to see the difference.
I like the idea. The game could get around the problem of having to generate the chunks "above" in order to determine daylight by generating all of the chunks above until it finds daylight, then saving the "daylight can/cannot reach here" flag as part of each lower chunk before saving and unloading the unneeded chunks.
There would be a moment of lag as the new chunks are generated, but then there would be no more lag until a recalculation might be needed due to blocks above being destroyed or placed. In any case, the lag would probably be minimal since the recalculation could wait until the player gets close enough to see the difference.
A simpler solution would be to keep a heightmap of the 15 highest non-air blocks at any given XY coordinate. Checking their Y height alongside their block type properties allows for sunlight calculation at any level. The number of blocks must be 15, because no matter the block type, the light level will always be 0 after 15 blocks, even if they're glass blocks.
With this heightmap of blocks and their associated data, the Y coordinate of rendered blocks can be used to determine which of the 15 highest blocks are above it, and then those blocks are used for light calculation of that block.
I hope notch can find SOME way to expand the ceilings easily...
Thats the whole idea behind this
That and I love the idea of deep sea evaporation and building
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
The problem of how to encode the data of a raised height limit is almost trivial compared to the necessary engine rewrite to operate with a raised the height limit. The existing logic will have been written using assumptions about the data set it will be operating on, so changing the structure of the data set means finding and changing the logic everywhere that that hidden assumptions within it are now changed.
This is the actual problem. It is not at all trivial.
I deeply hope that we will eventually be able to build truly massive structures in Minecraft, but understand that what we want probably involves rewriting the game from scratch.
But then again i'm no programer ether so *shrugs*
The game needs reprogramed anyway in something other than java x.x
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
I still love this idea.....
all that would need to be done is the chunks save lighting data from the bottom layer and then send it down to the chunk bellow so the chunk don't have to load to know the light
same with sending the open space for falling blocks up.....
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
Minecraft Haters.
This sounds good.
I like the idea that the world height will be expanded, but I don't know how much work it would take to do this. Even with this theory, it would be difficult to write the code without causing lag. Think about it, in order to take information from the bottom layer of a cubic chunk so the game can check and save the lighting details, it would first have to load the entire chunk unless the entire system is rewritten, then unload the chunk. This could cause severe lag if it's doing this multiple times (for instance, while sprinting or sprint-flying in Creative). Not to mention, like it's been pointed out before, this would require a massive overhaul, and the game would have to be rewritten from the ground up. Doubt it'll happen.
And what happens if the world height is increased and, somehow, a cave spawns that's even taller than anything ever thought possible. If the game checks the bottom layer of a chunk and reports it as empty air, it'll light up the cave as if it's not a cave. But, what happens when you eventually reach the bottom of the chunk that reports that there is a roof to the cave. Then, boom, the entire visible area is suddenly pitch black, and you're surrounded by fifty Creepers (exageration, I know). I know this has been pointed out before, but your suggestion to solve the previous idea doesn't take into account extreme cases.
I like the idea, it's just going to be way too difficult to write the code to encorporate cubic chunks.
Rewriting the chuck code would also be a great time to optimize the code. *cough* multi-thread *cough*
the idea though would be that chunks would have that data saved so it could load the lighting/fall data with out loading the whole chunk
when generating new ground... it would load everything above you up to open sky and maybe one chunk bellow and such.... but once the chunks are created it wouldn't have to load all of them ..... creating new area's will allways be lagggy,,,, but this can cut down on lag of going places you have already been big time...
and yes.... the code needs a lot of work..... and if you could work something like this in and fix all the problems in the code at the same time.... a full re-rite would be worth it if you ask me
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
http://www.minecraftforum.net/topic/1536395-infinite-world-height-vertical-chunks/
no it's not.... thats about taller chucnks or something this is about cubed ones, and it's two years older than that thread lol
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
There would be a moment of lag as the new chunks are generated, but then there would be no more lag until a recalculation might be needed due to blocks above being destroyed or placed. In any case, the lag would probably be minimal since the recalculation could wait until the player gets close enough to see the difference.
A simpler solution would be to keep a heightmap of the 15 highest non-air blocks at any given XY coordinate. Checking their Y height alongside their block type properties allows for sunlight calculation at any level. The number of blocks must be 15, because no matter the block type, the light level will always be 0 after 15 blocks, even if they're glass blocks.
With this heightmap of blocks and their associated data, the Y coordinate of rendered blocks can be used to determine which of the 15 highest blocks are above it, and then those blocks are used for light calculation of that block.
I assume I'd be yelled at though.