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
but anyways, amzing post! you just made my day.
That's a shame.
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.
To answer your question, I dont see why not, though I am not quite sure how exactly the zeplin mod works...
An oddly appealing idea. I am in the beginning stages of an epic build that I expect will take me months to complete, (but it will be crippled if Cubic Chunks isn't implemented into Minecraft,) and I've considered adding a skydock but I almost didn't think there would be a use for it.
But I have one now...
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.
Oh, thanks for the link. All though I may have come across it before. Server jumping is not my idea, so I probably got it from here or from another related site.
But from what I have read in some of the other threads, they are not necessarily talking about server to server interaction, but rather moving entities and I presume constructions from one server to another. I brought it up here because I wonder of the coders working on this project might have thought about this. If they can't include the multi-world platform in the the alfa version, that they at least think ahead and lay a foundation for later code work.
Or of the 3d chunk system might hold strengths or weakness over the current system. Including the full six axial representation of world-files.
As for future-mod itself. This sounds incredibly ambitious for a mod. I am not sure just any thing can be done with a mod, or even multiple mods if they are not carefully coordinated. But I do think that server jumping is not just something that would vastly improve the game, I think its something that Minecraft needs to execute in order to stay competitive.
See here, you're not the first person to bring it up, and in fact it was discussed very recently in this topic. I don't know why you'd think you're the first person to bring this up - I take each issue to heart and attempt to remedy it in the main post, and thus far, an issue with what you've brought up has not shown itself to be true.
To be honest, there is an issue with generating chunks infinitely on any axis. It's called the Far Lands.
But it would be nice if they took another look at it, terrain rendering lag being the most annoying thing in the game at this point.
D_B
To tell them how to live is to prevent them living.
Nice play on words, thanks for supporting.
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.
I'd assume that the world files themselves would only need three coordinates, with ships and such stored as some form of multiblock entities with the six-axal position storage. Minecraft currently uses only 5 coordinates to store positions (X, Y, Z, Pitch, Yaw. Missing the rotation/roll.), so we'd need to add that axis to entities first.
I think I may have come up with a concept for truly infinite position and generation, but it's still just in my brain. Basically, when an integer exceeds it's maximum bit value, then the integer gets represented in double the amount of bits, half as many for getting closer to 0, 0. Ex: anything below 2^16-1 is represented with a 16-bit integer, while everything above 2^16-1 and below 2^32-1 is represented with a 32-bit integer. This system also decreases lag for low-value coordinates, making the game laggier the farther you go. There would be an initial cap of ( (2^32-1)^ 2^32-1)^ 2 on 32-bit systems, simply because of the fact that you could reach 4 billion bits of information. Any feedback appreciated.
As far as i know that is possible.
There are 16bit, 32bit and 64bit types called short, integer and long respectively (There is also BigInteger which could grow as big as your memory). But i don't think its that easily to integrate, after all it needed to be checked which is actually used and needed to be cast to the other type. Integrating BigInteger would be a much greater undertake.
imho the 32bit int it currently uses is suffice, because the is no "normal" way to reach the far lands.
Errors and omissions excepted.
Again, mind my ignorance of the code at work here, but here are my thoughts on this issue.
When a craft is created or ported into the world, it exists as a secondary world file. The host can set condition on the file, limiting its size or even its movement (enable/disable pitch, yaw, and role) and limit velocity. This could be to reduce computing load, or simply in keeping with the game style. If created in world, the blocks are removed from the primary world and added to the secondary world file. If imported from another server, a new secondary world file is created and place in the far off reaches of the world to begin its approach.
The server then treats the secondary world file as it dose the primary world file.
This is where the tri-chunks become useful. The secondary world file exists as chunks, just as in the primary world file. The only difference is that empty blocks would be treated as void blocks. If a player steps off the edge of the secondary world file and into a void block, the server transfers him to the primary world file based on a translation of his/her XYZ coordinates, presumable falling to their doom.
Each chunk in the secondary world file will also be given a chunk address found in the primary world file. Thus a player in the primary world loads up chunks for the graphics engine, it will also call up the chunks found in the secondary world file. These chunks can then be translated for the graphics engine. Likewise a player on a secondary file will upload the chunks found in the primary world file as well as any other secondary files that may be in view.
The chunks them selves only need to have address relevant to their XYZ location relative to the primary world file. Pitch, yaw, and role are irrelevant here. This data is only needed for the graphic engine and for hit detection. If course pitch, role, and yaw influence where secondary chunks are located in the primary file relative to each other. If the secondary file turns 360 degrees, the chunks will have to move in the same way. Otherwise the graphics engine might get confused when it tries to render the data in each chunk.
By definition, there is no block-to-block interaction between primary world file chunks, and secondary world file chunks. A BUD update taking place in one file will not influence any other file, so there is no need to worry about this interaction. The only interaction would be hit detection, resulting with the destruction of blocks in both files or expulsions if the secondary world file is given enough momentum in relation to the primary or secondary world file it makes contact with.
This would mean rethinking how explosions work to prevent lagging the system in the event two large ships collide. Then again perhaps this needs to be done any way.
Hit detection may be a bit tricky. This is something that even high end simulators have issues with. We can start off by only bothering to calculate hit detection for adjacent chunks or chunks occupying the same address. Just as there are block updates, we can use chunk updates to add or remove chunks that are to be on the lookout for hit detection.
Chunks that are on the hit-detection watch list will create a collision map, similar to the height map used for sunlight. Thus we only do hit detection for those blocks that are a part of the collision map, ignoring all other blocks.
Each block listed in the secondary file collision map are then translated into XYZ coordinates relative to the primary map. If the collision chunks are both secondary files, then both are translated into primary file coordinates.
Any in the XYZ map that shares coordinates will be identified as a positive hit and a collision sub-routine will be called in. If the ship is moving slow enough, the secondary world file will just come to a jarring holt or just a simple thud. As energy increases it starts destroying blocks, starting a BUD update in both chunk files. As the BUD update takes place in both files, this also redraws the collision map. The subroutine might also slow the velocity of the secondary chunks.
There might also be a safety in place to prevent leg from large secondary files colliding, basically destroying both secondary files in a massive explosion, dumping the secondary chunks, and ending the lag issue. This is assuming that the collision is fatal.
Something else that might prevent lag would be having secondary files require fuel in order to move. When the fuel is shut off, the secondary file is gradually slowed until it snaps back with the primary file grid. It is then considered to be a rested secondary file, and thus removing the chunks from the collision watch list if they are on the list.
If it is at rest, then the secondary file could then be joined with the primary file, temporarily moving the data from the secondary file and placing them in the primary file so that they can share BUD updates. But the secondary file will still remain in place.
Once the ship is re-launched by adding fuel to the system, the blocks from the secondary file are removed from the primary file and the secondary file is taken out of rest mode. The chunks are now added to the collision watch list again and the secondary file is now aloud to move again.
The only other thing that remains is how to have primary world file and secondary world file interactions. I have already said that BUD updates are not permitted between files until the secondary file is at rest.
But how would an avatar jump from one file to another? Well, for this to even be possible, the avatar would have to be in a chunk that is in the collision watch list. If this is true, than the avatar it self will be added to the watch list. If the avatar is falling or flying in an empty chunk, then the chunk is not considered empty as far as hit detection and the empty chunk is added to the watch-list.
If the avatar intersects with the collision map, the position data of the avatar is moved to a subroutine that handles the transition, and it is then deposition onto the new file. The same would go for any entity.
Then there is ballistics. Let's say we have a pirate battle and we are firing cannon balls at each other. As the cannon ball moves through space, it is moving through chunks. If the chunk is empty, no calculations are needed other than moving the ballistic.
But the collision map will not work here as there is a chance that the ballistic will actually fly through the map without making contact and the game will think it’s a miss. How it should work is that as the ballistic moves through space, it will call up all chunks it passes through, primary and all secondary's. A copy of the ballistic will then be placed in all chunks. The ballistic then works by using the BUD update.
If it gets implemented at all.
The cupic-chunk system is ambitious as well. And roomers persist that Mojang has already discarded. This would be a bad move on their part because cupic-chunks bring so much potential to the table. Secondary world files is just one more possibility to be added to an already impressive list. I think there is also permission to start thinking about what we can do with all of that empty space.
Your journey begins there, not here.
I don't like those rumors
Actually it begins here
http://www.minecraftforum.net/topic/710528-futurecraft/page__hl__ fr0stbyte124