Minecraft Forums

I'm curious; will you be having negative y coordinates like the original mod did or will the map always bottom out at y=0?

For reference: The mod started with a 4096 range (-2048 to +2048) and ended up with a 64k range (-32k to +32k) the next version (that didn't happen) was going to bump up to a 4 million km vertical range.

One thing that allowing a negative y coordinate enabled was easy creation and even auto-converting of vanilla worlds into Cubic Chunks worlds while retaining the coordinate levels in those original worlds (ie y=64 in vanilla and in converted world too) while still giving that world incredible depths to work with. This way terrain didn't have to generate up to a great height to start with in order to enable potential great depth later. Also, when auto-converting vanilla worlds all bedrock between y=0 to 4 was converted to regular stone.

Also; for future consideration of how you might deal with the Nether later down the road: The version of Cubic Chunks for beta 1.8.1 had a cubic Nether that went 4 km up and down from y=0, with the 8 to 1 distance travel ratio working vertically in the same way as it currently does horizontally (4k x 8 = 32 km, the surface world vertical limit). I think there was still some work to do regarding lava-lag though, heh heh. The vanilla code is in many ways different now though so hopefully that lag-issue won't exist?

Just trying to help out with the old implementation info since it seems to be arcane knowledge at this point, heh heh. I understand that you will set things up in this project however you will, I'm just trying to help with info that may or may not be used anew but at least I'll know that you have it and can use it in your considerations.


[EDIT] At the same time; If we are starting fresh with this mod then the option also exists to do the following:

Have negative y (like exists for the other coordinates) as described above, but make y=0 be the default sea-level. That would make the "meaning" of height coordinates incredibly intuitive to everyone whether under or above ground. Then regarding auto-conversion you could auto-offset the coordinates of the vanilla world to sync the sea-levels to y=0.
[/EDIT]

Quote from MineCrak

In the mean-time you might enjoy inspiration from the 1:1 World Trade Center replica made by kantk2010 with the original Cubic Chunks Mod a long while back.

kantk2010's 1:1 Recreation of the original World Trade Center (requires Cubic Chunks Mod)

Nice, except my replica will be of the new World Trade Center currently being built.

Quote from McCuddlz

Nice, except my replica will be of the new World Trade Center currently being built.

Very nice! I look forward to seeing that and hopefully even walking through that map.

Fair enough. Question answered.

Quote from Cuchaz

I'm not implementing negative y coordinates. There is a lot of vanilla Minecraft code that assumes the world bottoms out at y=0. I'm not going to change that unless I absolutely have to. So far, I haven't had to do that. =)

Making world conversion easy isn't really a priority for me. I don't have any expectations that vanilla worlds and tall worlds will be interconvertable.

I'm planning to make surface level and sea level configurable. Players can decide how much underground space they want using those settings, but the world will always have bedrock at the bottom. It just makes my job easier.

Very nice! This means I can do the underground mall and basement levels of the towers!

please no million blocks down... unless this is configurable.

Quote from vyor21

please no million blocks down... unless this is configurable.

Here's your answer.

Quote from Cuchaz

--snip--

I'm planning to make surface level and sea level configurable. Players can decide how much underground space they want using those settings, but the world will always have bedrock at the bottom. It just makes my job easier.

woops, didn't see that!

Quote from Cuchaz

Honestly, I don't really care if Mojang implements cubic chunks or not. I just want to get this mod working so I can use it myself. I have plans that need tall worlds. =)

Please say that this is in some way related to airships

Quote from LastBlockOrg

this is exactly what I need for my mod pack / for forge since it uses forge :/ but dangit this doesn't use forge :/

my issue is I have come to a point that my 1.7.2 mod pack has 380 mods and the pack has so many mods that chunks start to freak out and in order to change the render even with optifine on you must crash and then do it / or do it before you play or else your screwed till you log out :/

anyways as you can see my mod pack has many issues (most are gone now :D)

but chunks are still an issue mostly because I have 2 sky dimensions that technically connect to the over world o.o sooo... yeah and only way to get that to work was by setting one sky dimension above the other sky dimension above the over world unless I could get the mod maker to make it not connected which wasn't going to happen.

having this in a simplified and customizable version for forge would still help some if you would want or maybe could do it im sorry if that's asking to much and sorry for rambling xD

As far as I know, this WILL be compatible with Forge eventually.

Cuchaz is making his own mod loader, and using it as the platform for this mod. It is called M3L, and you can read more about it here.

In a nutshell; it will be very functional, flexible, and compatible with Forge.

To put that nutshell in another slightly larger nutshell; Cubic Chunks should be compatible with most Forge mods, but sometimes poo gets smeared on the walls, and sometimes there's just not much you can do about it [in other words; compatibility issues will invariably arise here and there regardless of the modding library used].

For the end user, it's kind of like when you go to install a mod, and find that you need to install a library before installing the mod (like with NEI, you first need to install Code Chicken Core or w/e).

Quote from Cuchaz

I'm actually reconsidering having the bottom of the world be at y=0. It would really make a lot of sense to have the sea level at y=0. I'm going to see how much of Minecraft actually depends on y=0 being the bottom and think about what to do.

I was thinking about commenting and suggesting exactly this after it was discussed before. I think it would make the entire concept of altitude much more intuitive.

My guess is that you set the default world gen height to some really big number and realized that the numbers would just confuse the hell out of half the players who used the mod?

EDIT: I forgot to mention that you can double the vertical space if you allow negative y values :D, though I'm not sure how relevant that is, since you can already make a 1:1 scale replica of Earth with only 12-ish million blocks, and anything larger would need to get scaled anyway.

Quote from Cuchaz

That's one concern. The other concern is having to make configurable settings for surface height and water height, etc. That raises questions of how to even define a "surface height."

That's a good point. Hmmmm... I see the problem, I think.

Worst case scenario, I guess you could always work on the assumption that sea level is at y=0 while generating the terrain, but then stick the data into the chunks at y=8'000'000 instead...

Quote from Cuchaz

I'm looking through the code now and I'm not really seeing any huge barriers to having negative y cubes anymore. There used to be, but now that I'm using my completely new lighting engine, most of those barriers are gone. The only other big system that used that assumption was the biome system, but that's disabled right now for other incompatibility reasons. It's likely I'll have to rewrite that completely anyway.

By the way, allowing negative y cubes won't actually double the vertical space. I'll still have ~16mil total blocks, but now half can be above 0 and half can be below 0.

You can't go to ~±16'000'000? :'(

Public Static Void set_biome_at_position(x,z){

     biome_at_position[x][z] = random.nextInt(acceptable_biome_list.length());

}

Consider the biome problem solved ^^ (not 100% sure how Java handles 2d arrays :s)

Being serious now, is there some reason why you can't simply force the old system to apply a biome to each x/z coordinate? With my limited grasp of how MC does it's stuff, I would have thought that this would be a relatively simple solution (if not only temporary).