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
Depending on how the chunk loading works, it may be possible to make dropper maps still be made to work somewhat. Dropper maps can only have a fall of about 250 blocks, or 144 Cubic Chunks for the entire fall (including the chunks around the chunk in which the player is falling).
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Sure with current vanilla generation; however, if they added any sort of generation that exceeds those specifications, they have to change the system to work with it. That is why the system must work from anywhere, at any time in the map, with any mod(modding api).
And that is not capitalizing on mod maker's ideas exactly how?
Because
1. They're listening to the community. They're putting in content that they think MOST people will enjoy.
2. They're legally Mojang's ideas.
3. If you don't want them to put new content in, the suggestion portion of the forums is a really odd place to be.
What about negative lighting? Have everything naturally be well lit, but the bottom of blocks cast a shadow/subtraction value to said light. If possible, that fixes overhangs and underground.
As far as things being out of load range affecting something in load range, all I can say is, good luck with that. Hard to make a program recognize something it doesn't have to recognize. Especially with the whole infinite ceiling thing going on. If the ceiling had a limit, which is what you're trying to fix, it's easy to solve.
Full support.
Unless capitalization means some drastically different than the dictionary claims, you're still not answering my question.
Assumption as to my opinion.
Do stop.
Capitalization is often used to indicate emphasis. In this case, it is meant to indicate the opinion that since many people enjoy the mods, so Mojang has decided to integrate them into the official code for all people to enjoy.
No, I believe I have provided a more than sufficient answer to your question.
Obviously. I AM human after all, and you did seem to be indicating disapproval towards Mojang adding things to the game.
That's why this will be configurable: you will be able to choose the minimum and maximum generation heights (if you use a generator or if a new generator is implemented) and the minimum and maximum building heights.
I am not a programmer either but I think this would reduce some calculations, because there are often more blocks at 15 light levels than blocks at 0 (if the lighting system doesn't already work like this, knowing that night vision potions remove shadows (and some lag)). But the most laggy thing is often the lighting updates that would still be a problem.
Note: The following systems, will, not, work. They've been suggested here tons of times, and are not constructive:
-Raytracing for dynamic shadows. Requires storing a 3D mesh of some sort, and raytracing from an infinite point. Given that the mesh would be infinite in size, raytracing from a point at infinity(The sun) is not possible.
-Ignoring shadows cast by blocks above a specific height. Assumes that sunlight can reach an area if only a single column of blocks are ignored. Cannot verify if sunlight is physically able to reach an area without raytracing, which doesn't work, as explained above.
-Storing light columns. Traditional sunlight accesses horizontally adjacent blocks. Using a single column for calculations would ignore horizontally adjacent blocks.
-Saying we're in spaaaaaaaace and there is no sunlight. No.
Kind of weird I know, but it should look decent and be similar to calculate as what vanilla is already doing.
Calacbolg, my idea of how the height-map works is that you ray-trace initially from a certain layer in the sky to generate the heightmap, and then you calculate the light based on that. Nobody ever said that horizontal blocks would be ignored, any blocks above and at the highest point determined by the heightmap are calculated and set to light level 15, then light is calculated normally using the normal methods (think that glowstone is placed at those blocks and light is spreaded). Blocks placed above the initial ray-tracing height still get light calculated properly, the initial ray-tracing is only for forming the heightmap, which will be modified when blocks are placed above the highest block or the highest block is broken.
This method may or may not be faster than the current system, but the efficiencies of Cubic Chunks should definitely make up for that.
Sounds about like what I said, so it must not be too weird if more than one person thought of that as a solution.
I like the idea of negative lighting for the day/night cycle. If a block is exposed to the sky then subtract light starting from the furthest loaded chunks in a sweeping pattern. Instead of an actual "sun", have a degree location to determine how a shadow should be cast. Minecraft earth is square after all. These are just my on the spot ideas. I have not put much thought into them, so excuse any nonsense.
And that brings up another possibility that could help with the lighting.
Use infinite height only in one direction; downward
So the ceiling is height 0, and as you move down the value goes up (depth meter basically) with no possibility for negative height value.
This would allow for keeping vanilla style light calculations that just need to be saved per-cube so that the entire column doesn't have to be calculated constantly.
Then different generators can use different sea levels to give you 128, 256, 512 or whatever blocks of surface, floating islands, etc before beginning the infinite abyss
Infinite height is infinite height no matter how you offset it. If a generator starts you off at 20km below 0, with sky islands, it runs into the same exact issue as having the world spawn you at 0 and having a a negative depth and positive height with sky islands.
Best suggestions so far are using LoD to render distant chunks, with shadows being based off those; and/or using vertical chunk compression in relation to solid and empty.
I am; I have actually modded the game to generate terrain that is 64 blocks higher than normal (adjustable to anything between +0 and +128 with a global variable in a new class I added); that is, terrain generates normally but is offset by 64 blocks, with the 64 blocks under the normal terrain filled in with stone (bedrock removed from normal terrain and replaced at y=0); sea level is at 127 instead of 63.
I did this so I could double the height range of caves, greatly increasing the amount per area, even with a decrease in cave density (air blocks vs total blocks). Although as far as ores go I just adjusted the range and frequency to match the increased terrain height, so there is about twice as much iron and coal ore (same density, so a given amount of cave has the same amount exposed; for the rarer ores, I factored in the height above the lava level in caves (also reduced from 10 to 3, which I had previously done, lowering the ranges of rare ores by 7). Note that I also had to adjust a lot of other things, with a total of about 20 classes modified (e.g. slimes and squid only spawn near the surface, which would now be well underground).
Of course, this is pretty hard on the game, not so much because of the extra 64 blocks of terrain (simply filled in with stone, no calculating terrain, etc), but because of all of the extra caves, forcing me to use Minecraft Land generator to pregenerate a world (when testing in Creative in MCP, I can easily outfly terrain generation over the largest cave systems; +128 blocks also causes severe FPS lag (out of dedicated VRAM?) when looking down above a big cave system unless I reduce render distance, which is why I went with +64), although this means that I only need a few modded classes on the client (SSP) to fix mob spawning ranges (I changed the world type to superflat with a void preset + bedrock wall to prevent new chunk generation).
On the other hand, the vertical chunk generation problem could be partly avoided with cubic chunks, but the way cave systems are generated would still be a problem (the game recursively iterates through an entire cave system for each chunk within a range of chunks, which is how it knows to place a cave in chunk x, z when it originates at chunk x+5, z+7 or whatever; I partly alleviated this by making the biggest cave systems generate in many chunks, much larger than the range checked, but it still has a huge performance hit; cubic chunks world make this even worse due to more chunks in the gen-range, unless a completely different cave generation algorithm is used).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I love the Portal reference.
As it will be in the future, it was at the birth of Man
There are only four things certain since Social Progress began.
That the Dog returns to his Vomit and the Sow returns to her Mire,
And the burnt Fool's bandaged finger goes wabbling back to the Fire;
And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!
-The Gods Of The Copybook Headings, by Rudyard Kipling.