Tall Worlds Mod - Raising the world height cap without causing lag
Poll: TWM needs money to continue. Would you donate to a Patreon?
TWM needs money to continue. Would you donate to a Patreon? - Single Choice
- Nope. I don't want to spend money on mods. I'd rather the mod didn't exist than pay to support development. 6.9%
- Nope. I'd be happy to donate, but I don't have any money. 52.8%
- Sure, I guess I could spare $1-$5 a month to help finish the mod. 23.6%
- Yes! I'm really excited about the mod AND I have lots of money! I could donate more than $5 a month. 13.9%
- I'm incredibly wealthy, or a potential business sponsor. I could give $100+ a month. 2.8%
Ended Feb 11, 2016
I'm not working on Tall Worlds Mod anymore! But Barteks2x is!
Read all about his progress here:
I'll keep the original OP below for historical reference though.
Next up in my series of exciting mods is the Tall Worlds Mod!
The goal is simple: Raise the height cap on the world from 256 blocks to 16,777,216 blocks, but do it without adding too much lag. Turns out that's pretty technically challenging to do, but I love a good technical challenge.
Download the mod:
Tall Worlds Mod has released a somewhat-working protoype! The core idea of cubic chunks works fairly well, but there are still lots of minor bugs that prevent seamless gameplay. You can try out the mod today if you like, but don't expect it to work with any of your other mods.
Download Tall Worlds Mod prototype
How does it work?
The first step to raising the height cap on worlds is to break up the world into pieces vertically and only load the vertical pieces when players are actually near them. Of course, Minecraft's chunk system does exactly this to break up the world horizontally, but the vertical size of the world has always been fixed at 256 blocks.
Tall Worlds Mod breaks up Minecraft's world in the vertical dimension as well. Here's an early video of the cubic chunk loading system in action, the main component of Tall Worlds Mod.
Of course, players can't travel very quickly in the horizontal directions, so chunk loading doesn't have to be very fast there. But what about players in free fall? How fast can a cubic chunk system load chunks when players are moving very quickly? This video answers that question:
Minecraft Version: 1.8.3
Modding System: Magic Mojo Mod Loader (M3L for short)
Wait... what the heck is Magic Mojo Mod Loader?
Well, building the Tall Worlds Mod required gutting and entirely replacing large portions of the Minecraft engine. Namely, the entire chunk loading system and a fair bit of the lighting system. Since these changes are rather large, there isn't much benefit to using a modding system like Forge which has essentially no APIs to help with something like this.
I'm using Tall Worlds Mod to start building the modding API for my own modding system, Magic Mojo Mod Loader, or M3L for short. You can read the justification for why we need yet another modding system here, but it means that when I eventually release M3L, you'll actually have modding API support if you wanted to do something completely insane like entirely replace the chunk loading system in Minecraft.
If you REALLY have a lot of free time, there is another thread discussing cubic-chunk type mods. It's 275 pages long at the time of this post and it's chocked full of discussion about cubic chunk ideas, particularly suggestions for how to solve "the lighting problem." I'll be honest though, I haven't read the whole thread.
Need more room to talk? Try the offiicial Tall Worlds Mod Forums:
I think we're starting to outgrow a single thread for discussing Tall Worlds. In a huge thread, sometimes good suggestions get lost. If you feel like you want more room to talk, or a place to put your suggestions so people can actually find them later, header over to the dedicated forums.
Development Status: Backburner'd!
I'm taking a break from working on Tall Worlds for a while.
All of the fun technical challenges have been solved and all that's left to do is a massive amount of tedious cleanup work. This is a hobby project. I'm going to enjoy doing the fun bits, but there's no reason I need to slog through all the tedious bits. The tedious work left to do includes things like finding all the places in vanilla Minecraft that broke because of the new engine changes and trying to add compatibility with every modded thing ever imagined.
The only reason to do boring work is if someone is paying a decent wage, and that's definitely not the case here. I ran a poll for about a month asking if players would donate to a Patreon. The answer was very clear: the donations wouldn't come anywhere close to paying a decent wage, or even make a dent in my rent payments.
I general, I think making massive changes to Minecraft's core game engine and seeing them through into a finished product is far larger in scope than any one person can really do for hobby without getting seriously burned out. I put up a prototype mod to show the idea actually works, but I don't really have any interest in turning it into a finished product. Perhaps it's up to Mojang now to decide if they want cubic chunks or not, but it's just too much work for a single unpaid modder.
The entire project is open source of course. Contributions are always welcome from other modders. None of this technology is disappearing any time soon, it's just going to start gathering dust.
In the meantime, I'm going to focus all of my energy into my Ships Mod and make that mod the best mod it can be.
Since I'm no longer splitting my time among too many projects, I should be able to make some real progress, so look forward to some exciting new features there!
All mods by Cuchaz:
Tall Worlds Mod
Make the mod a reality! We believe in you!
M3L will be able to run alongside Forge. Meaning, you should be able to run both modding systems at the same time.
No. The simplest way to raise the height cap would lower FPS, but the way I do it is much more sophisticated and could even raise your FPS.
It's true, Forge's core mods might potentially allow something like this, but I think core mods are a curse upon this planet and should never be used. They kind of go against the point of having an inter-mod compatibility layer in the first place.
EDIT: Aha! You're the colored lights guy? Nice work! That one's tricky to pull off too.
But it's great to see that you're making progress in making a CC mod.
also you should check out Link Removed
Yeah, you're technically right, but that version of Minecraft is so ancient now I didn't even consider it.
So... it all depends on how you write your coremod... Currently, I'm still 100% backwards compatible, while adding light data to the save file, across all mods. It's not easy, but well within the reach of Forge. I changed the rules by which EVERYONE lights up blocks, but left vanilla intact, and I left the input and output channels as they were. Colored light merges with the old system, and when light spreads out, other blocks pick up the changes!
It's all in how you set up, hook in, and manipulate what's around you. If you spend enough time on it, a design usually makes itself apparent.
But I agree, if a coremod breaks inter-mod relations, then it's a bad mod... but I don't use that as justification to disown the entire coremod system... that's just a sign that people are using it improperly. (And why I continue to use it)
You can get by with core mods if you're not changing vanilla Minecraft. Kudos to you if you found a way to make colored lights without doing that. I don't think that can work for everyone though. It's way too easy to make a core mod that breaks a whole bunch of other mods you couldn't have possibly known exists. Core mods put the all the burden of compatibility onto the mod author where it's actually much harder to deal with the problem. Sure, a talented dev can do it, but it shouldn't be that hard to write a mod. It's much easier to handle inter-mod compatibility problems centrally in the mod loading system.
Are you suggesting that a Minecraft update would delete a tall world? That probably won't happen.
I think they're trying to say that if a person had to update Minecraft after using this mod, everything above Y:255 (or was it Y:256? I can't remember) in a world where this mod was used would be gone. That is, if they don't install an update to the mod.
also you should check out Link Removed
Then that is that person's problem. Obviously updating Minecraft while you have mods installed and then playing on the same world will break that world, that is common sense.
Newer Generations like biomes and such would provide less pain from Bedrock and loads more ores if done correctly...
or even less ores if done wrong...
But now I can make a gargantuan Hunger Games arena!
(oh who am I kidding? Hunger Games minigames are all terrible.)
The reason Godzilla 2014 failed was because there was no Mothra in it.
Mothra is the only reason Godzilla is good. Mothra saved the movie industry. If Mothra never existed nobody would like movies. The reason many people hate Call of Duty is because it lacks Mothra.
I changed my name to MothraFanboy27.
Raising the height limit to something within the range of Earth's mountains (up to ~8800m) would be fantastic. 65k+ blocks of build space is even more impressive.
Keep up the good work!
Data storage is a GREAT example.
You as a mod writer have a couple ways to do this.
Modify the current world save, and expand a single player world save file to N dimensions, reformatting the current system. This would "remove" backwards compatibility as the new file format that you create wouldn't be able to interface with the old format.
You can try to stack the old format on top of itself (along the y dimension) making save files giant pancakes 256 blocks tall all stacked on top of each other. So 0-256 would put you in pancake 1, but 256-512 would put you in pancake 2! If you do this right, you can leave the OLD save data in tact, and then a vanilla client can still talk to the first pancake just fine!
That, and it will make network transfer a bit easier for the first iteration.......
Sure, you can start messing around with how stuff is moved and loaded, but it's up to you how to store the data. If you do it well, then it will interface with other systems (including vanilla) because you left the source material looking the same. Now, the big changes have to occur when and how you save and load. But, that's OK! You have to change saving and loading specifically when it comes to chunk data, and no one expects you do it any other way. You can even change how data is represented in memory. as long as you keep the calls to world looking the same. If I call world.getBlockMetadata(arguments), I'd hope to be able to use this on vanilla or cubic systems. It's totally possible, and keeps everything working!
This kind of thought process is independent of M3L or Forge. That's all I'm saying.
You've been doing a great job! Keep it up!