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 assume that it would be perfectly possible for a server owner to add height limits themselves? (For the same reason many worlds have borders now, to prevent absurd file sizes)
Yes. They would simply designate a minimum and maximum building height in the server properties file. Outside of that height, it would be exactly the same as leaving the top or bottom of a chunk in the existing system (can't place or break blocks, but you can still fall into the void).
In the cubic chunks system, blocks can exist in chunks outside of the build limit, but these chunks are not stored on the disc, simply regenerated whenever they are loaded. The player cannot modify such chunks, and such chunks can be kept empty regardless of what might have generated in them.
Note that the removal of the height limit does not explicitly warrant an increase in world size. The number of chunks that the player can build in only determines the maximum world size. World size itself is determined by how many chunks the player has actually built in. Generally speaking at least.
It sounds like you know this already, but other people may not have read all of the OP and it's better to be sure.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I removed that seeing as to how the rest of the FAQ notes that terrain will not change, and that the void will remain where it is now. It might be readded in the future.
I'm still not ready for this. The problem with such a topic is that there's a good amount of people that, no matter how much I say the suggestions are separate and that the terrain doesn't HAVE to change if Cubic Chunks is implemented, will automatically assume and believe such a thing.
That is a good point. The advertising that these terrains can be toggled (A 3D Biome toggle button in options) could always help. Also a separate topic on it does mean its separate so it would not be grouped in with this suggestion by default. Im just a tad bit pushy on it cause I believe the majority of minecrafters would love to see the possibility that their dream biomes (And there are many suggestion threads trying to get new biomes. This gives a way to implement them) and would be in absolute support of it.
But its your call of course.
Actually i hacked the NBT data in the world and i went so fast java ran out of memory. However i suspect that that wouldn't happen without trying unless you have a treehouse at 99999999999999999999999999999. Not to mention terminal velocity.
@Invarion, bigger trees would be nice. This is one of the options I have always wanted to see in the "create world" menu, along with sliders to modify how bumpy the terrain is, how high sea level is, how often certain biomes appear, and so on.
Lol.
Also, x/z = ±30,000,000 is pretty much the limit of the minecraft world.
Errors typically start occurring after x/z = ±25,000,000. While this is a lot smaller then 10^30, given the player's speed, reaching this distance would still take many thousands of hours of constantly running in a straight line.
The same vertical limits (y = ±30'000'000) will apply with the Cubic Chunks system.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I volunteer! Not the best. But i can try with the editing tools available to me. (Paint.net)
Oh. And also i could do this. I actually looked in the source code to figure some things out. Still learning java though. So i might not be the best at understanding. Although i am at a higher than average. Including NBT tags and their limits. •People with a deep understanding of Minecraft's coding and how it works. Two people have volunteered for this. Importance: ♦♦♦♦
As for a deep understanding of the code, I know it semi-deep. I know basic Java and I know a LOT about servers, modding, save formats, etc, however the one thing I have not done is actually taken a look at the code. I volunteer if you think this is deep enough.
I am thinking of using a pretty standard solution proposal structure. This breaks every aspect of the solution up into smaller sections. These sections are used to organize and index information, and different sections can be delegated to different people. For example, Bill knows all about height maps, and Ben know all about terrain generation. Therefore, we would tell Bill to write the section about height maps, and we would tell Ben to write the section about terrain generation.
It's quite long, so I have put it in spoiler tags.
1. Cover Page
Has a picture, a title, pretty straight forward. Generally, if two reports are exactly the same, bar the cover page, the client will pick the one with the better cover page. It's not crucial, but remember; first impressions are lasting.
2. Executive Summary
For budding essay writers, this is basically just a big-ish abstract. It describes the problem and the solution. It's also the marketing line of the entire solution. You can be guaranteed that if any part of the proposal is read, it will be the executive summary, and therefore this part is probably the most important. It should also be one of the last written sections as its contents must reflect the contents of the proposal.
Again, first impressions are lasting.
3. Indexing
Contents page. It is very important that this is clear and straight forward. It allows the client to immediately visit any section of the report easily. This is hyper-linked to the corresponding sections, and contains all the appropriate page and section numbers. This also means that the document must the use correct headings, and is properly sectioned.
4. Introduction
Now things get a little less straight forward. For now, we will say that it introduces the client [Mojang] to Cubic Chunks. It's not unlike the introduction you would write for an essay, but there are some key differences here and there (in relation to the rest of the structure).
5. Explain various elements of solution
The solution has many elements. It requires a way of storing data, of checking for shadows [height maps], of optimizing the loaded chunks, and so on. Also, it allows for improved world gen. All of these elements get their own sections and are explained in depth, with their own introductions, technical descriptions, and evaluations.
6. Evaluation, analysis, discussion
If the client likes the executive summary, this is basically the next bit they will read (along with the conclusion). Like the introduction, it's not as straight forward as it sounds, but it is essentially just an evaluation and discussion of all of the elements together, and the solution as a whole.
7. Conclusion
As the name implies. There are some things that the conclusion has to do, but I can't really be bothered explaining them right now.
8. Appendix & references
References do nothing more than make it look more professional. They are also essential if we discuss an idea or concept that is not actually ours. If we mention using Taylor or Power series estimations to speed up some maths operations, it gets a reference or a description here. If we reference a game that already uses Cubic Chunks, it gets referenced here.
9. Petition
Basically just a long list with the usernames of every supporter. I'm not fully decided on where this should go, but I do believe that it should go in somewhere.
Please feel free to give input and suggest modifications to this structure. Note that we have identified the problem/requirement ourselves, and therefore we must explain HOW and WHY we did this, as well as HOW and WHY we chose Cubic Chunks as the solution.
The most important point is that the entire presentation has to be clear and organized, with a distinct point of view. This creates consistency, and allows the reader to access the relevant information easily.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Yes, there is a thorough discussion on this in the 1300 posts you have not read. In the event that a chunk is not loaded, the player is simply paused for a couple of moments, and the necessary chunks will then be loaded before allowing the player to continue falling. Fortunately, the relatively small size of each chunk, and a few simple optimizations, allows us to very quickly load/emulate the chunk, and hence the effect would be little more than some slight stuttering and jarring.
Methods to reduce this effect include capping the player's speed so that the chunk loader can always keep up, and putting emphasis on loading the chunks directly below the player. Fortunately the player will not regularly be falling far enough to escape the loaded region. The problem will also almost never be experienced while exploring default terrain as there are few vanilla land features that will ever allow the player to fall more than 3-4 chunks.
Overall, it is a slight disadvantage to this system, however it is not prominent and can be drastically reduced if not entirely removed, provided the Cubic Chunk system is implemented well.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Mmmm. Duly noted.
If anyone has some figures for how long it takes an average computer to generate and load cubic chunks, I would be interested to know.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.