Incredibly minor and far from being a priority to look at, but players should only be allowed to spawn in on #minecraft:valid_sapwn blocks, which are not obstructed by anything solid. Despite this, the player often spawns inside of leaves:

magic

1.14 rewrote lighting to allow for directional opacity of blocks. While this is completely fine within reasonable distances, it completely breaks beyond 33554432 blocks on the X and Z axes:

For the Y axis, it breaks beyond 2048:

And with cubic chunks, this still holds true, if a bit differently:

So in order for lighting to work correctly at any depth/height (or outwards distance for OpenCubicChunks/CubicChunks#535) block lighting might need some serious rewriting. (An absurd ask: maybe this rewrite could also implement coloured lighting on the side? After all, the 1.7.10 coloured light mod (CptSpaceToaster/CptsModdingLight#58) is in need of someone to maintain it, so it being merged into CC and continued with it with the necessary lighting fixes for CC would be fantastic.)

Bug tracker ticket: https://bugs.mojang.com/browse/MC-221891

A vanilla limitation that doesn't really make much sense with this mod considering that CC will almost certaintly allow for terrain to generate up this high/blocks to be placed at this height in the future.

It shouldn't be necessary

Currently there are 0 protections in place that prevent launching a world with a different packed blockpos long.

Vanilla handles them differently, do we need to do that too?

Currently the world will be broken, once the save format is implemented correctly it will just take much longer to load the world as it converts the cube size.

1.17 Fabric Cubic Chunks compatibility reports

What is this place?

This is a place where you can report compatibility status of mods. Both compatibility issues and information about compatible mods are welcome here.
Don't be discouraged to report information about mods that have been already reported, but with older version of cubic chunks, fabric or the mod. It is useful to know that an issue is still relevant after updates. Duplicated reports will be merged into one for a given mod and then deleted to keep this place reasonably easy to navigate and search. It is expected that your specific comment here will be deleted and it's content moved.
Mods that work should also be reported, even if it looks like mods of the reports are about incompatibilities.

Off-topic messages will be deleted. This is not a place for discussion.

What to avoid?

• Avoid posting compatibility reports with modpacks, including self-made modpacks, unless an issue can't be reproduced after removing any of the mods. The less mods involved, the easier it is for other people to find an issue and potentially to fix it. If you want help with modpacks, consider asking on our discord server.

• Avoid reporting issues with outdated versions of mods, always test with their latest version(at the time of writing)

What information to include?

A minimal report should include

• Cubic Chunks version
• Mod(s) version
• Fabric version
• Fabric API version
• What works and what doesn't
• Crash report w/ said mod (in an isolated environment with only CC & said mod preferably).

While the above should be enough, try to provide as much information as you can.

Periodically, information about mods may be moved to compatibility table below.

The current implementation is completely wrong and returns a center cube instead

Version Information

Minecraft version: 1.17 (21w14a)
Forge version: (N/A, Fabric Loader 0.11.3)
Other mods (if applicable): Fabric API 0.32.7+1.17

Steps to reproduce:

1. Load into a new world
2. Teleport beneath approximately -2.1 million on the Y axis
3. Observe an ArrayIndexOutOfBoundsException in the generated crash log.

Expected Behavior:
The cube would load.

Actual Behavior:
After attempting to load the cube for a bit the game crashes, apparently due to an issue with Aquifer water level calculations.

Link to crash log (if applicable - use a site such as hastebin: https://paste.ee/p/GvANh

Would that work?

Initial impl idea:
scale 0 heightmap to be saved in cubes
max scale heightmap to be saves in columns
other scales to be saved in combined region file for all of them

After thinking this through a little more I've realised there are some major difficulties in loading a world with a smaller cube size than the one currently selected (upscaling).

I believe our original approach was to save the world as it's current cube size, and on loading it back if the cube size doesn't match the world will be converted (either entirely, or on the fly). The major problem is that of missing cubes. Given this cube to upscale:

You would first have to generate the missing sub-cube, and then convert it to the larger cube size. However, as the cube generation works entirely through a flag that changes Mixins, it isn't possible to generate cubes of different sizes at the same time.

Which leaves a few options:

• Generate the entire cube again, overwriting it with the already existing sub-cubes
• Have an entirely separate cube generation pipeline for variable cubesize generation
• Not allow players to upscale worlds

currently vanilla doesn't allow custom dimensions to have areas above y=2031 or below y=-2032 buildable in, regardless of what the opposite limit is set to. I suspect this is due to vanilla's lighting engine breaking down outside of those bounds but as CC plans to fix that this should no longer be an issue.

Maybe a custom aquifer implementation?

Currently we are using the same name as horizontal render distance

comments of OpenCubicChunks/CubicChunks#479 - "Will be needed for 1.14+"

Requires fixing all vanilla features and their placement

As of commit df044b on branch MC_1.17_lighting, server side load order appears to be fixed. This is due to fixing several issues regarding the chains of futures controlling dependencies between world generation stages. I was not able to find any load order related issues on the server-side.

However, client load order remains an issue. Cubes are sent to the client without their chunks having been sent first. One result is entities appearing in non-existing chunks. The cause of this is that the stages border, ticking and entity ticking are not part of the dependency chains used during world generation. They are entirely independent. A cube transitioning into any of these three stages is not dependent on its chunks having reached the new stage first. As cubes are available to being sent to the client as soon as they reach entity ticking, cubes may be sent ahead of their chunks. This issue appears not to be game-breaking but it is an issue nonetheless.

The most relevant method to this issue is ChunkHolder.updateFutures. We copy this method using ASM and do not modify it any further. Thus cubes and chunks are processed independently from each other causing the current issue.

This will allow to implement accessor for sections arrays in ChunkAccess, and with some ASM transformations, reduce code duplication. Cubes would have a reference to that array and their assigned index.

Is it possible to do it in less invasive way?

Currently applies cubic chunks logic unconditionally

Why does it even use section pos?

Problem
Currently, tens of thousands CompletableFutures are being created during terrain generation. Terrain generation is split up into several stages (i.e. terrain, lighting, features, ...) When a cube is generated, other cubes in its neighbourhood are required to be at certain stages during their respective generation, such that all of the information for the requested cube to be generated is present.

In Vanilla 1.15. chains of CompletableFuture are used to represent these dependencies. Due to CubicChunks introducing the 3rd dimension, these chains grow to contain tens of thousands of CompletableFutures, hog up memory and slow down the system.

Possible Solution
It might be possible to replace the entire CompletableFuture system with a map keeping track of the stage of each cube. ("HashMap<CubePos, StageTracker>"). The "StageTracker" is a small object containing a reference to the Cube's current stage and allow subscribers to listen for the cube reaching a given stage.

Issue

World generation is split into multiple stages. These include determining biomes, generating noise for the terrain, carving caves and rivers, or placing structures. In general each cube is generated by itself and moves through the different stages. However, some stages require information from neighbouring cubes to produce satisfying results. A simple example is placing structures across multiple cubes.

Vanilla Minecraft already has a dependency system in place to deal with this problem along the horizontal axis. Each stage has a well defined task margin. This margin defines the radius of cubes around the current cube, that are needed to progress the current cube to the next stage. For example, generating features has a task margin of 8, meaning that in a radius of 8 cubes around the current cube, all cubes must exist and be in the stage prior to features. This way, the feature generator can reference the neighbouring cubes and rely on their data.

Surface and liquid carvers do not have a task margin in Vanilla Minecraft as they do not depend on neighbouring chunks horizontally. They do however depend on information above the current cube. When a carver is executed it references noise up to 8 blocks above the current cube to determine if there exists a cave or some other carved feature that needs to be extended downwards. We thus need a system to provide these additional 8 block layers to the carvers.

Possible Solutions

Increasing the task margin for carvers

Increasing the task margin for carvers would result in all neighbouring cubes being present and containing block information. However, the cube above the current cube could be in a later stage. Thus blocks might have changed since the noise stage. This could lead to carvers using information different to what they expect from Vanilla Minecraft.

Generating noise on demand

Whenever a carver is being executed, we can generate the necessary 8 block layers of noise just in time and present them to the carver. This approach does work, but it results in some noise being generated twice. Given a cube size of 32³ blocks, it results in a 25% increase of noise to be generated, as the bottom 8 layers of each cube are calculated twice.

Caching noise and generating it on demand

To avoid the 25% computational penalty from generating noise on demand, we could cache the required noise data from the original noise calculation. When a new cube is generated, its block array is filled with noise information. We could stash the bottom 8 layers of this information separately. This copy would not be affected by the cube reaching later stages of generation and could thus safely be used for running carvers for the cube underneath it. The cache would effectively duplicate the bottom 8 block layers of each cube. Thus we must ensure that this cache is removed as soon as possible. This could happen as soon as the cube underneath has finished its carver stages.

Currently lighting information is being sent from the server to the client correctly, but the information itself is completely wrong.

Vanilla lighting assumes that an entire column is loaded before lighting is done, which is of course flawed for CC.

Will most likely require an entire rewrite of the skylight system (both SkyLightStorage and SkyLightEngine)

Requires OpenCubicChunks/CubicChunks#519 to be implemented first.

Should allow cube sizes such as 64x32x64 as possible options.

(Beta) Currently we have no support for hybrid worlds

Bug tracker ticket: https://bugs.mojang.com/browse/MC-221890

Maybe limit to vertical view distance?