Overwiew

This mod is a Forge port and a continuation of Cuchaz's Tall Worlds Mod, and also a successor of Robinton's Cubic Chunks mod. This fork of TWM has been in development for over a year, and it's still not ready for a beta release. I decided to created this thread anyway because people asked the same questions over and over again in TWM thread.

More information, and how it works?

The goal is to increase the world height and depth, without making the game too slow. This mod attempts to do that not by making chunks taller (like many earlier attempts), but by making them smaller and stacking them on top of each other, just like what Minecraft already does horizontally.

Minecraft 1.2 together with changed save format got world height increased up to 256 blocks. This was possible without making the game slower by splitting a Chunk into 16x16x16 subsections, just like what cubic chunks does (and in fact the update has been inspired by Robinton's cubic chunks mod). But instead of dynamically loading and unloading them, Minecraft just removed the empty ones which decreases memory usage. This mod dynamically loads and unloads these 16x16x16 sections as player goes up and down.

Downloads

What is left to do?

The full list of issues to solve can be found on github. Those marked with "beta release" milestone almost certainly need to be fixed before beta release.

Mod compatibility

Some mods will work, but many mods will break in unpredictable ways. Wile some mods may appear to work, even in 100+ mods modpacks, they are very likely to break when you actually begin to use them.

Plans far into the future

Some of these involve someone else making mod to do that, or just ideas that would be awesome to have but may never actually happen

Sponge compatibility - SpongeAPI has been designed to be able to work with cubic chunks. The Minecraft implementation however won't work with cubic chunks without compatibility patches. While I was already able to make sponge not crash and actually load a world, nothing else worked (even breaking blocks didn't work). This will almost definitely happen at some point.

Advanced terrain generation plugins/addons/mods/modules: more realistic terrain generators that make better use of the unlimited world height and depth

Stacked dimensions - nether below the overworld, the end above it. All as a single cubic chunks dimension with different 3d.

More realistic lighting system - I do have some ideas but I don't know if it will actually work

Approximate smooth rendering of faraway terrain - is it even possible in Minecraft

And this was what I found after just a few minutes of searching using github search feature (which almost never finds what you want). Seemingly unrelated things actually touch chunk loading. A lot of what mods do including terrain generation can work with cubic chunks in height range 0 to 256. The above won't just break outside of that range but possible corrupt your world or crash.

But you can't blame authors of the mods. Mods are free to assume they are dealing with vanilla minecraft+forge, and anything that breaks as result from not behaving exactly the same can be seen as not their fault. There is nothing I can do, and there isn't much I should expect them to do, because mods do in fact have access to all Minecraft internals.

What about the world size? The addition of so many blocks underground must make the files huge.

Yes it will increase size of the files, most likely in 3 different ways, and there really isn't much I can do. All I can say is: HDDs are big, unless you are running a server there is nothing to worry about:

Increased amount of blocks - obviously

Smaller chunks lead to worse compression. Each chunk is compressed individually which leads to much worse compression when using cubic chunks. I'm going to workaround it by saving, loading and generating them in 2x2x2 cubes groups (32x32x32 virtual cubes). This will still make a chunk about half the size of vanilla one, but they will have better spatial locality (the blocks stored in single chunk will be closer together) so it will compress better. Unfortunately there is only as small as a chunk can get with region format - which is 4kB for vanilla. I currently have it at I think 512 bytes which is the sector size for region files. The "obvious" solution would be to not store empty cubes at all, but there are other kinds of data stored too - lighting data and entities. And potentially special mod data. And eventually even biome data.

More lighting-related bookkeeping: Currently non-issue because OpacityIndex is updated dynamically as blocks are placed completely in memory. But it;s planned to change, Making this fast is likely to require almost doubling the save size. This is because to quickly access OpacityIndex data it should be either in memory (as it is currently, which is bad because there is no size limit to that), or be stored uncompressed. But there are some clever workarounds possible:

Store it compressed in Column when it's below certain size, and only store the outliers externally uncmpressed - but this means also writing to Column each time a cube is saved

Combined with the above, store it in cubes, and have column link to the cube with the latest version. This would increase cube size but probably not as much as actually always storing it uncompressed would.

Awesome! I'm glad to see that someone is making progress on this. Cubic Chunks are awesome. Hopefully the makers of the other mods will be able to take compatibility with this mod into consideration, I'd love to see this appear in a future FTB modpack or something.

Currently I've been playing the only semi-working cubic chunk mod-- Robinton's CC for beta 1.7.3. It has plenty of rendering issues but it works for the most part.

The more difficult thing with it has not been mod compatibility, but finding mods! Most links from September 2011 or earlier have not been maintained. And in one or two cases, a mod that added needed blocks (e.g. Stone Bricks) didn't even have recipes!

5½ years ago, it looked at one point like Notch was going to obtain or duplicate Robinton's code and add it to vanilla MC. Then Jeb and another person who thought it would behave like the taller chunk mods (i.e. lag out the computer) convinced him to not do it. This is the biggest injustice in all of Minecraft and has set us back years in CC development. Robinton was disheartened and quit.

This has been a long time in coming and we're still not there yet.

The lesson to be learned here is, when Barteks2x's mod comes out (whenever),grab it and run with it!

Currently I've been playing the only semi-working cubic chunk mod-- Robinton's CC for beta 1.7.3. It has plenty of rendering issues but it works for the most part.

The more difficult thing with it has not been mod compatibility, but finding mods! Most links from September 2011 or earlier have not been maintained. And in one or two cases, a mod that added needed blocks (e.g. Stone Bricks) didn't even have recipes!

I was able to bet MC 1.0.0 test version working with some mods, but I remember some mods crashing (even Risugami's shelf mod crashed after placing some of it's blocks). Finding beta mods is going to be close to impossible, you may have better luck writing them yourself (that is if you manage to get MCP working, it requires changes to some scripts)

5½ years ago, it looked at one point like Notch was going to obtain or duplicate Robinton's code and add it to vanilla MC. Then Jeb and another person who thought it would behave like the taller chunk mods (i.e. lag out the computer) convinced him to not do it. This is the biggest injustice in all of Minecraft and has set us back years in CC development. Robinton was disheartened and quit.

This has been a long time in coming and we're still not there yet.

The lesson to be learned here is, when Barteks2x's mod comes out (whenever),grab it and run with it!

I don't think you are completely right. It was jeb who actually implemented semi-cubic chunks based on Robinton's mod, and together with that added initial support for 4096 block IDs in save format and internal chunk data (also base don his mod) which is what made huge modpacks possible as we know them.

I think the reason they didn't actually take the code and implement real cubic chunks system was because skylight calculation seemed impossible to solve, and maybe a few other minor issues. Instead Minecraft took the good parts of both (except infinite height). The reduced lag and memory usage of cubic chunks, and the simplicity of linear chunks.

Without many changes to Minecraft code it would be possible to increase height to arbitrary value without making game very slow as long as you aren't trying to build there - truly dynamic world height. And I may actually make a mod that does just that - unlocks full possibilities of anvil format.

When I'm trying to import CC (Cubic Chunks) over to IntelliJ I don't see any Decomp setup workspace in the Gradle tab.
It would be nice if there was a step by step guide how to import cubic chunks to Eclipse or IntelliJ tho...

I was working on exactly that when you posted it. You should see readme on github updated in several minutes. Also note that users compiling a mod to run it is not a normal thing to do. I didn't release it yet for a good reason.

Well I tried to follow the instructions but i got stuck on ./gradlew build.

Every time i open cmd in the CC files and type: gradlew build

It keeps crashing like this

at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Error type encountered: [ERROR : ShadowJar] (ErrorTypeImpl).
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper$1.processErrorType(KotlinTypeMapper.java:147)
at org.jetbrains.kotlin.load.kotlin.TypeSignatureMappingKt.mapType(typeSignatureMapping.kt:118)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapType(KotlinTypeMapper.java:460)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapReturnType(KotlinTypeMapper.java:411)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapReturnType(KotlinTypeMapper.java:391)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1076)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1004)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignatureWithGeneric(KotlinTypeMapper.java:987)
at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:173)
at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:157)
at org.jetbrains.kotlin.codegen.PropertyCodegen.generateAccessor(PropertyCodegen.java:458)
at org.jetbrains.kotlin.codegen.PropertyCodegen.generateGetter(PropertyCodegen.java:423)
at org.jetbrains.kotlin.codegen.PropertyCodegen.gen(PropertyCodegen.java:125)
at org.jetbrains.kotlin.codegen.PropertyCodegen.gen(PropertyCodegen.java:105)
at org.jetbrains.kotlin.codegen.MemberCodegen.genSimpleMember(MemberCodegen.java:204)
... 100 more
(C:\Users\Qlyo\Documents\GitHub\CubicChunks\build.gradle.kts (71:1))
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project 'CubicChunks'.
> Could not open cache directory ds7bat0q5hrvjgut0vznknm7u (C:\Users\Qlyo\.gradle\caches\3.4-20170117200919+0000\gradle-script-kotlin\ds7bat0q5hrvjgut0vznknm7u).
> Internal error: org.jetbrains.kotlin.codegen.CompilationException: Back-end (JVM) Internal error: Failed to generate property shadowJar
Cause: Error type encountered: [ERROR : ShadowJar] (ErrorTypeImpl).
File being compiled and position: (71,1) in C:/Users/Qlyo/Documents/GitHub/CubicChunks/build.gradle.kts
PsiElement: val shadowJar: ShadowJar by tasks
The root cause was thrown at: KotlinTypeMapper.java:147
at org.jetbrains.kotlin.codegen.MemberCodegen.genSimpleMember(MemberCodegen.java:213)
at org.jetbrains.kotlin.codegen.ScriptCodegen.genMembers(ScriptCodegen.java:229)
at org.jetbrains.kotlin.codegen.ScriptCodegen.generateBody(ScriptCodegen.java:100)
at org.jetbrains.kotlin.codegen.MemberCodegen.generate(MemberCodegen.java:127)
at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generateFile(PackageCodegenImpl.java:119)
at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generate(PackageCodegenImpl.java:65)
at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.generatePackage(KotlinCodegenFacade.java:99)
at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.doGenerateFiles(KotlinCodegenFacade.java:77)
at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.compileCorrectFiles(KotlinCodegenFacade.java:44)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.generate(KotlinToJVMBytecodeCompiler.kt:417)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyzeAndGenerate(KotlinToJVMBytecodeCompiler.kt:328)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileScript(KotlinToJVMBytecodeCompiler.kt:532)
at org.gradle.script.lang.kotlin.support.KotlinCompilerKt.compileKotlinScriptToDirectory(KotlinCompiler.kt:70)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileTo$1.invoke(CachingKotlinCompiler.kt:134)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileTo$1.invoke(CachingKotlinCompiler.kt:45)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.withProgressLoggingFor(CachingKotlinCompiler.kt:185)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileTo(CachingKotlinCompiler.kt:132)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.access$compileTo(CachingKotlinCompiler.kt:45)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileWithCache$cacheDir$2.execute(CachingKotlinCompiler.kt:114)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileWithCache$cacheDir$2.execute(CachingKotlinCompiler.kt:45)
at org.gradle.cache.internal.DefaultPersistentDirectoryCache$Initializer.initialize(DefaultPersistentDirectoryCache.java:92)
at org.gradle.cache.internal.FixedSharedModeCrossProcessCacheAccess$1.run(FixedSharedModeCrossProcessCacheAccess.java:73)
at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.doWriteAction(DefaultFileLockManager.java:184)
at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.writeFile(DefaultFileLockManager.java:174)
at org.gradle.cache.internal.FixedSharedModeCrossProcessCacheAccess.open(FixedSharedModeCrossProcessCacheAccess.java:71)
at org.gradle.cache.internal.DefaultCacheAccess.open(DefaultCacheAccess.java:130)
at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:55)
at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:30)
at org.gradle.cache.internal.DefaultCacheFactory.doOpen(DefaultCacheFactory.java:89)
at org.gradle.cache.internal.DefaultCacheFactory.open(DefaultCacheFactory.java:63)
at org.gradle.cache.internal.DefaultCacheRepository$PersistentCacheBuilder.open(DefaultCacheRepository.java:116)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileWithCache(CachingKotlinCompiler.kt:116)
at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileBuildScript(CachingKotlinCompiler.kt:92)
at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.compileScriptFile(KotlinBuildScriptCompiler.kt:195)
at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.executeScriptBodyOn(KotlinBuildScriptCompiler.kt:107)
at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.access$executeScriptBodyOn(KotlinBuildScriptCompiler.kt:44)
at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler$compileTopLevelScript$1.invoke(KotlinBuildScriptCompiler.kt:92)
at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler$compileTopLevelScript$1.invoke(KotlinBuildScriptCompiler.kt:44)
at org.gradle.script.lang.kotlin.provider.KotlinScriptPlugin.apply(KotlinScriptPlugin.kt:42)
at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:39)
at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:26)
at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
at org.gradle.configuration.project.LifecycleProjectEvaluator.doConfigure(LifecycleProjectEvaluator.java:70)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$000(LifecycleProjectEvaluator.java:33)
at org.gradle.configuration.project.LifecycleProjectEvaluator$1.execute(LifecycleProjectEvaluator.java:53)
at org.gradle.configuration.project.LifecycleProjectEvaluator$1.execute(LifecycleProjectEvaluator.java:50)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:50)
at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:599)
at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:125)
at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:60)
at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:38)
at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuildAction.execute(DefaultGradleLauncher.java:233)
at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuildAction.execute(DefaultGradleLauncher.java:230)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:160)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:119)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:102)
at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:71)
at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:31)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:47)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Error type encountered: [ERROR : ShadowJar] (ErrorTypeImpl).
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper$1.processErrorType(KotlinTypeMapper.java:147)
at org.jetbrains.kotlin.load.kotlin.TypeSignatureMappingKt.mapType(typeSignatureMapping.kt:118)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapType(KotlinTypeMapper.java:460)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapReturnType(KotlinTypeMapper.java:411)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapReturnType(KotlinTypeMapper.java:391)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1076)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1004)
at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignatureWithGeneric(KotlinTypeMapper.java:987)
at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:173)
at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:157)
at org.jetbrains.kotlin.codegen.PropertyCodegen.generateAccessor(PropertyCodegen.java:458)
at org.jetbrains.kotlin.codegen.PropertyCodegen.generateGetter(PropertyCodegen.java:423)
at org.jetbrains.kotlin.codegen.PropertyCodegen.gen(PropertyCodegen.java:125)
at org.jetbrains.kotlin.codegen.PropertyCodegen.gen(PropertyCodegen.java:105)
at org.jetbrains.kotlin.codegen.MemberCodegen.genSimpleMember(MemberCodegen.java:204)
... 100 more
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 4.112 secs
C:\Users\Qlyo\Documents\GitHub\CubicChunks>

Join gitter chat (link in readme on github), this should asking questions quickly a bit easier, that seems like you are doing something wrong but I don't know what.

Hm, there is also the problem with render distance not being enough to actually load the map as far as would be necessary to really enjoy the awesome scenery this would possibly give. A workaround would be some sort of distant terrain renderer that essentially already generates the landscape but doesnt decorate it and uses 1x1 textures intead of 16x16 textures or alternatively just renders the middletone of the textures the blocks would normally use. And when the player gets closer it loads the actual textures and decorates the terrain with grass, trees, etc. A render distance of about 48 chunks would certainly be really awesome to play on. You could check out the way 7 Days To Die have done their distant terrain rendering (Best Survival Game out there).

Hm, there is also the problem with render distance not being enough to actually load the map as far as would be necessary to really enjoy the awesome scenery this would possibly give. A workaround would be some sort of distant terrain renderer that essentially already generates the landscape but doesnt decorate it and uses 1x1 textures intead of 16x16 textures or alternatively just renders the middletone of the textures the blocks would normally use. And when the player gets closer it loads the actual textures and decorates the terrain with grass, trees, etc. A render distance of about 48 chunks would certainly be really awesome to play on. You could check out the way 7 Days To Die have done their distant terrain rendering (Best Survival Game out there).

This is way outside of the scope of the core cubic chunks mod. But it's certainly something I would like to see at some point.
The problem with rendering distant chunks isn't that rendering textures is slow. It's the absurdally high amount of polygons and the amount of 16x16x16 render chunks to draw. Even flat 16x16 surface has 256 rectangles, which that GPU renders as 512 triangles. And terrain is rarely flat, usually more than doubling that number. And loading that stuff - it's all done serverside. And how do you think server will send this data to client? Sending just the blocks would be slow. I know the windows 10 version of Minecraft somehow manages to work with such render distance. I have no idea how. My guess is that C++ compiler is much smarter at optimizing code, and the fact that it was optimized to work well on mobile devices (because it essentially is mobile version compiled for windows 10).

32 chunks render distance already uses a lot of memory even in vanilla, and even more in cubic chunks (because of vertical view distance and some additional overhead).

What could be done is some algorithm that can generate low-polygon no-texture mesh ideally on scale larger than 16x16x16 blocks. This would no longer render blocks, but a smooth approximation of the terrain. It would also be careful with rendering player-made structures. And somehow loading them - a special structure in world save would need to be added for efficiently loading the data. Which would increase size of save file even more.