Giant cave systems can be worried about later. I'm suggesting sticking with the current generation methods and basicly dropping the bottom out of the world. Just to get the ball rolling faster. The easier it looks like to implement, the more likely Mojang will do it.
Mojang(or at least some of mojang) has already stated that they will not even look at it as a viable system until the giant cave issue is solved.
Thank you for the quick replies, everything works now.
I have noticed that when using the area ability, that it does not recognize up or down as directions.
Have you thought of changing the direction of forward to be based on the side of the block clicked instead of the direction the player is facing?
He should also read the part about keeping shadow maps stored as part of the chunk, and acceptable compromises for an inherently imperfect situation.
However those shadow maps only exist for loaded chunks, which if the caves roof has never been loaded would be a giant bug in the lighting system and unacceptable since mojang will only seriously consider this if it is as functional as the current lighting system.
There seems to be an issue with adding items to the S:CreatableItems section. It recognizes that there is an input, but the item image does not display and it is not selectable. Also does it support metadata?
If the overhang is that far away it stops being a meaningful shadow source anyway since ambient light would bleed in.
The solution is "close enough". There's no perfect solution to this issue, so the real question is where do you make sacrifices to reach a "close enough" decision.
On a default minecraft server, the load distance around a player is 10 chunks(160 meters). A giant overhang 160 meters above you would make a shadow.
Not exactly true. There are different sizes of infinity when you get into the math. Anyway, not the point.
As I said, by having a fixed maximum height at 0, it allows a shadow map to be saved with each chunk. The shadow map itself just has to be two dimensional reflecting the bottommost light level. When a chunk generates, it only has to look at the shadow map above itself, it doesn't have to calculate any higher than that.
When a shadow map updates, it can poll the neighbor below it to recalculate. If that neighbor's shadow map doesn't change as a result then the update ends, otherwise it continues through any loaded chunks.
When a chunk loads, it checks the shadow map above it and recalculates if necessary. Keeping things always up-to-date.
The updates can be done in columns so that if only say 2 blocks on the shadow map change, the entire chunk doesn't have to recalculate, only the effected columns.
The increase in data size, assuming 16x16 chunk with 16 light levels is only 128bytes per chunk.
not a perfect solution, but certainly one that handles "infinity" quite well as long as you know where the ceiling is (0 depth)
While infinite is thrown around a lot, the world limits are actually +-32,000,000 in all directions with cubic chunks, making the ceiling 32,000,000, that is why offsetting terrain does not make a difference as we already have a clear ceiling and floor for handling shadows from.
The shadow solution does not work in the event of massive overhangs outside of chunk distance that the player has yet to visit(since the chunks don't exist yet.)
And that brings up another possibility that could help with the lighting.
Use infinite height only in one direction; downward
So the ceiling is height 0, and as you move down the value goes up (depth meter basically) with no possibility for negative height value.
This would allow for keeping vanilla style light calculations that just need to be saved per-cube so that the entire column doesn't have to be calculated constantly.
Then different generators can use different sea levels to give you 128, 256, 512 or whatever blocks of surface, floating islands, etc before beginning the infinite abyss
Infinite height is infinite height no matter how you offset it. If a generator starts you off at 20km below 0, with sky islands, it runs into the same exact issue as having the world spawn you at 0 and having a a negative depth and positive height with sky islands.
Best suggestions so far are using LoD to render distant chunks, with shadows being based off those; and/or using vertical chunk compression in relation to solid and empty.
Sure with current vanilla generation; however, if they added any sort of generation that exceeds those specifications, they have to change the system to work with it. That is why the system must work from anywhere, at any time in the map, with any mod(modding api).
I'm afraid to unpause my game until I figure this out.
I'm using a bit of mods with this one. Two noteworthy mods are Ars Magika 2 and Biomes O Plenty. I was flying around, mapping out the continent to see if the Taint was bad in the whole thing. I dropped my map, and went down to grab it. I grabbed it, and this appeared:
I took a screenshot to make sure it wasn't a Magical Forest biome. It's a Pech Stalker BTW if it changes anything.
Edit: If you see on the minimap, there's a second Pech. I really want to know why they're more common in the Fungi Forest biome than a flipping Magical Forest Biome.
Second Edit: I unpaused and threw my diamond pick at it. I'm going to try to use a lead and get him to my base.
Fungi Forest is a magical biome if I remember correctly.
The mod has a reason though. Mojang has heard about this engine, but they discarded it with concerns about lighting issues (Yeah right...) so Barteks is making a proof of concept to send to Mojang to show how not buggy this engine can be.
The lighting issues are actually the last issue that many of the people on this thread are trying to overcome.
The lighting system must work for the following:
It must work at any height or depth using the same method.
It must it has to be able to handle situations where overhangs are above the player but outside load range.
*A cavern taller then the load range would be full of daylight if the current minecraft system was used.
It must have less bugs then the current minecraft lighting system.
Point 2 is where all the issues are located. So far, using a lod system to render/check far away chunks has been agreed to be the best method, but until the mod is actually finished, we can't be sure of the results.
I would like to recommend that ore blocks have twice the cost as their ingot/gem forms, as otherwise you get an infinite loop using pretty much any tech mod.
Scan 20 gold ores, create as many gold ores as possible, throw in "insert grinding machine here", smelt into ingots, feed to amulet, spawn twice as many gold ores as you started with, repeat.
For a NullPointerException to have occurred where it did the item it was trying to craft mustn't have existed.
The most likely reason for that to happen would be an incorrect recipe definition in "config/MPB_values/default 1.6.4.drd", probably caused by block of reactivity's item id changing since the file was created.
If you delete that file it will be recreated when you next run Minecraft, which should fix the issue.
I just checked the source code for NEI and if a recipe component doesn't exist it will substitute that component with fire; So the recipe for crafting blocks of reactivity is invalid and deleting your .drd file should fix it.
since phials now seem to return empty when you use them on jars, instead of being consumed
(unless that was a bug, and not intended. but i noticed, that i got my phials back after using them.)
I have always received my phials back, so I think you either experienced a bug in which you did not recieve them back, or just never noticed(unlikely).
0
Mojang(or at least some of mojang) has already stated that they will not even look at it as a viable system until the giant cave issue is solved.
0
Thank you for the quick replies, everything works now.
I have noticed that when using the area ability, that it does not recognize up or down as directions.
Have you thought of changing the direction of forward to be based on the side of the block clicked instead of the direction the player is facing?
0
However those shadow maps only exist for loaded chunks, which if the caves roof has never been loaded would be a giant bug in the lighting system and unacceptable since mojang will only seriously consider this if it is as functional as the current lighting system.
0
S:CreatableItems <
1x264
1x266
1x265
1x388
1x331
1x397:0
1x397:1
1x368
1x369
>
0
On a default minecraft server, the load distance around a player is 10 chunks(160 meters). A giant overhang 160 meters above you would make a shadow.
0
While infinite is thrown around a lot, the world limits are actually +-32,000,000 in all directions with cubic chunks, making the ceiling 32,000,000, that is why offsetting terrain does not make a difference as we already have a clear ceiling and floor for handling shadows from.
The shadow solution does not work in the event of massive overhangs outside of chunk distance that the player has yet to visit(since the chunks don't exist yet.)
0
Infinite height is infinite height no matter how you offset it. If a generator starts you off at 20km below 0, with sky islands, it runs into the same exact issue as having the world spawn you at 0 and having a a negative depth and positive height with sky islands.
Best suggestions so far are using LoD to render distant chunks, with shadows being based off those; and/or using vertical chunk compression in relation to solid and empty.
0
Sure with current vanilla generation; however, if they added any sort of generation that exceeds those specifications, they have to change the system to work with it. That is why the system must work from anywhere, at any time in the map, with any mod(modding api).
0
Fungi Forest is a magical biome if I remember correctly.
0
The lighting issues are actually the last issue that many of the people on this thread are trying to overcome.
The lighting system must work for the following:
- It must work at any height or depth using the same method.
- It must it has to be able to handle situations where overhangs are above the player but outside load range.
*A cavern taller then the load range would be full of daylight if the current minecraft system was used.
- It must have less bugs then the current minecraft lighting system.
Point 2 is where all the issues are located. So far, using a lod system to render/check far away chunks has been agreed to be the best method, but until the mod is actually finished, we can't be sure of the results.0
Scan 20 gold ores, create as many gold ores as possible, throw in "insert grinding machine here", smelt into ingots, feed to amulet, spawn twice as many gold ores as you started with, repeat.
0
Ah, thank you, did not notice that folder there.
0
I have always received my phials back, so I think you either experienced a bug in which you did not recieve them back, or just never noticed(unlikely).
0
Looking through nei at the recipes, it shows that an iron ingot+amulet makes fire(block 51).
0
Here you go: The Barrels Mod, Just Barrels and Nothing else!