Minecraft Forums

Quote from Hackaholic5069»

sorry about the necropost, but slime chunks arent addressed in the original post. how do slime chunks work in cubic worlds?

In the current implementation of the mod they work on columns, just like in vanilla. But there is no reason to not change it.

Quote from erykus»

(...)

I'm also just curious as to how Extreme reactors might stop working. The mod itself doesn't matter, but I can understand why it presents a bit of a challenge for cubic chunks. Basically if the reactor is 176 blocks tall (not likely, but let's assume), or even if you're up high and just a small reactor goes over some y chunk borders, and chunk render radius is set to 10, then there's an issue with the multi-block structure. Is that correct? (I'm wondering why the y-axis here would present a different issue instead of say a reactor crossing a few x/z-axes with chunk render radius set to 2 or something).

Is a band-aid for this something like

• The extreme reactors mod checking if a player is in rendering range of certain block type
• Checking if that block type borders a chunk border
• If yes, load the chunk where the block borders another chunk, up to a limit of +/-256 blocks along the global y-axis from the origin point.
• Loop the process until limit is reached or no more bordering blocks are found
• If no more bordering blocks were found, then start loading the internals of the reactor?

I realize a big part of the answer is: I don't know because I didn't code that mod.

Obviously I have no idea about the performance implications, but I'm just wondering if that would theoretically fix such an issue or not.

The reason it stops working, is an implementation detail in the multiblock handling library the mod author made.

Because {some handwavy explanation about some issues} the mod for some reason can't use a method within TileEntity called when it gets loaded to initialize itself, and check if the multiblock is valid.

Instead it listens to world global chunk load event, and every time a chunk is loaded, it looks at all the tile entities in that chunk, and tries to keep track of the state of it's own multiblock structures this way. And this breaks because after that, it never re-checks that the multiblock is valid, so if it doesn't get it right on chunk load, it will stay inactive.

The big problem here is that the forge chunk load event is more or less meaningless within a cubic chunks world. The reason is the way cubic chunks achieves any reasonable mod compatibility at all: virtualizing vanilla Chunk. Normally, a Chunk object contains constant, 16 of 16x16x16 sections, an they are all loaded at once. Chunk has various methods to access blocks etc...

Instead of adding a third coordinate directly to Chunk object, cubic chunks makes the chunk look like it's effectively infinite in height, with parts of it getting dynamically loaded and unloaded.

So a "Chunk being loaded" really means that an empty chunk object has been created, without any cubes in it yet. So when ZeroCore is trying to list the tile entities there, it sees none of them. CubicChunks still correctly calls the TileEntity onLoad method, but because the mod sees the corresponding chunk load event long before the tile entity exists, it never adds it to it's internal structures, and never activates it.

And I can't fire another chunk load event every time a cube is loaded, because that is very likely to break other mods. And a chunk load event has no data about Y coordinate.

I know for a fact that ZeroCore WILL work fine if I re-fire the chunk load event on every cube load, but again, this is not something I want to do to avoid potentially breaking other mods (chunk load event can be used in a way that is compatible with cubic chunks)

Actaually, WorldEdit is getting closer to being compatible with cubic chunks. The most recent builds should work above y=256, there is a test build that works below y=0, and there are plans to make all of WorldEdit work correctly with cubic chunks.

Currently this mos is alpha version. All by itself it has some known issues. Mod compatiblity could be better.

A lot of it is likely to change in future Minecraft versions. 1.13.2 should be a big step for world generation compatibility. While progress on mod compatibility is slow, more mods become compatible over time. Eventually there may be time when you can just put cubic chunks into an average modpack and it will work.

Right now if you want a modpack with cubic chunks, you really have to design around it, and avoid mods that cause issues.

Quote from redngb»

Hey, Great work on this mod!

I just wondered is there a way to make this mod compatible with world edit?

so i can use world edit to build above 256, thanks in advance!

No. WorldEdit limits itself to 0-255 height range, and there is nothing this mod can do about it. Bur Orbis mod has similar features and works with any height .

Read description.

And ok, I won't post anything like that again. But unfortunately original sources of these files are long gone and this kind of things are the only thing that remains. There IS no official source anymore. I wouldn't have linked something like this if there was a known good source. But in general, there isn't.

I may still have backups of such old stuff somewhere, but if I still have it, I will only have access to that in about a month. I would suggest trying to find some old pre-made craftbukkit server files for beta 1.7.3 that have been available around that time. They usually had a lot of different plugins, and sometimes came with some custom GUI. Most of the MediaFire links still work, so you should be able to find something. Just one I found on youtube from 2016 has Towny, iConomy, WorldEdit and WorldGuard, and many others (I hope it's ok to link it, but here [removed], added a space so that MCForum wouldn't show it as youtube video).

WorldEdit 4.6 (which by looking at release date, should be for beta 1.7.3) is available on dev.bukkit page. And a lot of old plugins should still be there. And worldedit 4.7 which is for newer craftbukkit may just work with the older version. A lot of the plugins were also open source even back then, so with some effort it may be possible to compile old versions from source (even if it may not be easy)

Quote from TheMasterCaver»

Mods need to be rewritten in order to generate outside of the ranges hardcoded into them; for example, this is how vanilla sets the coordinates of a cave, which results in a random starting altitude from 0-126 being chosen (the distribution is nonlinear; even just increasing the ground depth to 128 won't really work well since only 1/6 of all caves generate above normal sea level):

double x = (double)(chunkX * 16 + this.rand.nextInt(16));
double y = (double)this.rand.nextInt(this.rand.nextInt(120) + 8);
double z = (double)(chunkZ * 16 + this.rand.nextInt(16));

To get around this, Cubic Chunks replaces vanilla world generators with custom ones, including ones that can work with cubic chunks (among other things, the cave generator works by scanning a +/-8 chunk radius to "follow" any caves that start within that area so it can carve out the middle chunk if any intersect it. This presents a major issue if you make the height effectively infinite, as this also means that an effectively infinite number of caves can start in any chunk column along the y-axis - you also have to split the range up vertically, so now it checks a 17x17x17 cube of cubic chunks, which still presents an issue since you need to perform 17 times the checking of a 17x17 area). Plus, the vanilla cave generator (and most modded derivatives) actually works with an array (instead of accessing chunks in the normal manner), which is assumed to be 16x256x16 in size, which needs to be 16x16x16 instead:

/** The number of Chunks to gen-check in any given direction. */
protected int range = 8;

public void generate(IChunkProvider par1IChunkProvider, World par2World, int par3, int par4, byte[] par5ArrayOfByte)
{
    int var6 = this.range;
    this.worldObj = par2World;
    this.rand.setSeed(par2World.getSeed());
    long var7 = this.rand.nextLong();
    long var9 = this.rand.nextLong();

    for (int var11 = par3 - var6; var11 <= par3 + var6; ++var11)
    {
        for (int var12 = par4 - var6; var12 <= par4 + var6; ++var12)
        {
            long var13 = (long)var11 * var7;
            long var15 = (long)var12 * var9;
            this.rand.setSeed(var13 ^ var15 ^ par2World.getSeed());
            this.recursiveGenerate(par2World, var11, var12, par3, par4, par5ArrayOfByte);
        }
    }
}

I actually didn't notice that vanilla cave distribution is nonlinear until now! This explains so much about why it "feels" different, with seemingly less caves, despite there being technically the same amount of them. Thanks for bringing it up. I guess I never noticed the nested use of random, so I basically did this to choose where to generate caves: https://github.com/OpenCubicChunks/CubicWorldGen/blob/f404a7e79036438b3b10053a329b9e13bd850a7f/src/main/java/io/github/opencubicchunks/cubicchunks/cubicgen/customcubic/structure/CubicCaveGenerator.java#L163-L165. This has been an issue for about 2-3 years now! So there another option that is going to be added to CWG.

And cubic chunks actually does one more trick to make cave generation faster: cave generation is in a way done on 32x32x32-blocks chunk scale. While each 16x16x16 chunk is generated individually, caves can only start in 32x32x32 chunk sections, which reduces the amount of work to do by 8 almost 8 times in case there aren't a lot of caves (see: https://github.com/OpenCubicChunks/CubicWorldGen/blob/f404a7e79036438b3b10053a329b9e13bd850a7f/src/main/java/io/github/opencubicchunks/cubicchunks/cubicgen/customcubic/structure/CubicStructureGenerator.java#L72-L110)

The base cubic chunks mod also doesn't actually replace any vanilla worldgen and just invokes vanilla generator, and splits the result into 16x16x16 chunk sections (which is trivial because vanilla mostly does that for me, I just have to put it into Cubes instead of Chunks). The actual cubic chunks generation is done by CubicWorldGen.

And as I said, this has the issue that nothing useful generates beyond vanilla height range. And currently there is no workaround for that.

But for a long time I'm planning to make CubicWorldGen be able to take over generation beyond vanilla height range. This is technically easy to do but also very hard to do in general enough way that is also controllable by the user (where do you even put a GUI to control that? Also you would probably want to make it an option saved with the world. Where do you store the generator settings of the other generator? Because now you have 2 generators, each with it's own settings. How exactly do you expose that in API without breaking compatibility?)

Quote from ThunderBolt6»

oh, so yes it generates caves downwards passing y=0? i haved worleys caves in, so passing y=0 only generates stone, but i still dont have ores, only stone.

what i can do?

yes, extending ore/cave gen downwards will work for me, but as i said above , no ore and no cave gen passing y=0(worleys caves on the modpack, so maybe thats a problem)

Thee way it currently works is that there are 2 "modes": compatibility and cubic chunks world type.

Compatibility mode will let you use any vanilla generator, but nothing really useful will generate beyond vanilla height range. And this is what is used when you enable cubic chunks in default world type.

The other mode is actual cubic chunks world type. CubicWorldGen provides 2 such world types: CustomCubic (equivalent of vanilla CUSTOMIZED world type) and FlatCubic, equivalent of vanilla superflat. These generators have all the features at any height, but almost nothing from mods will generate there, and some features are still missing.

There are plans to add "mixed mode" where it would use compatibility generator for vanilla height range, and a real cubic chunks generator outside of that range.

For the parts outside of vanilla height range it would still have all the downsides of the generator used there (including no modded stuff there) but vanilla height range would have everything as normal.

Quote from alex123456»

Hei man, great work seriously! It is sad that this thread doesnt get more attention you certainly deserve it. You are doing something that has never been done before and i hope you can finish through with it. I am working on a mod and i want it to be fully compatible with your mod, if you finish up could you make a small list of things that need to be watched out for in order to make mods fully compatible with your mod? If this mod finishes it could be a much needed game changer and should wake up Microsoft and Mojang(because modders do more than the devs).

Also one thing, dont cubic chungs tend to break lighting? like a big cave that is out of render distance would let light flow in right? Do you have any possibile ways of fixing this? leaving blocks in a pseude rendered state where they just block the light? just curious.

For compatibility, most of it is obvious things. Like "don't assume world height 0-256". If you don't see how some part of code could work with heights below y=0 or with cubic chunks in general, it most likely doesn't. There is also a bit of (partially outdated but still relavant) information on wiki pages on github.

Lighting:

First the way it's intended to work, and the core parts needed fo it are there and working: Lighting is based on any parts of terrain that have ever been generated in a given world. If you spawn at the bottom of a huge cave and the top isn't generated, it will be fully lit. The moment you generate the top of the cave, it should become dark.

The way it currently is: height tracking for it works correctly, but keeping track of where lighting needs to be recalculated isn't finished. To work around it, cubic chunks will, by default, choose one (kind of) random loaded block from 16x16 column per tick, and update lighting in it. This ensures that even if initially lighting is broken, it will fix itself over time (even if it takes very long time).

Currently height tracking also tends to use a good chunk of memory, and more memory the more vertical space is generated. This will be fixed eventually, but it's not very high priority as the overhead isn't too unreasonable in common cases. You should be able to keep everything within the default 1GB of RAM assigned with default view distance.

Quote from tnho05»

I can't load Minecraft with the cubic chunks mod.

It always crashes before it can even load

mods I used:

CubicChunks-1.12.2-0.0.902.0-SNAPSHOT-all

CubicWorldGen-1.12.2-0.0.33.0-SNAPSHOT-all

OptiFine_1.12.2_HD_U_C5

WorldEdit-1.12

Forge version 1.12.2-forge1.12.2-14.23.0.2491

Use OptiFine E2. And you are probably going to need newer forge too.

Quote from vetador»

I tried with a new world and I ran a few chunks until I find a chunk where I can't jump as described above. Also when falling in these *failed chunk* I'm falling very slow like having a low gravity.

Again, any other mods?Forge version? Cubic chunks version? Can you also pose the log? Ideally come to my discord server so that we can figure out what is wrong. This looks like a major bug but noone else seems to have that issue.

Quote from vetador»

In somes chunks I can't jump as if there was a wall above me. It happens very often after loading a chunk. It's just unplayable.

Do you have any other mods? Which forge version? Which cubic chunks version?

The mod is now finally on CurseForge! And updated the description with links to it. Joining discord to download it shouldn't be needed anymore.

Not all bugs have been fixed, lighting issues and performance issues still do exist, but I made a lot of progress. The mod is much more stable overall, there have been some compatibility fixes, and the world generator is a completely separate mod now. CubicChunks also has an API now that other mods can use.

Minecraft 1.13 update will take a while, because it's a big update with a lot of changes affecting cubic chunks.It will also be a long time until forge stabilizes, but the main issue with beginning an update is that mixin doesn't work with Forge 1.13 yet.

I'm not sure if it's caused by some other mod (especially cubic chunks that we are testing on server, xareo's minimap is the least broken minimap mod there) but sometimes when switching dimensions xareo's minimap crashes with this exception: https://pastebin.com/raw/jPJGEUMt

Quote from Skill117»

Hey, you can take my Code for Advanced World settings, it includes Cave, Ravine, Village and Mineshaft Rates/Sizes