To solve the large cavern issue wouldn't you just need to know what the biome is, from that doesn't the system have the numbers for what the lowest point of generation could be? At that point you just need to subtract the distance of the deepest hole generating terrain feature, which I think is the chasm.
So anything below Biome's Lowest Point minus Deepest Random Terrain Generation is automatically covered on generation. That would at least fix deeper underground caverns (there still may be some oddities right at the border but is better than nothing ).
Example: if plains can generate from -10 to 50, and if chasms are 30 blocks deep then the lowest point would be -40, so anything under -40 would have to be covered by some surface block when generated. This could all be calculated at world generation and stored somewhere, at which point it would be a simple if check for deep caverns if it could be lit.
To fix caverns that are above the biome's lowest point minus deepest random terrain generation mark you would need to do what Pentrit suggested and have the world generate up to the biome's heighest point could generate plus the tallest random terrain generation which I think is probably a tree.
While this solves the issue of having to generate infinitely up, it still may take too much time, and therefor not be feasible.
Example: if plains can generate from -10 to 50, and trees can be 20 blocks tall you would need to generate up to 50+20=70, or the chuck that contains height 70. Again the number could be stored at world generation and then just be a lookup based on the biome, but the higher the biome can generate the larger the hit to performance unfortunately.
I have no clue what the actual impact to performance would be for doing one or both of these or if there are any ways to mitigate that hit. I suppose it may be possible to have the upwards generation done on a separate thread and then once complete update the light appropriately, but I will leave any possible implementation to those that know the specific code better than I.
Cuchaz is exactly right about what this would require. Minecraft terrain doesn't use 2D functions to get the terrain height, it uses 3D noise fields, so that it can generate overhangs and the like. To compute a height function from these noise fields, you would basically have to calculate the majority of the terrain data for all the blocks above the current point. It's a massive amount of computational time for a small cosmetic benefit. Alternately, you could completely reinvent the terrain generation code. This could be an elegant way to solve the problem if you came up with a code which easily computed the maximum height, yet still allowed nice looking hills and formations. But nobody yet has been able to come up with a generator that does this.
But if you think it's that important, why don't you download the source code and start trying it out to see if you can get it working decently?
Doesn't it make you wonder though, if "infinite" is really even necessary?
I mean, if we constrained the limits to something even roughly approximating earth it would makes things crazy easier. Wouldn't it? And still provide virtually infinite more room.
Doesn't it make you wonder though, if "infinite" is really even necessary?
I mean, if we constrained the limits to something even roughly approximating earth it would makes things crazy easier. Wouldn't it? And still provide virtually infinite more room.
No need for concern then. For some reason people keep running around using the word "Infinite" but this mod won't have Infinite vertical space any more than the original Cubic Chunks Mod did or any more than vanilla minecraft has infinite horizontal space.
Cuchaz's current goal is around 16,000 Km total (16,777), that's 8,000 Km below sea-level and 8,000 Km above sea-level. The diameter of the Earth is approx 12,720 Km. So pretty much what you are asking for! Also; The Horizontal space of Minecraft currently equals the diameter of 2.5 Earths (32,000 Km).. So this mod's vertical space, being about 1.5 Earth Diameters, doesn't quite equal the allowed vanilla Horizontal dimensions but is close enough.
For more contrast; the last several versions of the original Cubic Chunks mod had a vertical space of 64 Km, 32 Km above and 32 Km below, and the next version that was going to happen would have had a total vertical space of 4 Million Km... That was the version FutureCraft was going to base it's solar systems on. For one more point of reference: The famous open source C copy of Minecraft, Minetest, has used cubic chunks for years and has a volume of +30 Km to -30 Km in every direction, slightly less than the final versions of the original Cubic Chunks mod for Minecraft had.
Tall Worlds mod is another scale or two larger than the last version of the original CC mod but not yet as far as it could go. This version sounds just right for your needs.
[EDIT]
Plus; I imagine the new vanilla definable map boundaries feature could be added to to allow defining Height/Depth map boundaries as well? That would allow you to cap the height/depth for your server or personal world at whatever you prefer. This mod would be the foundation that would enable that arbitrary amount of vertical space, with those wanting more space being able to have it too. * There wouldn't be any fundamental difference in performance though.
[EDIT**] I have edited the main message above the first EDIT tag. It would have been a mess to try to tag all of it, so please reread it all if you have interest in it. Thank you.
[EDITx2] All below is New:
It finally dawned on me that the following information would be the most direct answer to the question you were actually asking:
The original Cubic Chunks mod started with a vertical space of "only" 4096 blocks total, 4Km, +2 Km to -2 Km. After I bugged Robinton enough about orbital and space applications of the mod he bumped the space from 4 Km to 64 Km. He said it turned out to be very easy to do, and it didn't slow the game down at all. I then, due to my dev friend connections to the Futurecraft mod, started bugging him about pushing it even further. He eventually looked into it and discovered that he could push his mod to a vertical space of 4 billion blocks, 4 million Km, (further than the horizontal space allowed) and it would only increase his world save file size by about 10% and shouldn't noticeably affect the gameplay speed at all! This version didn't happen for other reasons but it almost did.
The main thing to learn from the above is that there is no real fps game performance to be gained by artificially restricting the game height, that's just not how the cubic chunks methodology works. The only reason to arbitrarily restrict game height is for server management reasons, not performance reasons. I hope this finally answers this question for everyone. Many questions regarding the cubic chunks method have already been tested and answered long ago. Don't get me wrong, there are some that haven't yet and which Cuchaz is actually in the process of solving, for which the old CC guard and all of you should be very grateful for.
[EDIT***] Sorry, I again updated a paragraph of the main post above the first EDIT. It was all in the second paragraph of what I wrote this time though.
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
Well, to begin, hello everyone, I'm new on this thread I think.
I don't know if it has already been asked, but as soon as I saw the latest video, I started thinking about rendering, because the thing is that if you're super duper high, you'll see the moon/sun while looking at your feet (if you're falling).
I might have found a way to solve that problem: what if your code detected when surface chunks become invisible to a person that's over them, and, since they will not be updated while unloaded, what you would have to do is only "save" their render, and show it to the player, so he can have a look at them.
I don't know, maybe it would add a lot of lag, but I propose something. =)
Rollback Post to RevisionRollBack
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =) Current number of corrected posts/things: 7
I love seeing Futurecraft get mentioned, it makes me feel like we're famous.
Anyway, Frostbyte is (was?) working on a method of increasing the view distance as much as 16x without increasing lag, using a special long-distance rendering system, you could potentially use that to render the ground below someone. I can't remember if we planned to use that to render a planet's surface from orbital altitudes, or a different system using bump mapping, I'd have to check.
Also, as far as I remember we weren't going to have a entire solar system be a actual world, it was going to be a void that had seperate, interacting dimensions(ships, planets) floating in it. This is from memory ofc, I might be wrong, but then again I'm not sure we even actually decided since the mod's been progressing at the pace of a slug, riding a snail, riding a turtle(that's frozen solid).
Not really. In terms of programming difficulty, there's, as far as I can see, little difference between, say, 16 million blocks height and four thousand.
There's not much difference. 16m blocks is the highest I can go right now without using more than 64bits to represent a cube coordinate (dimension, x, y, z). That's the limitation on height/depth right now. But it's so huge, it might as well be infinite. I doubt anyone would spend the tens of hours it would actually take to fly that far in the game.
The main thing to learn from the above is that there is no real fps game performance to be gained by artificially restricting the game height, that's just not how the cubic chunks methodology works.
Yup, there's no difference in performance if you take an engine that can handle 16m blocks and cut it down to 8m.
Well, to begin, hello everyone, I'm new on this thread I think. I don't know if it has already been asked, but as soon as I saw the latest video, I started thinking about rendering, because the thing is that if you're super duper high, you'll see the moon/sun while looking at your feet (if you're falling). I might have found a way to solve that problem: what if your code detected when surface chunks become invisible to a person that's over them, and, since they will not be updated while unloaded, what you would have to do is only "save" their render, and show it to the player, so he can have a look at them. I don't know, maybe it would add a lot of lag, but I propose something. =)
Hi Martititi!! =D
Fixing sky rendering is one of the things on our todo list. Basically, the sun and moon should never be at your feet.
We'd eventually like to do some fancy visibility calculations too (so we can do cool things like render the ground when you're waaaay up high), but an effective and general solution to that problem is pretty complicated. It's going to take some time to design some algorithms and test them out.
There's not much difference. 16m blocks is the highest I can go right now without using more than 64bits to represent a cube coordinate (dimension, x, y, z). That's the limitation on height/depth right now. But it's so huge, it might as well be infinite. I doubt anyone would spend the tens of hours it would actually take to fly that far in the game.
Tens of hours is a bit of an understatement... more like tens of days.
Even if you ~fell~ from y=8m, it would still take an entire day before you hit the ground at ~y=0.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Thank you for the thoughtful and detailed responses. After reflection on my original question and your responses I've actually come to the conclusion that I was only asking half of what was going on in the back of my mind. To wit...
Having worked on a 40k x 40k map using one byte of DEM data per block, I have to say that the difference in height between the plains and mountains is...meh. It works, but it's less than desirable. The 40k x 40k represented around 1500 miles x 1500 miles, or around 1:60 scale...in the HORIZONTAL. The 256 blocks of height was representing sea level up to ~8k meter mountains, or ~1:30.
When I originally started the map I was shooting for 80k x 80k (~1:30), and the fact that the horizontal was stretched out 2x made the vertical SEEM more appropriate. It actually looked BETTER that way. Which makes sense, the two scales being about the same. I ended up going with 40k for practical reasons: my rig took 4x longer to export each section at 80k. Heh.
But anyway, still less than impressive in actuality. It was cool, standing on the plains looking way up at the mountain tops, but could have been better.
Take that concept and extrapolate with me for a minute though...what if the vertical was 512? 1024? The vertical height differences would be way more spectacular but...is there a point where having TOO much vertical detail is BAD? Is there a sweet spot? And what about render distances? If we had a 1:1 vertical, the mountains would be 8000 blocks above the plains. Can we honestly render 8000 blocks away in realtime yet? Not even close!
So I guess that's what I *meant* to ask. Do we really NEED all that space? Just because we can have it doesn't mean it'll be fun!
So I guess that's what I *meant* to ask. Do we really NEED all that space? Just because we can have it doesn't mean it'll be fun!
Or practical.
Well...
Being able to build as high as you want = good. Having terrain that misuses the vertical space, looks hideous, and makes it almost impossible to have fun exploring? That's not so good. Luckily, we can have lots of building space and perfectly reasonable terrain
In other words; I agree that there will be a sweet spot (or a couple of sweet spots) for the terrain scale. Not too huge, not too flat, etc. The available building space is a different matter however; extra space won't bother you when you don't need it, but we all know how irritating the vanilla height limit can be when we want to build something big.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Since I did not follow the discussion closely, I don't know what you are really talking about.
Though, it seems to me that you are discussing about optimizations about blocks' coordinates in order to place them correctly.
I had an idea about it, and it might also be yours. By reading this:
the idea popped up in my mind: what if you did some kind of chunk coordinates, and then tell the blocks that are in the chunk: inside the chunk, you have another coordinates.
I mean: supposing you have a chunk coordinate: x=1; y=1; z=1
Inside this chunk, every block will have coordinates inside the chunk, for example (if there is no 0-position in the chunk) the
bottom-front-left corner block would be at x=1: y=1; z=1.
Though, in this chunk, you would not have values exceeding 16, since the blocks coordinates doesn't apply outside the chunk.
I guess it would be less demanding on memory.
Rollback Post to RevisionRollBack
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =) Current number of corrected posts/things: 7
I think that it would save a lot of memory since:
- inside the chunk, you would need to store a value that cannot go over 16 ==> you would need only 5 bits to store it
- in the real world (so, outside any chunk), you would divide the number of coordinates by 16, because blocks don't need a personal coordinate...
Rollback Post to RevisionRollBack
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =) Current number of corrected posts/things: 7
what if you did some kind of chunk coordinates, and then tell the blocks that are in the chunk: inside the chunk, you have another coordinates. I mean: supposing you have a chunk coordinate: x=1; y=1; z=1 Inside this chunk, every block will have coordinates inside the chunk, for example (if there is no 0-position in the chunk) the bottom-front-left corner block would be at x=1: y=1; z=1. Though, in this chunk, you would not have values exceeding 16, since the blocks coordinates doesn't apply outside the chunk. I guess it would be less demanding on memory.
This is a fantastic optimization! Minecraft already does this. =)
Okay, but if it could be compatible with other mods, would you allow it to be used in modpacks?
Tall Worlds Mod uses a completely different mod loader than, say, a mod pack full of Forge mods. You can't just add it to an existing mod pack and expect it to work properly.
Pardon me while I froth excitedly over this mod for a couple of minutes. <3
...
Okay, I'm alright.
Here's a question: Say I wanted to make a mod that adds some tall or deep worldgen complicit with Tall Worlds' extended height limits. Would I need to make this mod using M3L? What about if it's an addon to a pre-existing Forge mod?
In short, under what conditions would I need to use your M3L for my mod to ensure compatibility with Tall Worlds?
Rollback Post to RevisionRollBack
What do you mean, "fox" isn't the sound foxes make? Didn't you learn anything from Pokémon?
Say I wanted to make a mod that adds some tall or deep worldgen complicit with Tall Worlds' extended height limits. Would I need to make this mod using M3L? What about if it's an addon to a pre-existing Forge mod?
In short, under what conditions would I need to use your M3L for my mod to ensure compatibility with Tall Worlds?
These are fantastic questions. I don't even know the answers to them yet.
Here's my long-term plan for M3L.
The plan is for M3L to get rid of the need for Forge core mods. This should hopefully reduce the number of inter-mod compatibility issues overall. M3L should be able to run along-side of Forge and all its loaded mods. ie, you should be able to run M3L mods and Forge mods at the same time. You could even run Forge core mods too, but I wouldn't recommend it. Core more are too unpredictable and neither M3L nor Forge can guarantee that bad things won't happen.
Tall Worlds is the world's first mod built on M3L. If you build a mod on top of M3L, it will certainly be compatible with Tall Worlds.
If you build a mod on Forge, and try to interact with a mod on M3L, it should theoretically be possible. All the needed classes should be loaded in the same class loader, but there might be some issues with class load order.
Ermm... that was a bit technical. What I mean is, mods from the two ecosystems might be able to talk to each other, but it will take some extra work.
So anything below Biome's Lowest Point minus Deepest Random Terrain Generation is automatically covered on generation. That would at least fix deeper underground caverns (there still may be some oddities right at the border but is better than nothing ).
Example: if plains can generate from -10 to 50, and if chasms are 30 blocks deep then the lowest point would be -40, so anything under -40 would have to be covered by some surface block when generated. This could all be calculated at world generation and stored somewhere, at which point it would be a simple if check for deep caverns if it could be lit.
To fix caverns that are above the biome's lowest point minus deepest random terrain generation mark you would need to do what Pentrit suggested and have the world generate up to the biome's heighest point could generate plus the tallest random terrain generation which I think is probably a tree.
While this solves the issue of having to generate infinitely up, it still may take too much time, and therefor not be feasible.
Example: if plains can generate from -10 to 50, and trees can be 20 blocks tall you would need to generate up to 50+20=70, or the chuck that contains height 70. Again the number could be stored at world generation and then just be a lookup based on the biome, but the higher the biome can generate the larger the hit to performance unfortunately.
I have no clue what the actual impact to performance would be for doing one or both of these or if there are any ways to mitigate that hit. I suppose it may be possible to have the upwards generation done on a separate thread and then once complete update the light appropriately, but I will leave any possible implementation to those that know the specific code better than I.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCuchaz is exactly right about what this would require. Minecraft terrain doesn't use 2D functions to get the terrain height, it uses 3D noise fields, so that it can generate overhangs and the like. To compute a height function from these noise fields, you would basically have to calculate the majority of the terrain data for all the blocks above the current point. It's a massive amount of computational time for a small cosmetic benefit. Alternately, you could completely reinvent the terrain generation code. This could be an elegant way to solve the problem if you came up with a code which easily computed the maximum height, yet still allowed nice looking hills and formations. But nobody yet has been able to come up with a generator that does this.
But if you think it's that important, why don't you download the source code and start trying it out to see if you can get it working decently?
I mean, if we constrained the limits to something even roughly approximating earth it would makes things crazy easier. Wouldn't it? And still provide virtually infinite more room.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo need for concern then. For some reason people keep running around using the word "Infinite" but this mod won't have Infinite vertical space any more than the original Cubic Chunks Mod did or any more than vanilla minecraft has infinite horizontal space.
Cuchaz's current goal is around 16,000 Km total (16,777), that's 8,000 Km below sea-level and 8,000 Km above sea-level. The diameter of the Earth is approx 12,720 Km. So pretty much what you are asking for! Also; The Horizontal space of Minecraft currently equals the diameter of 2.5 Earths (32,000 Km).. So this mod's vertical space, being about 1.5 Earth Diameters, doesn't quite equal the allowed vanilla Horizontal dimensions but is close enough.
For more contrast; the last several versions of the original Cubic Chunks mod had a vertical space of 64 Km, 32 Km above and 32 Km below, and the next version that was going to happen would have had a total vertical space of 4 Million Km... That was the version FutureCraft was going to base it's solar systems on. For one more point of reference: The famous open source C copy of Minecraft, Minetest, has used cubic chunks for years and has a volume of +30 Km to -30 Km in every direction, slightly less than the final versions of the original Cubic Chunks mod for Minecraft had.
Tall Worlds mod is another scale or two larger than the last version of the original CC mod but not yet as far as it could go. This version sounds just right for your needs.
[EDIT]
Plus; I imagine the new vanilla definable map boundaries feature could be added to to allow defining Height/Depth map boundaries as well? That would allow you to cap the height/depth for your server or personal world at whatever you prefer. This mod would be the foundation that would enable that arbitrary amount of vertical space, with those wanting more space being able to have it too. * There wouldn't be any fundamental difference in performance though.
[EDIT**] I have edited the main message above the first EDIT tag. It would have been a mess to try to tag all of it, so please reread it all if you have interest in it. Thank you.
[EDITx2] All below is New:
It finally dawned on me that the following information would be the most direct answer to the question you were actually asking:
The original Cubic Chunks mod started with a vertical space of "only" 4096 blocks total, 4Km, +2 Km to -2 Km. After I bugged Robinton enough about orbital and space applications of the mod he bumped the space from 4 Km to 64 Km. He said it turned out to be very easy to do, and it didn't slow the game down at all. I then, due to my dev friend connections to the Futurecraft mod, started bugging him about pushing it even further. He eventually looked into it and discovered that he could push his mod to a vertical space of 4 billion blocks, 4 million Km, (further than the horizontal space allowed) and it would only increase his world save file size by about 10% and shouldn't noticeably affect the gameplay speed at all! This version didn't happen for other reasons but it almost did.
The main thing to learn from the above is that there is no real fps game performance to be gained by artificially restricting the game height, that's just not how the cubic chunks methodology works. The only reason to arbitrarily restrict game height is for server management reasons, not performance reasons. I hope this finally answers this question for everyone. Many questions regarding the cubic chunks method have already been tested and answered long ago. Don't get me wrong, there are some that haven't yet and which Cuchaz is actually in the process of solving, for which the old CC guard and all of you should be very grateful for.
[EDIT***] Sorry, I again updated a paragraph of the main post above the first EDIT. It was all in the second paragraph of what I wrote this time though.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
I don't know if it has already been asked, but as soon as I saw the latest video, I started thinking about rendering, because the thing is that if you're super duper high, you'll see the moon/sun while looking at your feet (if you're falling).
I might have found a way to solve that problem: what if your code detected when surface chunks become invisible to a person that's over them, and, since they will not be updated while unloaded, what you would have to do is only "save" their render, and show it to the player, so he can have a look at them.
I don't know, maybe it would add a lot of lag, but I propose something. =)
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =)
Current number of corrected posts/things: 7
Anyway, Frostbyte is (was?) working on a method of increasing the view distance as much as 16x without increasing lag, using a special long-distance rendering system, you could potentially use that to render the ground below someone. I can't remember if we planned to use that to render a planet's surface from orbital altitudes, or a different system using bump mapping, I'd have to check.
Also, as far as I remember we weren't going to have a entire solar system be a actual world, it was going to be a void that had seperate, interacting dimensions(ships, planets) floating in it. This is from memory ofc, I might be wrong, but then again I'm not sure we even actually decided since the mod's been progressing at the pace of a slug, riding a snail, riding a turtle(that's frozen solid).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere's not much difference. 16m blocks is the highest I can go right now without using more than 64bits to represent a cube coordinate (dimension, x, y, z). That's the limitation on height/depth right now. But it's so huge, it might as well be infinite. I doubt anyone would spend the tens of hours it would actually take to fly that far in the game.
Sure. Here's what I have so far:
Yeah, we're planning to add nice polish features like configurable limits.
Yup, there's no difference in performance if you take an engine that can handle 16m blocks and cut it down to 8m.
Hi Martititi!! =D
Fixing sky rendering is one of the things on our todo list. Basically, the sun and moon should never be at your feet.
We'd eventually like to do some fancy visibility calculations too (so we can do cool things like render the ground when you're waaaay up high), but an effective and general solution to that problem is pretty complicated. It's going to take some time to design some algorithms and test them out.
Tens of hours is a bit of an understatement... more like tens of days.
Even if you ~fell~ from y=8m, it would still take an entire day before you hit the ground at ~y=0.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Having worked on a 40k x 40k map using one byte of DEM data per block, I have to say that the difference in height between the plains and mountains is...meh. It works, but it's less than desirable. The 40k x 40k represented around 1500 miles x 1500 miles, or around 1:60 scale...in the HORIZONTAL. The 256 blocks of height was representing sea level up to ~8k meter mountains, or ~1:30.
When I originally started the map I was shooting for 80k x 80k (~1:30), and the fact that the horizontal was stretched out 2x made the vertical SEEM more appropriate. It actually looked BETTER that way. Which makes sense, the two scales being about the same. I ended up going with 40k for practical reasons: my rig took 4x longer to export each section at 80k. Heh.
But anyway, still less than impressive in actuality. It was cool, standing on the plains looking way up at the mountain tops, but could have been better.
Take that concept and extrapolate with me for a minute though...what if the vertical was 512? 1024? The vertical height differences would be way more spectacular but...is there a point where having TOO much vertical detail is BAD? Is there a sweet spot? And what about render distances? If we had a 1:1 vertical, the mountains would be 8000 blocks above the plains. Can we honestly render 8000 blocks away in realtime yet? Not even close!
So I guess that's what I *meant* to ask. Do we really NEED all that space? Just because we can have it doesn't mean it'll be fun!
Or practical.
Well...
Being able to build as high as you want = good. Having terrain that misuses the vertical space, looks hideous, and makes it almost impossible to have fun exploring? That's not so good. Luckily, we can have lots of building space and perfectly reasonable terrain
In other words; I agree that there will be a sweet spot (or a couple of sweet spots) for the terrain scale. Not too huge, not too flat, etc. The available building space is a different matter however; extra space won't bother you when you don't need it, but we all know how irritating the vanilla height limit can be when we want to build something big.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Though, it seems to me that you are discussing about optimizations about blocks' coordinates in order to place them correctly.
I had an idea about it, and it might also be yours. By reading this:
the idea popped up in my mind: what if you did some kind of chunk coordinates, and then tell the blocks that are in the chunk: inside the chunk, you have another coordinates.
I mean: supposing you have a chunk coordinate: x=1; y=1; z=1
Inside this chunk, every block will have coordinates inside the chunk, for example (if there is no 0-position in the chunk) the
bottom-front-left corner block would be at x=1: y=1; z=1.
Though, in this chunk, you would not have values exceeding 16, since the blocks coordinates doesn't apply outside the chunk.
I guess it would be less demanding on memory.
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =)
Current number of corrected posts/things: 7
also you should check out Link Removed
- inside the chunk, you would need to store a value that cannot go over 16 ==> you would need only 5 bits to store it
- in the real world (so, outside any chunk), you would divide the number of coordinates by 16, because blocks don't need a personal coordinate...
A Rocket Science tester and engineer. Well, at least when it will be released. =)
I'm French so English is not my native language. Please correct me when I make a mistake and don't worry for me, it will be even better. Thanks in advance! =)
Current number of corrected posts/things: 7
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is a fantastic optimization! Minecraft already does this. =)
Tall Worlds Mod uses a completely different mod loader than, say, a mod pack full of Forge mods. You can't just add it to an existing mod pack and expect it to work properly.
...
Okay, I'm alright.
Here's a question: Say I wanted to make a mod that adds some tall or deep worldgen complicit with Tall Worlds' extended height limits. Would I need to make this mod using M3L? What about if it's an addon to a pre-existing Forge mod?
In short, under what conditions would I need to use your M3L for my mod to ensure compatibility with Tall Worlds?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThese are fantastic questions. I don't even know the answers to them yet.
Here's my long-term plan for M3L.
The plan is for M3L to get rid of the need for Forge core mods. This should hopefully reduce the number of inter-mod compatibility issues overall. M3L should be able to run along-side of Forge and all its loaded mods. ie, you should be able to run M3L mods and Forge mods at the same time. You could even run Forge core mods too, but I wouldn't recommend it. Core more are too unpredictable and neither M3L nor Forge can guarantee that bad things won't happen.
Tall Worlds is the world's first mod built on M3L. If you build a mod on top of M3L, it will certainly be compatible with Tall Worlds.
If you build a mod on Forge, and try to interact with a mod on M3L, it should theoretically be possible. All the needed classes should be loaded in the same class loader, but there might be some issues with class load order.
Ermm... that was a bit technical. What I mean is, mods from the two ecosystems might be able to talk to each other, but it will take some extra work.
It isn't, AFAIK. Doesn't it affect mob spawning, grass propagation, crop/sapling growth, daylight sensor output, snow buildup, enderman behavior...?
"Oops, I climbed too high and generated the ceiling! Now my flowers are gone, my sheep are naked, and a creeper's on the roof!"
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhen that actually happens, I hereby give you permission to come back here and say I told you so. =P