Cubic Chunks Support


#1

Hello there! Sorry for caps but i consider this thread especially important.

I don’t know if you guys heard of mod being developed - Cubic Chunks, a mod which has been developed for years now - previously its name was tall worlds. What it does is it just gives us option to unlock the Y axis and set generator settings by ourselves so we can get infinite height and depth worlds, and mountains tall as mt. Everest or even taller.

Mod is currently in alpha stage but even though it works really great. It actually increases fps count because you have less blocks loaded at one moment (sphere instead of cyllinder as with normal chunks). The thing is - i wanted to set up a forge server with Sponge plugins - mainly voxel sniper - as you may know the most popular build servers base on this plugin actually - Minecraft Middle Earth for example.

But so far literally sky is the limit - complicating many things like building structures in 1:1 scale. My intention is to support cubic chunks as much as i can and i want you to do the same.

This is the only way we can expect Microsoft to implement option of cubic chunks to vanilla and by that finally change minecraft from a shitty game to something truly worth attention of not only little kids but adults too, also by simplifying many things - as option of having nether in the same world for example - just by generating it 10 or 20 kilometers underground - just as it works with terraria for example.

So back to business - depending on if you will want to support me, mod creators and build servers you will take care of this issue or not. The thing is:

I set up a forge server: MC 1.12.2 version 2555
installed spongeforge-1.12.2-2555-7.0.0-BETA-2757 as a mod to the server
and here is the error from the logs of server starting - im not a coder so i just assume it’s something related to block coordinates - i believe its not very difficult to fix and even if im wrong i’d definitely do it if i were a coder because the amount of potential in Cubic Chunks is just like maximal height in this mod - the potential is infinite.

I’m on discord server in contact with developers of Cubic Chunks so let me know if you wish to tell them something.

Best regards
Adam.


#2

[main/FATAL] [mixin/]: Mixin apply failed cubicchunks.mixins.core.json:common.MixinWorld -> net.minecraft.world.World: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException cubicchunks.mixins.core.json:common.MixinWorld->@Inject::handler$getBlockState$zzm000(Lnet/minecraft/util/math/BlockPos;Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;)V cannot inject into net/minecraft/world/World::func_180495_p(Lnet/minecraft/util/math/BlockPos;)Lnet/minecraft/block/state/IBlockState; merged by org.spongepowered.common.mixin.core.world.MixinWorld with priority 1000
org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException: cubicchunks.mixins.core.json:common.MixinWorld->@Inject::handler$getBlockState$zzm000(Lnet/minecraft/util/math/BlockPos;Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;)V cannot inject into net/minecraft/world/World::func_180495_p(Lnet/minecraft/util/math/BlockPos;)Lnet/minecraft/block/state/IBlockState; merged by org.spongepowered.common.mixin.core.world.MixinWorld with priority 1000
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.checkTarget(InjectionInfo.java:437) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.findMethods(InjectionInfo.java:407) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.readAnnotation(InjectionInfo.java:172) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.(InjectionInfo.java:159) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.(InjectionInfo.java:151) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.CallbackInjectionInfo.(CallbackInjectionInfo.java:44) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.parse(InjectionInfo.java:480) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinTargetContext.prepareInjections(MixinTargetContext.java:1179) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.prepareInjections(MixinApplicatorStandard.java:900) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.applyMixin(MixinApplicatorStandard.java:304) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.apply(MixinApplicatorStandard.java:267) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.TargetClassContext.applyMixins(TargetClassContext.java:353) ~[CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinTransformer.apply(MixinTransformer.java:724) [CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinTransformer.applyMixins(MixinTransformer.java:703) [CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClassBytes(MixinTransformer.java:509) [CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at org.spongepowered.asm.mixin.transformer.Proxy.transform(Proxy.java:72) [CubicChunks-1.12.2-0.0.781.0_(Fast%20Collision%20Check%20Fixed).jar:?]
at net.minecraft.launchwrapper.LaunchClassLoader.runTransformers(LaunchClassLoader.java:279) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:176) [launchwrapper-1.12.jar:?]
at java.lang.ClassLoader.loadClass(Unknown Source) [?:1.8.0_101]
at java.lang.ClassLoader.loadClass(Unknown Source) [?:1.8.0_101]
at java.lang.Class.getDeclaredMethods0(Native Method) ~[?:1.8.0_101]
at java.lang.Class.privateGetDeclaredMethods(Unknown Source) [?:1.8.0_101]
at java.lang.Class.privateGetMethodRecursive(Unknown Source) [?:1.8.0_101]
at java.lang.Class.getMethod0(Unknown Source) [?:1.8.0_101]
at java.lang.Class.getMethod(Unknown Source) [?:1.8.0_101]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:132) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_101]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_101]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_101]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_101]
at net.minecraftforge.fml.relauncher.ServerLaunchWrapper.run(ServerLaunchWrapper.java:62) [forge-1.12.2-14.23.1.2555-universal.jar:?]
at net.minecraftforge.fml.relauncher.ServerLaunchWrapper.main(ServerLaunchWrapper.java:31) [forge-1.12.2-14.23.1.2555-universal.jar:?]
[12:49:48] [main/INFO] [STDERR/]: [org.spongepowered.asm.mixin.transformer.MixinTransformer:transformClassBytes:519]: org.spongepowered.asm.mixin.throwables.MixinApplyError: Mixin [cubicchunks.mixins.core.json:common.MixinWorld] from phase [DEFAULT] in config [cubicchunks.mixins.core.json] FAILED during APPLY


#3

That’s, um, heavily opinionated. I’m pretty sure that most people would not attach this incredible significance to the height limit. It does happen to be pretty high.

This is extremely incorrect. Sponge hooks into and tweaks, nearly everything, and that includes not only chunk processing but also chunk loading and unloading. In fact, the mod’s FAQ clearly states that if a mod relies on chunk data/metadata, then it will be difficult updating the code.

Bottom line is, Minecraft works the way it does, and Forge works the way it does, and Sponge is built around those two systems. Mods which work within the system, or extend it in the appropriate ways, work easily with Sponge. Mods which don’t, and/or change extremely low-level functionality like chunks, don’t. The onus is on the mod to work with the system, not on the system to work around the mod. If it’s fixable, you’re not likely to see it in Sponge ever, but there’s also a wonderful mixin system which someone could use in a Cubic Chunks addon to add the fix.


#4

What’s the mixin system? Please explain something more so i can try to explain sth. to mod developers. As i don’t see much of willingness from your side towards the overall idea.

“Most people would not attach this incredible significance to the height limit. It does happen to be pretty high” - the significance is incredibly high, you can tell it just by searching in google a little bit. Height limit is 1. lethal for most cpu’s as chunks are loaded as 16x16x256, so when someone wants to increase their fps by lowering the render distance it won’t be as effective as with Cubic Chunks. I myself am able to play with 60 fps on 32 chunks horizontal and vertical render distance with cubic chunks when on vanilla with optifine this size of render distance turns my cpu’s into frying pans and causes 10-28 fps 2. Moreover - no one will convince me that many people would dislike the unlocked Y axis option in core vanilla.


#5

So you’re saying that Sponge is the absolute sacred system which isn’t going to cooperate with modders? Even if CC developer did whatever he is able to you still won’t even bother?


#6

Mixin is a trait/mixin framework for Java using ASM and hooking into the runtime class-loading process via Mojang’s LegacyLauncher system. The main documentation for Mixin can be found in the Wiki. Additional documentation for individual features and annotations can be found in the extensive Javadoc. For
additional help use the channel #spongedev on the Espernet IRC network.

Well known mods which do not break the core mechanics of the base game are supported very well and majority of bugs are fixed within few days or weeks.

Like it or not, sponge team is short on human resources. Its simply not worth and sometimes not even possible to support every single mod out there.


#7

That is what’s known as a strawman. Please Google it before responding.
Sponge integrates with Forge which integrates with Minecraft. Few aspects of the system are left untouched. Redoing everything related to chunks would be a hell of a lot of work, and it’s a much bigger priority to keep the system updated and working with regular mods, as well as improving and implementing the API. SpongeForge with CubicChunks support would also need to be an entirely different product - there’s no way for something this deeply intertwined with the chunk system to do both. So then you’d have two separate codebases, which need to be updated and debugged separately… it’d be a nightmare. Not to mention, of course, the fact that the API includes first-class regular chunk support, so it’d need a separate API and separate versions of plugins which involve chunks.
Are you starting to see why this would be infeasible? Modifications to Sponge to improve the system are always welcome, and are pursued both by the team and the community. But you’re advocating for the creation of an entirely new system, which would need to be maintained separately.

And no, Sponge doesn’t generally ‘cooperate’ with modders in that precise sense of the word. Sponge hooks into the system in a way that assumes the various components are used correctly. If a mod says ‘screw it’ and does everything its own way, it breaks compatibility with Sponge, the same way it breaks compatibility with other mods. The only difference is that Sponge is forced to interact with the mod immediately, leading to a crash on startup, whereas the other mod may go an indefinite amount of time without interacting with the first mod, but crash as soon as the two do end up interacting. The only time any mod ‘cooperates’ with another mod in the sense you’re using is if the mods form part of the same system, such as TE flux capacitors going on TiC tools. And Sponge is hardly going to include APIs for every mod in existence - that’s what third-party addons are for.

“What he is able to” is fixing the entire problem (aside from chunk-dependent plugins, of course), by making a compatibility mod which modifies Sponge at runtime to support cubic chunks. That is the fun of mixins.


#8

Quick Note, the SpongeAPI has been designed to be potentially compatible with CubicChunks. The author of CubicChunks also uses Mixins and has been working along side the Sponge team to keep CubicChunks compatible with Sponge.

The dev team have been making a small effort to remain compatible, but at the end of the day, both CubicChunks and SpongeForge are coremods that drastically change the base game, compatibility will only be achieved with help from both.

I understand you are passionate @Angelimar , but your arguments, and the way you approach them feels very inflammatory.

You don’t need to act as a go-between, CubicChunks is either using Mixins, or porting to Mixins.


#9

That’s not quite correct pie.

The Sponge team are absolutely willing to own bugs they create, if the mods are using the right hooks in Forge.

There is a rather large difference between core mods and normal mods, and whilst compatibility with core mods is always going to be the responsibility of both mod authors, compatibility with mods should be pretty straight forward to maintain if it mimics vanilla method calls and inheritance structures.


#10

That’s what I said, actually. Essentially, Sponge fixes bugs on their end, but won’t work around bugs on mods’ ends.


#11

Y’know, most of this could have been simply sorted out by chatting with @Barteks2x who works on the Cubic Chunks mod (iirc). He’s been very friendly with Sponge developers in the past, and can probably give you the skinny on compatibility between Sponge and CC. The main issue is that it changes fundamental MC mechanics so much that it messes with the normal expectations of almost every mod out there. Writing mixins that allow the functionality to be accessible to other mods is a prohibitively difficult task; it’s likely to be easier to rewrite the mods to be compatible with CC.

In a nutshell: Cubic Chunks pulls the carpet out from under most mods. They have no idea how to interact with this system because it really is quite alien to Minecraft. Making some kind of compatibility layer would be a monster task.Not impossible, but very hard, hence the slow progress of CC development. HTH.


#12

Ok. I got it now. But i’d disagree that CC messes with almost every mod out there. I myself was surprised when i successfully managed to set up a forge server and play on it with 40 very popular mods incl. buildcraft, immersive engineering, extrautilities, little tiles, THUT’S ELEVATOR (ye even that cool thing), viescraft, modern warfare mod and shitload of other mods - only thing that sometimes happen are small bugs and single machines bugs like - IE excavator doesnt dig ores because it was coded to work with normal chunk system but other machines from IE work perfectly so i guess this one wont require rewriting the whole mod just for the excavator to work. Inscrutable i dont know maybe you meant “it messes up with almost every mod which affects world generation in any way” - well CC is still in alpha and i believe this problem will be solved. What i meant after all - i want to convince everybody towards Cubic Chunks as Barteks’ mod to make it very very popular which can lead to several things: 1. it gets kinda implemented to forge (or at least an option of creating a world with unlocked Y which A) could push many modders to create mods towards Cubic Chunks because it’s just better than vanilla in every damn way. 2. it gain so much popularity so point A) happens 3. Microsoft takes interest and unlocks the Y axis. The vanilla gets a whole new meaning - a better meaning (finally) and amount of modders grow because possibilities grow. Well that’s my dream kind of :smiley:


#13

That wasn’t what was said. CC messes with the expectations of almost every mod out there, i.e. that chunks work the way they do. With some mods that’s fine, because there’s few things that actually depend on chunks. But any mod which does, breaks. And it’s not something that gets ‘fixed’. It gets modified. A separate version is created which does work with CC. This separate version does not work without CC. Your example of IE - the excavator would need to be rewritten and maintained separately.

World generation is also very chunk reliant, so no, it can’t be solved without per-mod changes. Almost all of which result in a modified version which is not compatible with non-CC Minecraft.

It’s a great dream, but simply put, it’s not likely to appear in Minecraft-based communities until it’s implemented in vanilla Minecraft, for the reasons we’ve explained.


#14

Here’s a relevant extract from the OpenCubicChunks WIki:

A lot of mods assume that world height is 256 and that there are no blocks below y=0. This mod breaks this fundamental assumption so a lot of mods won’t work correctly. There are also many technical details that make it nearly impossible to make some mods compatible with Cubic Chunks without modifying these mods.
In current development stage mod compatibility is very low priority so it’s very unlikely to be compatible with anything.``