From optimizing settings on optifine, i went from about 10 fps short view without to 35-50 far view with.
Point is, exactly how much incompatibility is there between this mod and that?
It's my understanding that Optifine & Cubic both change some of the same classes. So the only way Robinton could make them compatible is if he had permission & source from the Optifine author, sp614x, to merge it into the shared java classes.
Robinton & sp614x must have communicated at some point since sp614x has already explicitly allowed him to directly and completely add his "LagSpikeOfDeath" mod into the Cubic Chunks mod, which was done a long while ago. So since Robinton has been asked this many times it might work better if we asked the Optifine author nicely to allow this. :wink.gif:
[EDIT] It just dawned on me that the combined classes would need to be in a separate Patch, not in the main CC Install! The results of someone installing only CC without Opti but still having pieces of Opti active could be catastrophic, heh heh. But otherwise everything above still applies. If the Patch existed then people could just be given the following instructions:
Personally I can't tell what looks better with the high antialiased mipmapping, it doesn't really look better to me, just different... but that's another conversation.
Hi. Great questions! I can't answer for Robinton, but I'll respond for myself with some quick info that I have that might be helpful and with some of my personal thoughts on the issues. btw: It's always good to have someone asking these kind of questions, have you been making mods already or planning to? You sound like you are. :wink.gif:
I've been planning variations of content mods for a while, but I'm really waiting until Mojang opens better support for modding. The ideas continue to evolve and grow in my head in the meantime. I won't dare to do any game mechanics mods until I take the time to read the unobfuscated source at some point, but I have a firm grasp on how a few ideas would be implemented if I knew my way around the core files. Time is also a relevant factor.
1.
The last idea you mentioned, 1 averaged pixel per side, seems to most accurately match my understanding of Robinton's plan at this time, though I and others have chatted with him regarding other possibilities as well, such as combining it with a static image of the environment that is even beyond the range that he is planning to use the compressed chunks up to. Earlier on the idea of using multiple levels of compression for each chunk was raised but at this time Robinton isn't interested in doing that because of how much it would affect the world save size.
Robinton has expressed a great personal interest in the over-all compressed chunk and far view concept since the beginning so you can count on him following up on it. Right now he still has SMP and overall bug-fixing and such to focus on but he will be getting there.
Long distance view is so crucially important in tandem with slowly setting distance fog and environment shifts to make a truly massive sandbox game feel as big as it is. When we get oceans, rivers, more diverse biome content, and then mods like this with far view rendered backgrounds and massive increases in height limits (huge mountains!), some random villages, high res textures, the lovely GLSL mod updated, optifine, and season + weather cycles... this game, is not only going to BE huge, but it's finally going to FEEL huge. Anyways, I imagine that having 6 total layers of compression or more could triple the save file size, and since minecraft is constantly writing to disk, that might slow down chunk unloading, so there's a sweet spot in there, probably at about 3 levels of compression: normal (16 pixels per block), far (1 pixel per block), and very far (1 pixel per chunk). With some tactical layering of rendered spaces, and appropriately optimized fog, that could probably look nice and smooth, and I imagine it would actually require something like the optifines code to get down to a reasonable fps for a lot of computers.
2.
Yeah; the issue is not a matter of what any one person thinks is excessive, as there are people who WILL find a use for the space (Space mods etc), but instead what the cost/benefit ratio effect will be on the coding and world file sizes. The jump from 4096 to 65504 was, according to Robinton, a fairly trivial thing to do and should have no overall negative impact on the game's performance. So since there are no truly tangible negatives to allowing a 65504 block/meter vertical space there is not only no reason to not have it but every reason to have it even if only one person wants it, and they do.
Even the 4.2 billion vertical limit only raises the save file sizes by around 20%, and considering that he recently reduced the save file size of one world from approx 600mb down to 21mb with a redo of his save-file system, I suspect people could deal with that same file being 25mb instead. :wink.gif: - Even so; he has told me that a 4.2 billion size is not a top priority for him right now compared to other features. I've thrown out the idea to him that after everything else is done with the mod that he could release a "Cubic Chunks XT" version of the mod, or something like that, which would give people a 4.2 billion space if they want it, allowing others to just use the 64k version with slightly smaller saves. This wouldn't interfere with the development of the main mod.
3 dimensional chunks, gotta love it. :3
I had no idea it worked so smoothly, but I can't really imagine what the hang up would be considering how chunks load into memory and then hdd, so that makes sense.
Also I had not even considered the possibility of a world server as massive as a space scenario. something of that nature could plausibly require a special rewrite of its own to optimize for a high prevalence of empty space to keep save file sizes down, but it's a very novel concept.
3.
It may not even be possible to raise the Block ID limit to 4096 anyway without major hacking, but he will find out one way or the other. I suspect that Robinton will actually raise it to whatever figure is reasonably doable without having to completely rewrite the game engine and cause a bunch of bugs and spend too much time on it.. :wink.gif:
People involved with other mods have asked him to do this, and there is a very good reason. Raising the ID limit isn't even so much about actually using that many blocks all at once on a single install as much as it is to help insure that the largest possible number of mods will be able to be automatically compatible with each other on the common CC base in regards to block ID's and having different ones.
Though when you see things like YogBox, there's no real way to predict how many block-ID's may be needed at one time by some people someday, better to make it possible now than later. If using that many mods at once slows a persons computer down too much they will always have the option to either not add so many or get a faster computer. Either way it will be their choice.
The Cubic Chunks Height Mod is a very Core type of mod that will become a central requirement for compatibility for many people in times to come, if they want to play in a higher world, and so there will be many different mods using many of those ID's that would be guaranteed to conflict with the standard Block ID limit. If we're really lucky maybe we'll see a limit upgrade directly from Mojang before or by the November release, considering the Developer program opening up and all. :wink.gif:
Well, at 4096, we are talking a significant increase in the bits required to store the data in memory, so even if they are unused, the hard limit change could cause the game to become unwieldy in memory without some sort of pre-load block ID listing system stored in a sort of reference list in the memory to keep it at a reasonably small bit space, which, for all I know, is actually how it already works, but I imagine it would slow the bus calculation of all block IDs because of the extra time taken to i/o in a cycle through the bottleneck instead of keeping it as a straight back and forth 1 i/o to processor and back. Gah, where are memristors when we need them haha. That being said, I'm merely snatching at ideas, I'm not terribly familiar with the actual details of the minecraft code in that regard :3
4.
Yeah, this has been brought up before, I'd love to hear his ideas on this too! :smile.gif: Though there might be a legitimate fight with people who would NOT want to lose the 8:1 distance benefit we have by using the nether. I have proposed though, and others have done similarly since, that with as much space as there is now that there could be other "pocket" realms and such deep underground as well as on sky islands or "moons" really far up, even with the capacity for varying gravity as he has already shown can be done. :smile.gif:
At this time, from things he's said, it sounds like he will leave that for other mods to add. He's even supplied the ICubePopulator code to assist other modders in adding things to a Cubic World including plug-in terrain generators that only affect certain levels. Personally I am really looking forward to these sorts of things being addable on top of CC. :smile.gif: "Lost-World" types of mega-pockets a few thousands blocks down and Moonlets waay up. :biggrin.gif:
I am excited for locational terrain generation as a concept, and I think for the most part a decent amount of people aren't even aware there is a 1:8 ratio because it just doesn't seem very significant and portal placement is fairly erratic. I liked the idea of the nether for fast travel, but in reality I've never really used it for that, because it's just not very good for it. It should have a more appropriate 1:16 ratio, where each chunk in the real world correponds to a block in the nether, but since it doesn't, I say kill it anyways and render the nether biome in a layer a hundred blocks below where bedrock typically is, and fill the area in between with magma and obsidian and the occasional tunnel (he should see about implementing mods by regions in the map, such as mods being initially loaded, immediately disabled in regards to function, and then re-enabled at certain height parameters).
@robinton if you ever raise the number of block IDs, see what you can do about making that field for blocks non-static. because currently it is static, which means you can't put a variable in there, which prevents my "have a text file to edit the IDs between mods to fix compatibility issues" plan. I really don't understand why it's a static in the first place, if it where to change and cause a problem, it would be like any other important number in the code you don't want to screw up :/
edit: also the glowing mushrooms are coming along
things i need to do:
-it's a flower not a mushroom, so it can't grow on stone -make an item from it
-it needs to be edible
-it needs to apply a "glow" buff to the player when eaten
-textures while holding need to be updated
-i need to configure the generation to CC
@Robinton: The Gen_Code.zip anchor works where it now is. :smile.gif:
@wintermuet:
1. I completely agree with how huge an effect having a true horizon of some sort will have on the game. :smile.gif: I had been thinking along the exact same lines regarding compressed chunks, though I didn't have a name for it :wink.gif:, for months before finding this Mod. That's part of what really caught my attention when Nocte first pointed the Cubic Chunks Mod out in another thread and I saw his to do list. You might find this post interesting. :wink.gif:
Long distance view is so crucially important in tandem with slowly setting distance fog and environment shifts to make a truly massive sandbox game feel as big as it is. When we get oceans, rivers, more diverse biome content, and then mods like this with far view rendered backgrounds and massive increases in height limits (huge mountains!), some random villages, high res textures, the lovely GLSL mod updated, optifine, and season + weather cycles... this game, is not only going to BE huge, but it's finally going to FEEL huge. Anyways, I imagine that having 6 total layers of compression or more could triple the save file size, and since minecraft is constantly writing to disk, that might slow down chunk unloading, so there's a sweet spot in there, probably at about 3 levels of compression: normal (16 pixels per block), far (1 pixel per block), and very far (1 pixel per chunk). With some tactical layering of rendered spaces, and appropriately optimized fog, that could probably look nice and smooth, and I imagine it would actually require something like the optifines code to get down to a reasonable fps for a lot of computers.
2. I think that 3D Chunks worlds already deal with empty space "air" like that, but I could be wrong about how the World Save would work if there were a "Moon" a ways up and you traveled to it. I like to think that all the emptiness in between would not require any World Save space to be saved. Robinton, any insights on that? btw: You might also find this interesting. :wink.gif:
3 dimensional chunks, gotta love it. :3
I had no idea it worked so smoothly, but I can't really imagine what the hang up would be considering how chunks load into memory and then hdd, so that makes sense.
Also I had not even considered the possibility of a world server as massive as a space scenario. something of that nature could plausibly require a special rewrite of its own to optimize for a high prevalence of empty space to keep save file sizes down, but it's a very novel concept.
3. Ok, that's something I just wouldn't know about. If it were to have a big slow-down effect on this game for people then more thought and experimentation might need to be done at that time on where the balancing value point would be for that. I would personally want the effect to actually be tested though to know for certain. :wink.gif:
Well, at 4096, we are talking a significant increase in the bits required to store the data in memory, so even if they are unused, the hard limit change could cause the game to become unwieldy in memory without some sort of pre-load block ID listing system stored in a sort of reference list in the memory to keep it at a reasonably small bit space, which, for all I know, is actually how it already works, but I imagine it would slow the bus calculation of all block IDs because of the extra time taken to i/o in a cycle through the bottleneck instead of keeping it as a straight back and forth 1 i/o to processor and back. Gah, where are memristors when we need them haha. That being said, I'm merely snatching at ideas, I'm not terribly familiar with the actual details of the minecraft code in that regard :3
4. The Glowstone and the rapid transit are the two main reasons I have for going down there at this point. :tongue.gif: Somewhere in this thread I did make a case for integrating the Nether though, then someone else reminded me about the 8:1 issue and Robinton said he would leave something like that to other modders. Currently, at least when this mod was 4096, he has a deep "ocean" of lava at the bottom of the map. Here's Robinton scuba-diving in the lava at the core. :wink.gif:
And just to show my sincerity, here's one of the statements I made about the Nether in CC a while ago:
You know, every hour of every day I'm falling in love with the idea of the Nether being physically reachable by making it, somehow, through those 48 layers of the Lava Ocean/Sea down at the core. The Nether could be the Core of the core. :wink.gif: AND creating a physical access point into the Nether could be an "allowed" way for water to be brought in to the Nether!!!!
I am excited for locational terrain generation as a concept, and I think for the most part a decent amount of people aren't even aware there is a 1:8 ratio because it just doesn't seem very significant and portal placement is fairly erratic. I liked the idea of the nether for fast travel, but in reality I've never really used it for that, because it's just not very good for it. It should have a more appropriate 1:16 ratio, where each chunk in the real world correponds to a block in the nether, but since it doesn't, I say kill it anyways and render the nether biome in a layer a hundred blocks below where bedrock typically is, and fill the area in between with magma and obsidian and the occasional tunnel (he should see about implementing mods by regions in the map, such as mods being initially loaded, immediately disabled in regards to function, and then re-enabled at certain height parameters).
-it's a flower not a mushroom, so it can't grow on stone
-it needs to be edible
-it needs to apply a "glow" buff to the player when eaten
-textures while holding need to be updated
-i need to configure the generation to CC
Nice! :biggrin.gif:
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
-it's a flower not a mushroom, so it can't grow on stone
-it needs to be edible
-it needs to apply a "glow" buff to the player when eaten
-textures while holding need to be updated
-i need to configure the generation to CC
If you need any help with textures, I've got a knack for these sort of things, :3
Here's some suggestions, if you don't mind me giving them:
Use a slightly more darker color around the edges of the mushroom, and a whiter glow coloration towards the center, and give the whole thing a tiny pump of yellow, because right now it seems to look a little bit odd. I love the idea though, and so far the sprite does look good.
If you need any help with textures, I've got a knack for these sort of things, :3
Here's some suggestions, if you don't mind me giving them:
Use a slightly more darker color around the edges of the mushroom, and a whiter glow coloration towards the center, and give the whole thing a tiny pump of yellow, because right now it seems to look a little bit odd. I love the idea though, and so far the sprite does look good.
ty, I havn't put a ton of time into it the textures (as they're easy to change at any time), and I was more focused on them existing than how they look :smile.gif: i'm looking into making them edible now, and then applying a buff, and then making the buff. so if you want to mess with the texture's colors you're welcome here's mine (( ))
@WinterMuet:
1. My initial thought (which I could change, if I saw a better alternative that I still had a hope of successfully implementing) was to figure out which block, at which brightness, would be most seen from each face of each 16X16X16 ChunkCube. Then render the ChunkCube as a single block, with each face's texture and brightness determined by the most-seen algorithm. This would result in a memory / hard-disk usage of about 8-10 bytes per ChunkCube (each ChunkCube is around 10000 bytes uncompressed), and 1 draw call per appx. 100 uncompressed.
Fundamental drawback to my idea is that it looks blocky, and might not reduce lag quite as much as it should.
Fundamental drawback to your idea is that I don't have the graphics and rendering experience to implement it. My experience is with chunks.
2. I definitely see your point. I'm currently using 65,000+ because it is probably larger than anyone will ever use, yet the y-axis still just barely fits within the limit of the "short" data type.
I don't see any point in limiting others to +-2048, when I can (with almost no overhead) extend it to +-32,000. I don't see many uses for the extra space, either, but give them space, and sooner or later someone will use it.
3. I picked 4096 as a possible limit because it would use exactly 1.5 bytes to store the BlockType. The current 256 limit uses exactly 1 byte to store the BlockType. For each block in the world (ignoring air ChunkCubes), Minecraft must store 2.5 bytes: 1 byte for blockID, 0.5 bytes for MetaData, 0.5 bytes for SkyLight, and 0.5 bytes for BlockLight. Thus, allowing up to 4096 blockIDs would actually only be a 1/5 or 20% increase in save size.
4. It could be done. Chief complications would include: in the Nether, absolute darkness isn't as dark as in the Overworld; skylight isn't calculated in the Nether, this is a definite optimization; the terrain Generator would need to be dramatically re-written; spawning code would need to be re-written. EDIT: and, oh, yes, the 8:1 NetherTravel effect.
I'd have to hardcode the Nether height limit (or at least the existence of this limit) into several functions. It wouldn't be easy, but it could be done.
Also, from the later post, cool idea about height-enabled mods.
@MineCrak: You are correct. All of the intervening ChunkCubes would be air and therefore never saved.
@MarcoPolo1613: Keep up the good work.
Sorry anyone I missed; the more time I post, the less I code.
Oh, and my quarry is acting strangely: whenever I play around the top of it for a while, then walk down into it, I see a bunch of sheep and pigs that had been suspended in midair fall to the ground and die.
Thanks, and BTW, the Cubic Chunks and Flood mods are not compatible, as they both modify the terrain generation. I should probably release a CC-compatible version of FloodMod. You can, however, create a Vanilla world with Flood, then convert it to Cubic Chunks format. So, even before I release a CC-compatible Flood patch, you can have flooded Cubic Chunks worlds.
I just made some save-fixes, and tested the Minecart replication bug. I ended up writing myself a stairway-building hack (hacks are awesome :biggrin.gif: ). I tested several different combinations, and I couldn't find any problems. I'm pretty sure I fixed it. I'll release that and a few other fixes soon.
4.2 mio km ... well ...
"The sun has a diameter of about 1,392,000 km"
4.2 million km only goes that far? Robinton; you'll need to figure out how to up that to at least 200 million km if we're going to get at least the inner solar system on the same map running on your beowolf cluster...
:wink.gif: :biggrin.gif:
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
Thanks, and BTW, the Cubic Chunks and Flood mods are not compatible, as they both modify the terrain generation. I should probably release a CC-compatible version of FloodMod.
I just made some save-fixes, and tested the Minecart replication bug. I ended up writing myself a stairway-building hack (hacks are awesome :biggrin.gif: ). I tested several different combinations, and I couldn't find any problems. I'm pretty sure I fixed it. I'll release that and a few other fixes soon.
Please do, to everything you just said. :smile.gif:
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
you can't eat the gel yet (made from glowing musrooms and glowstone dust), though I thought I programed it to remove one from the stack when you right click :huh.gif:
anyways, a screen shot:
edit: it kinda looks like tooth paste, lol
things to do:
-make edible
-add glow buff
-adjust mushroom spawns for CC
- fix textures on mushrooms
- maybe make the gel glow (not sure if i can)
WARNING: Opening the spoiler may spoil your milk/bread/Head
Rollback Post to RevisionRollBack
Quote from Aqualize »
it will obviously be CHOCOLATE ORE
used to make cocoa beans and CHOCOLATE CAKE and CHOCOLATE INGOTS
CHOCOLATE INGOTS will be used to make CHOCOLATE TOOLS which are obviously much stronger than diamond and also may be eaten if you are hungry.
Thanks, and BTW, the Cubic Chunks and Flood mods are not compatible, as they both modify the terrain generation. I should probably release a CC-compatible version of FloodMod. You can, however, create a Vanilla world with Flood, then convert it to Cubic Chunks format. So, even before I release a CC-compatible Flood patch, you can have flooded Cubic Chunks worlds.
I just made some save-fixes, and tested the Minecart replication bug. I ended up writing myself a stairway-building hack (hacks are awesome :biggrin.gif: ). I tested several different combinations, and I couldn't find any problems. I'm pretty sure I fixed it. I'll release that and a few other fixes soon.
Good to hear, Robinton! I've been playing Aethermod till you fixed it :biggrin.gif:
Now then... anyone got an estimate of how long it'd take to dig straight down to the core? 65000 blocks? a guess, anyone?
4.2 million km only goes that far? Robinton; you'll need to figure out how to up that to at least 200 million km if we're going to get at least the inner solar system on the same map running on your beowolf cluster...
:wink.gif: :biggrin.gif:
Tehe... eh... well... if we go over that, we may as well include the closest star, Proxima Centauri, as well... lol.
you can't eat the gel yet (made from glowing musrooms and glowstone dust), though I thought I programed it to remove one from the stack when you right click :huh.gif:
anyways, a screen shot:
edit: it kinda looks like tooth paste, lol
things to do:
-make edible
-add glow buff
-adjust mushroom spawns for CC
- fix textures on mushrooms
- maybe make the gel glow (not sure if i can)
WARNING: Opening the spoiler may spoil your milk/bread/Head
That... is just Robinton being amusing. He added an invulnerable mob to make it look like he's keeping an eye on ya. It spawns randomly, but only occasionally, and only one at a time. It's invincible to every form of attack and if you try to bash him directly, he'll set you on fire (even if you shoot arrows at him). He can breathe underwater and is flame-proof (you can set him afire, but if he moves outside the source flame, he goes out). Ignore him if you can. Attack him at your peril.
It's my understanding that Optifine & Cubic both change some of the same classes. So the only way Robinton could make them compatible is if he had permission & source from the Optifine author, sp614x, to merge it into the shared java classes.
Robinton & sp614x must have communicated at some point since sp614x has already explicitly allowed him to directly and completely add his "LagSpikeOfDeath" mod into the Cubic Chunks mod, which was done a long while ago. So since Robinton has been asked this many times it might work better if we asked the Optifine author nicely to allow this. :wink.gif:
[EDIT] It just dawned on me that the combined classes would need to be in a separate Patch, not in the main CC Install! The results of someone installing only CC without Opti but still having pieces of Opti active could be catastrophic, heh heh. But otherwise everything above still applies. If the Patch existed then people could just be given the following instructions:
1. Install ModLoader
2. Install Optifine
3. Install Cubic Chunks
4. Install Opti/CC Patch
5. Play! :biggrin.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
Also, they are insanely busy over some AF/AA mipmap thing.
Yeah, ok, I might make an inquiry. btw: I updated the bottom of my above post.
[EDIT] The request has been PM'd. sp614x isn't online atm. If anything comes of it I'll let you guys know. :smile.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
Anyways:
I've been planning variations of content mods for a while, but I'm really waiting until Mojang opens better support for modding. The ideas continue to evolve and grow in my head in the meantime. I won't dare to do any game mechanics mods until I take the time to read the unobfuscated source at some point, but I have a firm grasp on how a few ideas would be implemented if I knew my way around the core files. Time is also a relevant factor.
1.
The last idea you mentioned, 1 averaged pixel per side, seems to most accurately match my understanding of Robinton's plan at this time, though I and others have chatted with him regarding other possibilities as well, such as combining it with a static image of the environment that is even beyond the range that he is planning to use the compressed chunks up to. Earlier on the idea of using multiple levels of compression for each chunk was raised but at this time Robinton isn't interested in doing that because of how much it would affect the world save size.
Robinton has expressed a great personal interest in the over-all compressed chunk and far view concept since the beginning so you can count on him following up on it. Right now he still has SMP and overall bug-fixing and such to focus on but he will be getting there.
Long distance view is so crucially important in tandem with slowly setting distance fog and environment shifts to make a truly massive sandbox game feel as big as it is. When we get oceans, rivers, more diverse biome content, and then mods like this with far view rendered backgrounds and massive increases in height limits (huge mountains!), some random villages, high res textures, the lovely GLSL mod updated, optifine, and season + weather cycles... this game, is not only going to BE huge, but it's finally going to FEEL huge. Anyways, I imagine that having 6 total layers of compression or more could triple the save file size, and since minecraft is constantly writing to disk, that might slow down chunk unloading, so there's a sweet spot in there, probably at about 3 levels of compression: normal (16 pixels per block), far (1 pixel per block), and very far (1 pixel per chunk). With some tactical layering of rendered spaces, and appropriately optimized fog, that could probably look nice and smooth, and I imagine it would actually require something like the optifines code to get down to a reasonable fps for a lot of computers.
2.
Yeah; the issue is not a matter of what any one person thinks is excessive, as there are people who WILL find a use for the space (Space mods etc), but instead what the cost/benefit ratio effect will be on the coding and world file sizes. The jump from 4096 to 65504 was, according to Robinton, a fairly trivial thing to do and should have no overall negative impact on the game's performance. So since there are no truly tangible negatives to allowing a 65504 block/meter vertical space there is not only no reason to not have it but every reason to have it even if only one person wants it, and they do.
Even the 4.2 billion vertical limit only raises the save file sizes by around 20%, and considering that he recently reduced the save file size of one world from approx 600mb down to 21mb with a redo of his save-file system, I suspect people could deal with that same file being 25mb instead. :wink.gif: - Even so; he has told me that a 4.2 billion size is not a top priority for him right now compared to other features. I've thrown out the idea to him that after everything else is done with the mod that he could release a "Cubic Chunks XT" version of the mod, or something like that, which would give people a 4.2 billion space if they want it, allowing others to just use the 64k version with slightly smaller saves. This wouldn't interfere with the development of the main mod.
3 dimensional chunks, gotta love it. :3
I had no idea it worked so smoothly, but I can't really imagine what the hang up would be considering how chunks load into memory and then hdd, so that makes sense.
Also I had not even considered the possibility of a world server as massive as a space scenario. something of that nature could plausibly require a special rewrite of its own to optimize for a high prevalence of empty space to keep save file sizes down, but it's a very novel concept.
3.
It may not even be possible to raise the Block ID limit to 4096 anyway without major hacking, but he will find out one way or the other. I suspect that Robinton will actually raise it to whatever figure is reasonably doable without having to completely rewrite the game engine and cause a bunch of bugs and spend too much time on it.. :wink.gif:
People involved with other mods have asked him to do this, and there is a very good reason. Raising the ID limit isn't even so much about actually using that many blocks all at once on a single install as much as it is to help insure that the largest possible number of mods will be able to be automatically compatible with each other on the common CC base in regards to block ID's and having different ones.
Though when you see things like YogBox, there's no real way to predict how many block-ID's may be needed at one time by some people someday, better to make it possible now than later. If using that many mods at once slows a persons computer down too much they will always have the option to either not add so many or get a faster computer. Either way it will be their choice.
The Cubic Chunks Height Mod is a very Core type of mod that will become a central requirement for compatibility for many people in times to come, if they want to play in a higher world, and so there will be many different mods using many of those ID's that would be guaranteed to conflict with the standard Block ID limit. If we're really lucky maybe we'll see a limit upgrade directly from Mojang before or by the November release, considering the Developer program opening up and all. :wink.gif:
Well, at 4096, we are talking a significant increase in the bits required to store the data in memory, so even if they are unused, the hard limit change could cause the game to become unwieldy in memory without some sort of pre-load block ID listing system stored in a sort of reference list in the memory to keep it at a reasonably small bit space, which, for all I know, is actually how it already works, but I imagine it would slow the bus calculation of all block IDs because of the extra time taken to i/o in a cycle through the bottleneck instead of keeping it as a straight back and forth 1 i/o to processor and back. Gah, where are memristors when we need them haha. That being said, I'm merely snatching at ideas, I'm not terribly familiar with the actual details of the minecraft code in that regard :3
4.
Yeah, this has been brought up before, I'd love to hear his ideas on this too! :smile.gif: Though there might be a legitimate fight with people who would NOT want to lose the 8:1 distance benefit we have by using the nether. I have proposed though, and others have done similarly since, that with as much space as there is now that there could be other "pocket" realms and such deep underground as well as on sky islands or "moons" really far up, even with the capacity for varying gravity as he has already shown can be done. :smile.gif:
At this time, from things he's said, it sounds like he will leave that for other mods to add. He's even supplied the ICubePopulator code to assist other modders in adding things to a Cubic World including plug-in terrain generators that only affect certain levels. Personally I am really looking forward to these sorts of things being addable on top of CC. :smile.gif: "Lost-World" types of mega-pockets a few thousands blocks down and Moonlets waay up. :biggrin.gif:
I am excited for locational terrain generation as a concept, and I think for the most part a decent amount of people aren't even aware there is a 1:8 ratio because it just doesn't seem very significant and portal placement is fairly erratic. I liked the idea of the nether for fast travel, but in reality I've never really used it for that, because it's just not very good for it. It should have a more appropriate 1:16 ratio, where each chunk in the real world correponds to a block in the nether, but since it doesn't, I say kill it anyways and render the nether biome in a layer a hundred blocks below where bedrock typically is, and fill the area in between with magma and obsidian and the occasional tunnel (he should see about implementing mods by regions in the map, such as mods being initially loaded, immediately disabled in regards to function, and then re-enabled at certain height parameters).
http://notch.tumblr.com/post/123343045/my-vision-for-survival (follow this link if you need proof)
edit: also the glowing mushrooms are coming along
-it's a flower not a mushroom, so it can't grow on stone-make an item from it-it needs to be edible
-it needs to apply a "glow" buff to the player when eaten
-textures while holding need to be updated
-i need to configure the generation to CC
@wintermuet:
1. I completely agree with how huge an effect having a true horizon of some sort will have on the game. :smile.gif: I had been thinking along the exact same lines regarding compressed chunks, though I didn't have a name for it :wink.gif:, for months before finding this Mod. That's part of what really caught my attention when Nocte first pointed the Cubic Chunks Mod out in another thread and I saw his to do list. You might find this post interesting. :wink.gif:
2. I think that 3D Chunks worlds already deal with empty space "air" like that, but I could be wrong about how the World Save would work if there were a "Moon" a ways up and you traveled to it. I like to think that all the emptiness in between would not require any World Save space to be saved. Robinton, any insights on that? btw: You might also find this interesting. :wink.gif:
3. Ok, that's something I just wouldn't know about. If it were to have a big slow-down effect on this game for people then more thought and experimentation might need to be done at that time on where the balancing value point would be for that. I would personally want the effect to actually be tested though to know for certain. :wink.gif:
4. The Glowstone and the rapid transit are the two main reasons I have for going down there at this point. :tongue.gif: Somewhere in this thread I did make a case for integrating the Nether though, then someone else reminded me about the 8:1 issue and Robinton said he would leave something like that to other modders. Currently, at least when this mod was 4096, he has a deep "ocean" of lava at the bottom of the map. Here's Robinton scuba-diving in the lava at the core. :wink.gif:
And just to show my sincerity, here's one of the statements I made about the Nether in CC a while ago:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
Nice! :biggrin.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
If you need any help with textures, I've got a knack for these sort of things, :3
Here's some suggestions, if you don't mind me giving them:
Use a slightly more darker color around the edges of the mushroom, and a whiter glow coloration towards the center, and give the whole thing a tiny pump of yellow, because right now it seems to look a little bit odd. I love the idea though, and so far the sprite does look good.
http://notch.tumblr.com/post/123343045/my-vision-for-survival (follow this link if you need proof)
ty, I havn't put a ton of time into it the textures (as they're easy to change at any time), and I was more focused on them existing than how they look :smile.gif: i'm looking into making them edible now, and then applying a buff, and then making the buff. so if you want to mess with the texture's colors you're welcome here's mine ((
1. My initial thought (which I could change, if I saw a better alternative that I still had a hope of successfully implementing) was to figure out which block, at which brightness, would be most seen from each face of each 16X16X16 ChunkCube. Then render the ChunkCube as a single block, with each face's texture and brightness determined by the most-seen algorithm. This would result in a memory / hard-disk usage of about 8-10 bytes per ChunkCube (each ChunkCube is around 10000 bytes uncompressed), and 1 draw call per appx. 100 uncompressed.
Fundamental drawback to my idea is that it looks blocky, and might not reduce lag quite as much as it should.
Fundamental drawback to your idea is that I don't have the graphics and rendering experience to implement it. My experience is with chunks.
2. I definitely see your point. I'm currently using 65,000+ because it is probably larger than anyone will ever use, yet the y-axis still just barely fits within the limit of the "short" data type.
I don't see any point in limiting others to +-2048, when I can (with almost no overhead) extend it to +-32,000. I don't see many uses for the extra space, either, but give them space, and sooner or later someone will use it.
3. I picked 4096 as a possible limit because it would use exactly 1.5 bytes to store the BlockType. The current 256 limit uses exactly 1 byte to store the BlockType. For each block in the world (ignoring air ChunkCubes), Minecraft must store 2.5 bytes: 1 byte for blockID, 0.5 bytes for MetaData, 0.5 bytes for SkyLight, and 0.5 bytes for BlockLight. Thus, allowing up to 4096 blockIDs would actually only be a 1/5 or 20% increase in save size.
4. It could be done. Chief complications would include: in the Nether, absolute darkness isn't as dark as in the Overworld; skylight isn't calculated in the Nether, this is a definite optimization; the terrain Generator would need to be dramatically re-written; spawning code would need to be re-written. EDIT: and, oh, yes, the 8:1 NetherTravel effect.
I'd have to hardcode the Nether height limit (or at least the existence of this limit) into several functions. It wouldn't be easy, but it could be done.
Also, from the later post, cool idea about height-enabled mods.
@MineCrak: You are correct. All of the intervening ChunkCubes would be air and therefore never saved.
@MarcoPolo1613: Keep up the good work.
Sorry anyone I missed; the more time I post, the less I code.
Oh, and my quarry is acting strangely: whenever I play around the top of it for a while, then walk down into it, I see a bunch of sheep and pigs that had been suspended in midair fall to the ground and die.
I just made some save-fixes, and tested the Minecart replication bug. I ended up writing myself a stairway-building hack (hacks are awesome :biggrin.gif: ). I tested several different combinations, and I couldn't find any problems. I'm pretty sure I fixed it. I'll release that and a few other fixes soon.
4.2 million km only goes that far? Robinton; you'll need to figure out how to up that to at least 200 million km if we're going to get at least the inner solar system on the same map running on your beowolf cluster...
:wink.gif: :biggrin.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
Please do, to everything you just said. :smile.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
anyways, a screen shot:
things to do:
-make edible
-add glow buff
-adjust mushroom spawns for CC
- fix textures on mushrooms
- maybe make the gel glow (not sure if i can)
milk/bread/HeadNow then... anyone got an estimate of how long it'd take to dig straight down to the core? 65000 blocks? a guess, anyone?
Tehe... eh... well... if we go over that, we may as well include the closest star, Proxima Centauri, as well... lol.
Looking good!
That... is just Robinton being amusing. He added an invulnerable mob to make it look like he's keeping an eye on ya. It spawns randomly, but only occasionally, and only one at a time. It's invincible to every form of attack and if you try to bash him directly, he'll set you on fire (even if you shoot arrows at him). He can breathe underwater and is flame-proof (you can set him afire, but if he moves outside the source flame, he goes out). Ignore him if you can. Attack him at your peril.
Donate to help me buy people Minecraft accounts!
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod