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
What I suggest is to have a new array that would correspond to the world by X and Z (you can have it in chunks too, and that's probably for the best). So values in that array (that I called height map) will be equal to the biggest Y of all known solid blocks that have the same X and Z as the value in the array. Every newly generated or updated block will be checked with that array comparing it's Y to the value from the array. If it is lower then block is in the shadow, if equal it's in light, if higher then it's still in light, but array gets updated with the Y of that block.
Now if the block get's destroyed it checks if it's Y is equal to the value from the array and if that is true, that value must be marked as none and search for a second highest block must be initiated, moving down the column wit the same X and Z. And if it goes into unloaded chunks it should just pause till those chunks will be loaded.
I hope that is more understandable. As for your solution as I understood it, you basically want to create that array for every layer of chunks saving SA for the bottom blocks. I don't know which is better in terms of memory usage though, because your value is binary, but saved for each layer of chunks.
Also minecraft is in fact quite CPU taxing, at least for me (not the newest pc) it's a limiting factor. Other thing is that it doesn't quite utilize multiple cores, so CPU may look on the ease with a few cores loaded at 100% and others doing nothing.
It's a nice visual idea, but you'd have to create an algorithm that will generate terrain with far less detail at far distances and keep all three maps stored in your world save. That actually makes sense and may be worth separate suggestion thread, but hardly would help with the lighting issue since that generation must be pretty approximate and so shadow from the very high mountain would consist of large squares, still may be better then nothing, but must be implemented only as an addition to core sunlight mechanic rework.
But then it would have to "degenerate" terrain when you go away from it which is a waste of resources and will make you lose everything you built and dug out. So storing every map would be necessary but would not be so bad, because far terrain will have a very small resolution. Another question is that terrain generation doesn't work that way, it does it all at once. But even making caves generate past entrances only when you go underground would save so much space and power...
Nope, still a great performance hit because you will have to generate those far chunks not only when you visit an area for the first time, but every time and also when you move away from an area too. Which also brings a good point, what if someone were to change landscape massively with a huge castle or nuke explosion, how will that translate into far chunks?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumwomp womp.
=(
Frankly, a sky fortress would be incredibly badass, as would be a world with accurate crust depth.
The only hitch in this thing's giddyap as a mod appears to be the dreaded "lazy."
wouldn't that cause large save files?
Minecraft is not medieval-themed!!! As a matter of fact, it doesn't have a set time. And when and WHY did putting reponses in the quote, especially long ones, become a trend in the Suggestions? It's rather inconvenient, mainly since the OP has to gather your quote up manually. Avatar made by Endergirl!
Not if you save distant chunks and conglomerations of them at longer distances as singular objects. And for farthest ones it would probably be binary (air/ground) since it will be basically forming horizon.
Regenerating this over and over and over with analyzing every single block that is included in them will cause massive lag. Also it can only be generated according to the seed, so if someone would like to terramorph, like building his own Everest replica, well, touch luck. So no, they MUST be saved!
"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:
Yep, finally someone who just like me think that Mojang is a bad game developer, guess I'm not the crazy one after all ^^
By the way, if you are interested in other proves of their incompetence, check out CptSpaceToaster's Colored lights mod (in my signature), it's like 93% working (which is more then I can give vanilla lighting, lol) and in some cases it works even better then vanilla despite quadrupling light channels, but for some reason it does not get deserved attention :c
My criticism is OVER 9000!! Oh, and by the way, ¡llum¡π@t¡ ©oπf¡rmed o3o
But what with the changed terrain?
Also I don't get what you are arguing against? Both of those maps would be equal normal map with 8 chunk view radius in terms of resolution, but since there are less variety in them they'll take up way less space. You are excluding a bunch of stuff like cakes, tall grass, torches, redstone repeaters and much more for chunk blocks and probably using binary (air/ground) for region chunks since those would hardly take up more then a pixel on your monitor and be all fogged. So you'll need way less block id's and so can use smaller variables to save them.
I suggest separating the lighting into a different map which consists only of lighting, this map could run on the current flat chunk system and given the simplicity of the map it would allow significantly greater vertical heights, true not the near "infinite" that proper cubic chunks would allow, but probably 4-5 times current with little performance loss (I dont really have a clue how much better it would be but less data loaded makes for better running, also you can run the map on a different tread.
How the map works is like this, each block would send its current light data (transparent, partially transparent, or opaque and what it emits, 0, 12, 14) to the light map when placed/updated and the map would tell the world what the light levels are, the light updates could modified to happen once every 20 ticks or every tick or as you like.
this map could be simplified to only deal with sky light which would have all the "blocks" only have one of 3 values; no change to light level, ie glass; partial blocking, ie water; or no transmission.
"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: