java.lang.AbstractMethodError: ok.provideCube(III)LChunkCube;
at fd.getChunkFromChunkCoords(World.java:395)
at fd.a(World.java:313)
at net.minecraft.client.Minecraft.d(Minecraft.java:1422)
at net.minecraft.client.Minecraft.a(Minecraft.java:1342)
at net.minecraft.client.Minecraft.a(Minecraft.java:1306)
at net.minecraft.client.Minecraft.a(Minecraft.java:1245)
at rq.e(SourceFile:158)
at mg.a(SourceFile:206)
at lg.a(SourceFile:164)
at rq.a(SourceFile:178)
at px.b(SourceFile:553)
at EntityRendererProxy.b(EntityRendererProxy.java:14)
at net.minecraft.client.Minecraft.run(Minecraft.java:514)
at java.lang.Thread.run(Thread.java:662)
--- END ERROR REPORT 9765ed61 ----------

@lahwran: did you overwrite ok.class (unobfuscated: ChunkProvider.java)? If you installed another mod on top of Cubic Chunks, or didn't copy all of the Cubic Chunks classes into your Minecraft.jar, that could cause this error. Also, if you didn't install ModLoader first, that might cause this problem.
I honestly don't have an irc.esper.net login. I had been thinking about getting one (if only for adding MCP deobfuscation names) and will consider it much more seriously now.

Everyone else: There is now a known tree generation bug. That will be my next task, but I will have to wait until tomorrow... Meanwhile, I just released a save format conversion tool. I haven't throroughly tested it, so BACK UP EVERYTHING, and send me any and all errors you find.

Awesome! in correct order, it seems to have worked. Very impressive! I've been meaning to do this for ages, and I'm hardly the only one. I'll bet you could get quite a lot of contributers if you set up a git or such with your code.

Here is the current generation code, the most glitchy, least improved, and most re-moddable part of Cubic Chunks. Feel free to modify it and post CC re-mods. :biggrin.gif: Do be aware: I'm in the middle of trying to add caves to y<0 ChunkCubes. Not all this code may work right in its current form... I will fix any problems next time I update.

So if I install the Disappearing SmoothStone mod, and I have a castle at the surface, and let's say I have a mountainside HQ that's made of about 60% smooth stone, then when I play the game, my castle is gone, paintings are floating where my castle used to be, my mountainside HQ is nearly inaccessible to get to, and it's mine could be in better shape.

Would that fit the bill of what would happen? (Not that I tried it. :laugh.gif: )

I will PM them now, but seeing as I have fewer posts than some people who have joined just days ago, it is not as likely they will listen to me. If anyone else would like to help that would be be appreciated too... MineCrak?

I will PM them now, but seeing as I have fewer posts than some people who have joined just days ago, it is not as likely they will listen to me. If anyone else would like to help that would be be appreciated too... MineCrak?

@F_Synchro: SMP support is definitely the hardest of the listed possibilities... but I'll try for it sooner than I would have given how many people want it.

@ElusiveHawk: yep, just about. Do mention the floating torches, too.

@Leaf_It: Phoenix Terrain Generator compatiblity would be awesome. I released my Generator code, so that should make compatibility easier.

@flying sheep: Wow, I'm on notch.tumblr.com! Yeah, I know CC has bugs, but it took me weeks to work through all of the bugs that I have worked through. So it will probably take Notch a while to do the same. Maybe I can get a licensing deal and save him the headache...

This is one the the greatest sets of mods I have ever seen! you deserve a job at Mojang!

Rollback Post to RevisionRollBack

Our posturings, our imagined self-importance, the delusion that we have some privileged position in the Universe, are challenged by this point of pale light. Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity, in all this vastness, there is no hint that help will come from elsewhere to save us from ourselves.

Well; right now notch is getting a LOT of bother from the twitter community regarding higher maps, heh heh. He still keeps throwing out old ideas/issues regarding height extension. Thankfully some of the tweets have been pointing out that the problems he mentions wouldn't exist or be the same with 3D chunks done right vs linear bottom to top chunks.

However; some of the things notch is saying right now make it sound like he is starting to become aware of this as a real issue, in other words, that there are a LOT of people who want it and NOW due to people like Robinton they will get it whether notch want's them to or not. It's encouraging to see that notch has shifted the code to make height level more easily changeable, but is it only more easily changeable for linear chunks? I doubt that it directly helps 3D Chunks any. But it's still a positive sign regarding notch's attitude towards the subject. Especially since he now says that level 128 is a Design decision and not a technical one. Hopefully this will finally shut everyone up who keeps talking about it being impossible because people falling would cause a tear in the space-time continuum or whatever. :wink.gif:

And notch clearly isn't kidding about 1.8 being easier to mod for height; at least with linear slow chunks, as soon after he talks about it he posts that picture of his terrain generator working with a 512 block high map with just a quick bitshift to the generator code. :smile.gif: The fact that he did this is fantastic news! Not only because it shows a shift in his attitude and openness regarding higher maps, but it is bringing this subject to the attention of sooo many more people! :biggrin.gif:

Exactly! Methinks that guy from Bat-Frog Entertainment is exaggerating QUITE a bit... Especially since he has decided he wants to make his own version of the same thing. So anything he says is going to be very biased... :sad.gif:

For one thing, there are really only four or five known bugs; there are just ten or so potential obvious improvements. The easier-height-modding v1.8 will probably both help and hurt me: there will be many changes to the code to integrate (this will be one painful mod update), but improving terrain generation will be much easier.

Also, "a tear in the space-time continuum". LOL! Hilarious way to put it! Even more hilarious that Vanilla Minecraft has code in place to prevent such a thing.

Hey, does anyone who has used ymod know what ymod map's height/depth limits are? I'm looking through the code, and sea level appears to still be 64, but I can't tell whether that gets changed after generation, or what...

Hey, does anyone who has used ymod know what ymod map's height/depth limits are? I'm looking through the code, and sea level appears to still be 64, but I can't tell whether that gets changed after generation, or what...

I believe its 512.

Rollback Post to RevisionRollBack

The Epic PortForwarder.Helping with any Minecraft server related issues via skype send me a message (Hepled 12 people so far)

Hey, does anyone who has used ymod know what ymod map's height/depth limits are? I'm looking through the code, and sea level appears to still be 64, but I can't tell whether that gets changed after generation, or what...

Default seems to be 512 and the rest of the terrain is default Minecraft terrain levels I think, unless you twiddle with settings in some file before making the map. The first version played around with "stretched" terrain features if those settings were used but the later versions dropped that.

** Ahh crud.. I can't believe no one ever pointed this out to me, I have to update my thread now, grrr.. ymod 0.1.5 for MC 1.2_02 was NOT the last version released!! yatima released ymod 0.1.9 for MC 1.3_01 just before falling off of the face of the earth, he just failed to update his OP and thread title...

Also; the 0.1.5 version doesn't have a readme in it... The 0.1 & 0.1.9 both have a readme in them. The first version 0.1 readme has the most info in it but everything about the stretched terrain generation was deprecated with the next version 0.1.5 .

* yatima2975 was going to release 0.2.0 but just stopped coming back...

ymod 0.1 Readme text (Info about the save file format at the end)

README for yMod v0.1
--------------------

This is a first release, so there will be bugs!

- What does this mod do?

It replaces the hardcoded maximum height of 128 by 256, 512 or 1024 (and possibly even bigger values but those I've not tested). Every maximum height value has 5 save directories of its own, so you don't accidentally use a save with an incompatible height. Optionally, the terrain generated by Minecraft is stretched up to get bigger mountains/hills/other stretched.

- What does this mod NOT do?

This mod does NOT convert old saves into the new format, but that's planned for the next version!
Multiplayer will NOT work in this version.
The Nether is untested but might work. Then again, it might not!
This mod also doesn't fundamentally change the way the terrain is generated, so you won't get nice looking vast mountains, just terrain scaled up into the air; be prepared for steep mountainsides! The stretching can lead to very weird things like flooded worlds and impossible mountains, so if you don't like it, turn it off and build your own mountains.

- Installation instructions:

Put the .class files in the zipfile into minecraft.jar, and delete the META-INF folder in the jar (as usual). Optionally, place scalePercentages.txt into the root of the .minecraft folder. See below for lots more info on what goes into this file.

Start minecraft, singleplayer and you'll see an empty directory with the new maximum height above it.

IF YOU STOP READING HERE, YOU'LL GET A MINECRAFT WITH A NORMAL WORLD, BUT A
HEIGHT LIMIT OF 512. THE CLOUDS WILL BE GONE, BECAUSE THEY'RE TOO HIGH UP...

Before starting the modded Minecraft, you can set the environment variable YLIMIT_EXTRA_BITS (on Windows XP this can be done via My Computer -> Properties -> Advanced -> Environment Variables, I don't know how works for other OSes, sorry!). The value of this variable should be a single digit from 0 to 9, and it controls how many times the old limit is multiplied by 2. Here's a table:

If you don't set the value it defaults to 2, for a maximum height of 512. For netbooks I recommend the value 1, while those with powerful computers and lots of patience can try 3. There's not much point in using 0 as that will not change anything, except for changing the savefile format in an incompatible way.

- New savefile location and format

Instead of world save folders World1 to World5, each maximum height get it's own 5 save folders, called World_128_1 to World_128_5, World_256_1 to World_256_5 and so on. This is done to make sure you only load and save worlds with the right height maximum. Be aware that this will confuse tools like InvEdit, so that you might have to rename these folders back and forth manually in order to use these tools. Map viewing and editing tools most likely will not work, since the save file format is changed!

- Stretching and the file scalePercentages.txt

In order to get some interesting to stuff to look at, I've implemented something called stretching, which enlarges the output of minecraft's terrain generator. Minecraft tends to generate a world full of dirt, stone and ores up to height 64, after which hills, trees and air tend to take over until 128. This mod offers two ways to make the generated world fill more of the new size: either the below-sea level stuff is enlarged, or the above-sea part is. (Both at the same time is also possible, but not in this version). Per 16x16 chunk you can give a number that determines how the stretching happens: -100 means the below-sea is stretched as far as it can while keeping the over-sea the same size, 0 means both stay the same size and +100 means the below-sea stays the same, while the over-sea gets stretched all the way. Numbers in between do something in between.

This sounds pretty complicated so here's an example. Let's say the maximum height is 512. If you did nothing, you'd have 512-64 = 448 blocks above sealevel. The terrain coming from minecraft only goes up to (about) 128 so you'd have 384 levels of totally empty space. Fine for builders, not fine for people who want bigger mountains. If we stretch the over-sea as far as it can go (which is by a factor of 448/64 = 7) we get mountains which potentially can go to 512, but every little bump becomes a 7-high wall. So if you scale 50% the factor is midway between 1x (doing nothing) and 7x (all the way) for a factor of 4 - that means the top of the generated blocks go to 64 + 64 * 4 = 320. (The first 64 is for the unchanged under-sea). 25% would mean scaling by 2.5 and 75% is 5.5 and so on.

Now, if you'd like the surface to stay more-or-less unchanged, you can also apply this to the under-sea level blocks. This tends to give a deeper world, where the surface is as normal, but the caves are bigger. (Note however, that ore distribution does not change, diamonds will still be just near the bottom).

A few values in a table, showing the effect of varying stretch %-ages for different maximum heights:

All this is controlled via a file scalePercentage.txt which should be in the root of the .minecraft folder. Lines starting with # and blank lines are ignored while lines containing numbers are interpreted as stretching percentages. To get more varied terrain, you can give rectangular grids of numbers which are smoothed a bit (to prevent super-steep walls) and applied repeating in the N-S and E-W directions. But if you put just one number, that's always applied to every chunk, and if the file is missing, nothing happens - no stretching is done.

Here's a couple of sample files:

This makes everything above sea level fill half the available space:

#START
50
#END

This makes everything under sea level fill half the available space:

#START
-50
#END

This one makes most of the world act normally, except every 8 chunks (that's 128 blocks) where there's a huge mountain. Replacing -50 by +50 enlarges the over-sea features so if there's a sea there, you won't see much.

Feel free to experiment, but be aware that this part of the mod will probably change a lot in later versions...
I have tried a bit to prevent water getting too high up and flooding the rest of the world, but I'm not 100% sure got it working perfectly. Be ready for surprises!

- New savefile format

(this section is *very* technical and mainly of interest to tool makers).

I've made the following changes to the format:

* In the level.dat file, an extra Integer field called YLimit is added, with the maximum height (256/512/etc) as its value. This is mainly there so you know how big the arrays in the chunks are going to be.

* In the per-chunk file, the following fields get enlarged by an appropriate amount: Blocks, Data, SkyLight and BlockLight. The format here stays the same, so you get a sequence of bytes/nibbles with fixed x and z, and y runs from 0 to the heightlimit in each.

* The field HeightMap is saved using a new NBT type, called NBTTagIntArray. It's code is 11, but otherwise it is analogous to the bytearray type (so first the length, and then the bytes, written out using Java's writeInt method).

If this is in anyway relevant to you, you might also be interested in the patch diff (also in the zipfile and called ylimit.patch), there you can find the gory details.

ymod 0.1.5 Release Text

v0.1.5 is an Intermediate bug fix release, this removes the stretching, fixes the lighting problem and makes a special chunk appear at (0,0).

ymod 0.1.9 Readme text

Installation: put the class files in the zip into minecraft.jar and remove the META-INF folder. Pay attention to the net/client/minecraft/Minecraft.class file, this needs to be replaced in the proper location!

@Nopunkt1: I think MineCrak's sig has a link to a installation tutorial.

@Solidfire: No, that is a known bug that I plan on releasing a fix for later today, along with auto-converted wool blocks changing color.

RE: YMod Height Question: does this mean bedrock is at 0, sea level is at 64, and sky limit is at 512? (I knew I should have been more specific!)

Future plans: I can get two important bugfixes (say, 2/5 of the BuxFix votes) and ymod compatiblity (1 vote) in one day of work, or SMP compatiblity (18 votes) in about three weeks (21 days). Much better rate to do the first two today, and leave SMP compatibility for the next three weeks.