Gameplay
Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
Poll: Which parts of this system do you like?
Ended May 15, 2014
Poll: Which parts of this system do you NOT like?
Ended May 15, 2014
Poll: Do you support this system's implementation overall? (If yes, if
Ended May 15, 2014
I don't think that flowing water needs to load up to the source block if the flowing water blocks already exist. If source blocks are unloaded then they won't be changing. But it does present a problem if there is a large cavern which is open to the ocean overhead but no ocean chunks are currently loaded. There would be water that would not fall until the player ascended nearer to the ocean.
It's quite similar to the sunlight issue actually.
I suppose if each flowing liquid block pointed to it's source then if the source block is removed or blocked then the halted flow can be simulated by a time delay appropriate with the block's distance (vertical and horizontal) from the source block. Then flowing water blocks can disappear in order regardless of whether or not the all the flowing water between them and the source are in loaded chunks or not. Nice.
However, it still doesn't solve the problem of water falling in the first place (particularly from unloaded source blocks), where flowing water would be replacing air blocks.
I think that following liquid blocks not falling until observed can be chalked up as quantum mechanics.
The falling fluids/entities already experience issues at the edge of loaded chunks on the horizontal axis. Considering no effort has been made to fix this on Mojang's part, these are chalked-up as a non-issue.
Pretty sure that was a joke
Still, even though there are a lot of disadvantages of the proposed system, I don't think they are anything more than small asides to a positive change.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
White coats to bind me, out of control
I live alone inside my mind
World of confusion, air filled with noise
Who says that my life's such a crime?
Trapped in this nightmare
I wish I'd wake
As my whole life begins to shake
four walls surround me
an empty gaze
I can't find my way out of this maze
'Cause I don't care
Fall in, fall out
Gone without a doubt, help me
I can't take the blame
They don't feel the shame
It's a madhouse
Or so they claim
It's a madhouse
Oh, am I insane?
My fears behind me, what can I do
My dreams haunt my sleep at night
Oh no, won't learn their lesson, white fills my eyes
And only then they see the light
-Joey Belladonna, Anthrax
I had the same basic idea to solve the light problem. I think it can be helped with additional meta-data about the biome (my idea currently assumes 2d biomes but could work with 3d). The additional information would be the max generation height and min generation height.
Unfortunately to fully fix the lighting this idea does require a new sun map to be generated. This would obviously inflate the world sizes but would totally fix the lighting. The idea of the sun map is to hold the light values for what the sun would produce at full day. The sun map would only exist initially for the the chunks between the min and max generations of the biomes, however as the player messes with the terrain (digs down or builds up) additional chunks would need it as well.
When entering a new area and when the loaded area of a player is above the min generation for the biome, generate the y column between the min and the max generation for the biome. From the generated chunks create the sun map for those (including anything the player maybe placing).
When entering a previously generated area the sun map is already created just refer to the map, adjust for the time of day, then add any local lighting.
The major issues that I see with this is one that the world size would grow due to the new sun shadow map, and two the higher you are the longer it would take to update the sun shadow map.
Ideally the updating of the sun map should be done in a separate thread (the game shouldn't wait for that to finish before completing) but I don't know how well that will work with the way minecraft is programmed. Having it in a separate thread would cause a bit of a delay at the ground before the shadow was seen, but I think a slight delay is OK, especially when the person on the ground cant see what is going on.
While I believe this would work, I don't know if this will be nearly as efficient than the current system when generating new terrain at the surface. Other than the efficiency in speed and space, if anyone can find a reason as to why this wouldn't work please let me know.
So theoretically, while infinite height is not practically feasible, the system could still be added to the game utilizing the current height limit or a variable limit option during world generation (Up to a certain point, say 1000, and you could choose this limit based on how fast your PC is) and still retain all the advantages of the new system. Sounds like a win-win to me.
Of course, in the future if lighting and other issues are successfully worked around, this limit could be increased easily with most of the system already in place.
I'm glad you could take the time to respond, we've been looking for an official-ish response for a while now.
The sunlight issue is fairly big, but we've been attempting to come up with a solution. We're hoping that when our example mod is updated, you guys can check it out and see how it works, and if it works in a way Mojang can use.
-
View User Profile
-
View Posts
-
Send Message
ModeratorWant some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Well, the current solution set in the OP, in the "Coping with Sunlight" section, uses a heightmap, but the end result is something where light values are calculated on the fly instead of stored, which offers a disadvantage in the form of requiring lighting calculations even without updates, but also has the benefit of being able to say "Calculations aren't needed in this chunk" and completely skipping calculations for that chunk.
The problem with the current sunlight illumination is that it comes from a technically infinitely high place: No matter how high you fly, sunlight still pours down from above you. A similar problem is that this light reaches infinitely downwards. These two infinite factors are what cause most of the sunlight issues. So why not create an ingame solution: Why not create barriers above and below the surface of the world? Above could be a point when the sun and the sunlight start to fade, gradually, until you are immersed in the deepest of nights, and below could be a fog, like the void fog, that either exists as a layer or is ubiquitous below a certain point, that also gradually blocks light. Above or below these points the only light that exists is from light giving blocks.
These barriers would be very high up and very low down, respectively, and could be moved like the void. As long as they were far enough to reach, they wouldn't hinder gameplay (such as stopping that mountain there from being lit at its peak; it would be much higher) and could even add some ambience. Besides, most miners do not expect light below a certain depth, and the darkness above could simply be that space a lot of people seem to want.
Those barriers already exist, just very far away.
From the wiki.
Following that, there would be a barrier at Y ±30,000,000 to keep the players from entering the Space and Core Far Lands
No, these would be barriers for the sunlight: The world could still generate and the player could still go there and place blocks. The idea was to restrict sunlight on the y-scale.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)