Well after messing around for about a day, I finally got the foundation for a finite water imitation...
So far, I took a vanilla minecraft jar into the mcp, tweaked the BlockFlowing file and was able to get full finite water action.
I do need to learn how to use forge... however I'm not sure if forge would be able to work with a mod like this... does anyone have any experience with forge and mods which change core game files?
TL;DR
I've taken the first step towards copying this mod in 1.4.7.
Making the naturally occurring, and placed water finite.
wow, thanks for taking your time for this mod
i got no idea how forge works. maybe the peopel on the forge forums can help out. it would be a real shame if they wouldn't help you on this.
good luck and keep it up
You don't have to convert to Forge. I still prefer ModLoader over Forge. Why waste a week porting to Forge when you can spend a few hours updating the mod?
ModLoader mods are usually compatible with Forge.
I don't know if you can use this mod along with Forge.
You don't have to convert to Forge. I still prefer ModLoader over Forge. Why waste a week porting to Forge when you can spend a few hours updating the mod?
ModLoader mods are usually compatible with Forge.
I don't know if you can use this mod along with Forge.
I've messed with making my previous mods work with forge and it's a pain.
Not worth it IMO, but it's hard to deny the role forge now plays in the modding community.
wow, thanks for taking your time for this mod
i got no idea how forge works. maybe the peopel on the forge forums can help out. it would be a real shame if they wouldn't help you on this.
good luck and keep it up
I've finished work on water pressure
It's not 100% realistic, since the water can't seem to level out 100%...
I now need to work on the "ocean" water as it OBVIOUSLY can't also be finite, as that would cause MASSIVE lag.
I also need to make it so that single water tiles can flow downhill... but that's something less important >.>
I now need to work on the "ocean" water as it OBVIOUSLY can't also be finite, as that would cause MASSIVE lag.
I also need to make it so that single water tiles can flow downhill... but that's something less important >.>
Well, you could make ocean water finite as well and still avoid lag by using block-update triggers as opposed to always processing on ticks.
Off the top of my head, something to this effect should be possible:
Blocks
Two finite liquid block types, and active and a passive.
The active is your normal finite liquid, processing on ticks to determine how to flow, etc.
The passive is your "at rest" finite liquid, and has no processing on ticks, but only on block updates (like sand).
The Cycle
Active liquid attempts to flow as per normal. If it cannot find anywhere to go for three (or such) consecutive ticks, it turns into passive liquid.
Passive liquid has no processing on world ticks (and thus no lag impact), but instead turn back into active liquid when an adjacent block sends a block update.
Active will flow until it cannot anymore, turn back to passive, and repeat the cycle.
This would probably be the best way forward, as you then do not need to determine when a body of water is "too large" to be finite, nor do you need to cater for players creating massive bodies of finite water. Finite liquid would only process when needed.
You could do it with only one block, and setting an "at rest" flag. If the flag is set, it does not attempt to flow. On an adjacent block update the flag is reset.
Might have an impact on lag as each block would have to on ticks check the flag and decide not to do anything (which is not a lot of processing, but is something).
Anyway, it is awesome that you are working on this. I'd love to have this mod updated to 1.4.7.
Hey man
Thanks for the feedback... I like the idea, as that would in fact save on lag, and I will probably do that....
HOWEVER... I doubt I will do that with oceans... Do you know why?
Because of [ocean]-[cave] connections. If I use normal finite water as you said it would save on lag.
All the way up to the point where any flowpath is opened in the ocean floor to any cavesystem.
The cavesystem would flood, which is cool, however the water would come from the finite ocean, which would at first be fine until the low volume water wave propagated ever outward until literally the entire generated proximal ocean was updating...
RAMBLE BEGIN
My choices are... 1) Leave all water as finite, instead doing everything I can to decrease lag [likely decreasing the possible number of states] 2) Figure out some elaborate and exploitable way to make large bodies of water act like infinite water. 3) Make all water generated in ocean/river biomes infinite water.
I'm still working on the finite water, figuring out faster and faster ways of it spreading accurately, and take up less cpu-time.
You may wonder why spread speed was included, and the answer is simply that...
Assuming the per tick script takes the same amount of "cpu" time, the only remaining factor for large scale water activity is ticks till equilibrium.
Of coarse I have an odd idea for how to fix the ocean floor problem..
1 way would cause water which flowed from a 15 pressure water block downward to instead not remove water from that block...
The water block would need to create some kind of entity or something...
Let's call it an air bubble ;D
Then when the air bubble hit anything other that the fluid it traveled through, it would decrease the top water blocks water value...
This would strangely help with lag as even though all of the blocks would still need updating.
The update wave would propogate from the surface.
This would result in a lower number of ticks before equilibrium.
The reason has to do with the 3 phase process vs the current 4 phase..
1) Water levels from the bottom pull water in an ever increasing area to compensate.
The lower pressures moving up to the surface.
2) Surface water levels drop pulling nearby surface water inward.
3) Surface water levels return causing pressure to travel downward.
4) Increased pressure at the bottom results in a greater capacity for the surface to pull nearby water...
The water bubble tactic might allow the process to start 1 phase ahead.
Skipping the upward propagation entirely.
RAMBLE END
Anyway, which way do you think would play the best, and which way would perform the best
1) Finite water with complexity scrapped in order to allow finite water everywhere.
2) Finite water everywhere except massive water sources [mainly ocean biomes]
3) Finite water everywhere except with all water beneath other waters creating bubbles to simulate downward flow.
4) Finite water tuned to perform as best as possible, however leaving some ocean regions unusable due to lag.
I WILL be using your idea
I've chosen to make it so, if a water block doesn't change levels, it has a random chance to turn still.
I might even make the change 100% as nearby blocks would continue shifting around water if there was any imbalance.
I could even just use the old "source" blocks as the non-update blocks.
having the oceans made of finite water has its flaws:
1. if water flows into the ocean, it will raise ocean level (rainwater) until there's no more land to be seen
2. ocean water would be calculated permanently and take much CPU usage
making oceanwater spread by placing another oceanwaterblock to any empty direction is a bad solution, because it causes the tiniest leak to cause a structure to be flooded even if the leak gets closed within seconds, as if even one ocean block leaked through, there's an infinite oceanblock in the cave/mine/tunnel/ravine, which will continue filling up the cave/mine/tunnel/ravine.
djoslin already solved that by setting a limit for finite water. when finite water of that amount is connected, it will turn into infinite (ocean) water. and ocean water is limited to not raise above vanilla oceanlevel. finite water flowing into/onto oceanwater will be consumed by the oceanwater and cant raise the oceanlevel any further.
i hope that helps you figuring how to realise this project
also i've already written some concepts of how oceanwater could spread without creating any leaks that keep spreading oceanwater after closing a leak.
As always, this is your show. I'm just throwing ideas out there.
I have to admit I haven't looked deeply at the finite liquid mechanics, and how pressure works, so my understanding might be entirely incorrect. The assumptions I work on are:
A finite liquid block has a integer value called pressure.
A finite block 'flows' by balancing its pressure with adjacent blocks. It can only do so with finite liquid blocks of the same kind of liquid, and with air.
When balancing with a block on the same y-level, a pressure difference of 1 is seen as the same pressure and will not try to balance.
A finite block has some integer natural pressure limit, meaning that if the pressure is above this, it can propagate upwards.
A finite block can otherwise only propagate sideways and down, with priority on down (gravity my old nemesis, we meet again).
A finite block becomes 'passive' if its pressure has not changed recently (i.e. had nothing to do).
A finite block that receives a block update, becomes 'active', but will only issue its own block updates to adjacent blocks if it actually changes state. (I.e. I only wake up the blocks around me if I find I can in fact do something with my pressure. Otherwise, I let sleeping water lie, and so, prevent the update calls of propagating unnecessarily.)
The summary of the balancing mechanic being:
If allowed, give as much possible pressure to the block below (Gravity) to get it up to its natural pressure limit.
If own pressure is 0, then become an air block and stop processing.
Else, balance pressure between self and all four adjacent blocks (or as many of them as allowed).
Then, if above natural pressure limit, balance with block above, using only the pressure over natural limit.
Because of [ocean]-[cave] connections. If I use normal finite water as you said it would save on lag.
All the way up to the point where any flowpath is opened in the ocean floor to any cavesystem.
The cavesystem would flood, which is cool, however the water would come from the finite ocean, which would at first be fine until the low volume water wave propagated ever outward until literally the entire generated proximal ocean was updating...
Yes, indeed. I had not considered that.
Some things are in your favor though.
Firstly, the number of 'active' finite liquid blocks will be determined by the size of the cave opening. A small opening will only have a small number of updating liquid blocks.
Secondly, unless you attempt to balance pressure over large distances, but only with adjacent blocks and not allowing fractions of pressure, you will get a 'stable' (all blocks back to passive) without having to update the whole ocean. This assumes you are happy with the compromise of having an 'indent' in surface water, where the pressure was (at the end of it all) taken from to fill the cave. Again, size of indent depends on the cave size.
Personally, I have no problem with this. It is Minecraft, so some oddities are allowed... and fun. Also, fully simulating fluid dynamics is one of the most CPU intensive processes out there. So K.I.S.S. (Keep It Simple Stupid) makes sense.
Thirdly, if you give priority to gravity (i.e. you start block update triggers with the block above yourself). Then the low pressure wave will only propagate on the surface of the body of water. And only far enough to 'make up' for the 'lost' water. (I.e. once you get to the point where the pressure difference is 1 or less, you cannot balance anymore, and therefore stop issuing block updates. Allowing everything to return to passive.)
And even if you don't, if you do not allow pressure balances of less than 1 (integers used for pressure), it should even out in an area, rather than the entire body of water.
Example: Assume water's natural pressure is 15. If you remove a block at the bottom of the body of water. Only 1 pressure needs to be 'taken' from 15 nearby water blocks in order to make up for the 'missing' water. In fact, since balances of less than 1 is not allowed, it will stabilize at 14, thus only needing 1 pressure from 14 nearby blocks. The outer edges of this 'low pressure bubble' will ask their adjacent water to update, but since the balance is less than 1, nothing will happen, the water will go back to passive, and the cascading update calls will cease.
The only update calls that will carry on, are for those block above, that through gravity, can add that 1 pressure to the blocks below (i.e. gravity does not balance, it tops-up). But again, once you reach the surface, no more pressure changes, thus no more update calls. Thus no updating the whole ocean.
A truly gigantic cave might still cause lag by needing large volumes of water to fill it up.
having the oceans made of finite water has its flaws:
1. if water flows into the ocean, it will raise ocean level (rainwater) until there's no more land to be seen
..snip..
djoslin already solved that by setting a limit for finite water. when finite water of that amount is connected, it will turn into infinite (ocean) water. and ocean water is limited to not raise above vanilla oceanlevel. finite water flowing into/onto oceanwater will be consumed by the oceanwater and cant raise the oceanlevel any further.
Ooh... I had not considered that.
A small compromise to the method of djoslin might let it work with finite water though.
In real life rain effectively comes from water taken from the oceans to start with.
So in the game we could make a compromise and say: "If water flows down to the ocean y-level (64 I think) and it flows into an existing body of water at least X blocks big, then instead of forming a new block atop that 'ocean/large lake/river' at ocean level water, it gets deleted."
In short, we pretend that the rain water came from that body of water to start off with, and after topping off the body of water, we just delete all excess.
This would allow for the following:
Other than the y-64 rule, no need for any other special handling of finite liquids.
You could still use finite water for all large bodies of water, ocean / lakes / or rivers.
If someone drains out a body of water (and given it is finite, they can) it will top back up when it rains, but cap itself at y-level 64.
You do not have any of the problems that comes from infinite water sources.
We only need to cap at y-level 64, because even if water is added from below, it will eventually propagate up to y-level 65, and thus be subject to the deletion as per the normal y-64 rule.
New lakes/oceans could form, even in hollowed out quarries. And will cap themselves at y-level 64. Adding a new neat mechanic to protect low-lying housing, caverns, etc. against.
Similarly, caves will only even possibly fill up to y-level 64, so will not flood the world.
In the end, some compromises must be made, because of silly limitations such as CPU power. (WHY U NO QUAMTUM-COMPUTE?!!)
But overall I think you can get still-truly-awesome-finite-liquid-mechanics.
[Ocean overfill from rain]
Well no, if I would have rain depositing, which I may once I figure it out, I would have the rain come from evaporation.
Lag is however the biggest REAL reason I have for not making oceans finite, due to undersea flooding.
[Lag from oceans]
ACTUALLY, oceans only lag when something is updating.
I've flown over a huge ocean area, and messed around with placing water to check for lag.
The only ocean oriented lag comes specifically from the ocean flooding underground caves and cave-ins.
This on top of my implementing the non-constant updating should prevent that problem.
[Ocean spread]
NO, I don't plan on making ocean blocks replicate.
If I go with the ocean block idea, Implement simple de-ocean-ing rules...
However I would not allow ocean tile replication.
[PRESSURE]
Water blocks normally can have a value from 0-8 [0 being empty, and 8 being full]
If a water block has water above it, and that water is filled above a certain level.
The lower block can exceed it's normal max value of 8.
So if you place a water block above another, their values will become 9 and 7.
[UNDERSEA PROBLEM]
When an opening appears in the bottom of the ocean.
It allows water blocks to move their contents downward.
This then decreases their value, which triggers nearby block to flow into them.
The nearby blocks value being lower causes nearby blocks to flow into them...
You see the pattern?
Well it creates a low pressure wave which rapidly moves upward.
The number of updates required to find pressure equilibrium is enormous in an ocean.
[RAIN]
Well I honestly think the best solution is simply to create ocean blocks which absorbs finite water blocks.
and if i told you, that i stil lwant some small lakes and ponds above level 64? that would be absolutely impossible when you cap water above level 64.
having infinite oceanwater is no problem at all, if it does never spread upwards and if it gets converted into being finite water when the mass gets reduced/it gets seperated into smaller bodies of water.
also if you have finite oceanwater, a cavein will lead to a wave of computed blocks that might expand really fast and crash the server.
and if i told you, that i stil lwant some small lakes and ponds above level 64? that would be absolutely impossible when you cap water above level 64.
having infinite oceanwater is no problem at all, if it does never spread upwards and if it gets converted into being finite water when the mass gets reduced/it gets seperated into smaller bodies of water.
also if you have finite oceanwater, a cavein will lead to a wave of computed blocks that might expand really fast and crash the server.
YOU ARE ABSOLUTELY RIGHT
I'm working on making oceans into infinite NON-DUPLICATING water sources.
Having the ocean finite results in giant low pressure waves to travel up and outward across the ocean.
they still have to be duplicating, but by filling up adjacent air blocks with finite water. that way the adjacent block will fill up until its a full nonflowing waterblock and then turns into an infinite oceanwater block and if it flows into a cave or mine, it will always try to fill that block again and again and never finish, so it wont convert that airblock into an infinite ocean block.
if you have the ocean nonduplicating, what will happen if you dig on the coastline - water next to air not flowing there like being held back by some invisible wall...
they still have to be duplicating, but by filling up adjacent air blocks with finite water. that way the adjacent block will fill up until its a full nonflowing waterblock and then turns into an infinite oceanwater block and if it flows into a cave or mine, it will always try to fill that block again and again and never finish, so it wont convert that airblock into an infinite ocean block.
if you have the ocean nonduplicating, what will happen if you dig on the coastline - water next to air not flowing there like being held back by some invisible wall...
I don't think you understood what I meant
The ocean blocks would fill air blocks with finite water blocks...
The ocean block would not turn any blocks into ocean blocks...
This would allow for the ocean to flood a cave without severe lag, and without filling it with ocean blocks.
I might allow oceanification under very specific circumstances, and deoceanification under more common circumstances.
I can't use the mod... Making what the video says doesn't work, the screen is black when I log in or play offline. What may be the problem? I wanted to test a specific flux paradox, and found out that this would be perfect for that, once Minecraft is not limited to conservation of energy, and this is a 3D fluids simulation, so it's perfect...
Tried in both most recent and recommended version (1.4.7 and 1.3.2), neither of them work when I add modloader and the mod (also doesn't work with forge, sad).
As @pvt._Pirate said; Instead of simply "porting" it to the latest version of minecraft, the mod would probably be better off with a complete rewrite.
In that case, I don't think you need anyone's permission at all, since the code would be yours.
Yeah, not noticed it.
In that case, need much more time, that just update code in mod.
i ponder whether to do
So far, I took a vanilla minecraft jar into the mcp, tweaked the BlockFlowing file and was able to get full finite water action.
I do need to learn how to use forge... however I'm not sure if forge would be able to work with a mod like this... does anyone have any experience with forge and mods which change core game files?
TL;DR
I've taken the first step towards copying this mod in 1.4.7.
Making the naturally occurring, and placed water finite.
i got no idea how forge works. maybe the peopel on the forge forums can help out. it would be a real shame if they wouldn't help you on this.
good luck and keep it up
ModLoader mods are usually compatible with Forge.
I don't know if you can use this mod along with Forge.
I've messed with making my previous mods work with forge and it's a pain.
Not worth it IMO, but it's hard to deny the role forge now plays in the modding community.
I've finished work on water pressure
It's not 100% realistic, since the water can't seem to level out 100%...
I now need to work on the "ocean" water as it OBVIOUSLY can't also be finite, as that would cause MASSIVE lag.
I also need to make it so that single water tiles can flow downhill... but that's something less important >.>
Well, you could make ocean water finite as well and still avoid lag by using block-update triggers as opposed to always processing on ticks.
Off the top of my head, something to this effect should be possible:
Blocks
Two finite liquid block types, and active and a passive.
The active is your normal finite liquid, processing on ticks to determine how to flow, etc.
The passive is your "at rest" finite liquid, and has no processing on ticks, but only on block updates (like sand).
The Cycle
Active liquid attempts to flow as per normal. If it cannot find anywhere to go for three (or such) consecutive ticks, it turns into passive liquid.
Passive liquid has no processing on world ticks (and thus no lag impact), but instead turn back into active liquid when an adjacent block sends a block update.
Active will flow until it cannot anymore, turn back to passive, and repeat the cycle.
This would probably be the best way forward, as you then do not need to determine when a body of water is "too large" to be finite, nor do you need to cater for players creating massive bodies of finite water. Finite liquid would only process when needed.
You could do it with only one block, and setting an "at rest" flag. If the flag is set, it does not attempt to flow. On an adjacent block update the flag is reset.
Might have an impact on lag as each block would have to on ticks check the flag and decide not to do anything (which is not a lot of processing, but is something).
Anyway, it is awesome that you are working on this. I'd love to have this mod updated to 1.4.7.
It's the flying cutlery that stresses me out.
Hey man
Thanks for the feedback... I like the idea, as that would in fact save on lag, and I will probably do that....
HOWEVER... I doubt I will do that with oceans... Do you know why?
Because of [ocean]-[cave] connections. If I use normal finite water as you said it would save on lag.
All the way up to the point where any flowpath is opened in the ocean floor to any cavesystem.
The cavesystem would flood, which is cool, however the water would come from the finite ocean, which would at first be fine until the low volume water wave propagated ever outward until literally the entire generated proximal ocean was updating...
RAMBLE BEGIN
My choices are...
1) Leave all water as finite, instead doing everything I can to decrease lag [likely decreasing the possible number of states]
2) Figure out some elaborate and exploitable way to make large bodies of water act like infinite water.
3) Make all water generated in ocean/river biomes infinite water.
I'm still working on the finite water, figuring out faster and faster ways of it spreading accurately, and take up less cpu-time.
You may wonder why spread speed was included, and the answer is simply that...
Assuming the per tick script takes the same amount of "cpu" time, the only remaining factor for large scale water activity is ticks till equilibrium.
Of coarse I have an odd idea for how to fix the ocean floor problem..
1 way would cause water which flowed from a 15 pressure water block downward to instead not remove water from that block...
The water block would need to create some kind of entity or something...
Let's call it an air bubble ;D
Then when the air bubble hit anything other that the fluid it traveled through, it would decrease the top water blocks water value...
This would strangely help with lag as even though all of the blocks would still need updating.
The update wave would propogate from the surface.
This would result in a lower number of ticks before equilibrium.
The reason has to do with the 3 phase process vs the current 4 phase..
1) Water levels from the bottom pull water in an ever increasing area to compensate.
The lower pressures moving up to the surface.
2) Surface water levels drop pulling nearby surface water inward.
3) Surface water levels return causing pressure to travel downward.
4) Increased pressure at the bottom results in a greater capacity for the surface to pull nearby water...
The water bubble tactic might allow the process to start 1 phase ahead.
Skipping the upward propagation entirely.
Anyway, which way do you think would play the best, and which way would perform the best
1) Finite water with complexity scrapped in order to allow finite water everywhere.
2) Finite water everywhere except massive water sources [mainly ocean biomes]
3) Finite water everywhere except with all water beneath other waters creating bubbles to simulate downward flow.
4) Finite water tuned to perform as best as possible, however leaving some ocean regions unusable due to lag.
I WILL be using your idea
I've chosen to make it so, if a water block doesn't change levels, it has a random chance to turn still.
I might even make the change 100% as nearby blocks would continue shifting around water if there was any imbalance.
I could even just use the old "source" blocks as the non-update blocks.
1. if water flows into the ocean, it will raise ocean level (rainwater) until there's no more land to be seen
2. ocean water would be calculated permanently and take much CPU usage
making oceanwater spread by placing another oceanwaterblock to any empty direction is a bad solution, because it causes the tiniest leak to cause a structure to be flooded even if the leak gets closed within seconds, as if even one ocean block leaked through, there's an infinite oceanblock in the cave/mine/tunnel/ravine, which will continue filling up the cave/mine/tunnel/ravine.
djoslin already solved that by setting a limit for finite water. when finite water of that amount is connected, it will turn into infinite (ocean) water. and ocean water is limited to not raise above vanilla oceanlevel. finite water flowing into/onto oceanwater will be consumed by the oceanwater and cant raise the oceanlevel any further.
i hope that helps you figuring how to realise this project
also i've already written some concepts of how oceanwater could spread without creating any leaks that keep spreading oceanwater after closing a leak.
I have to admit I haven't looked deeply at the finite liquid mechanics, and how pressure works, so my understanding might be entirely incorrect. The assumptions I work on are:
A finite liquid block has a integer value called pressure.
A finite block 'flows' by balancing its pressure with adjacent blocks. It can only do so with finite liquid blocks of the same kind of liquid, and with air.
When balancing with a block on the same y-level, a pressure difference of 1 is seen as the same pressure and will not try to balance.
A finite block has some integer natural pressure limit, meaning that if the pressure is above this, it can propagate upwards.
A finite block can otherwise only propagate sideways and down, with priority on down (gravity my old nemesis, we meet again).
A finite block becomes 'passive' if its pressure has not changed recently (i.e. had nothing to do).
A finite block that receives a block update, becomes 'active', but will only issue its own block updates to adjacent blocks if it actually changes state. (I.e. I only wake up the blocks around me if I find I can in fact do something with my pressure. Otherwise, I let sleeping water lie, and so, prevent the update calls of propagating unnecessarily.)
The summary of the balancing mechanic being:
If allowed, give as much possible pressure to the block below (Gravity) to get it up to its natural pressure limit.
If own pressure is 0, then become an air block and stop processing.
Else, balance pressure between self and all four adjacent blocks (or as many of them as allowed).
Then, if above natural pressure limit, balance with block above, using only the pressure over natural limit.
Yes, indeed. I had not considered that.
Some things are in your favor though.
Firstly, the number of 'active' finite liquid blocks will be determined by the size of the cave opening. A small opening will only have a small number of updating liquid blocks.
Secondly, unless you attempt to balance pressure over large distances, but only with adjacent blocks and not allowing fractions of pressure, you will get a 'stable' (all blocks back to passive) without having to update the whole ocean. This assumes you are happy with the compromise of having an 'indent' in surface water, where the pressure was (at the end of it all) taken from to fill the cave. Again, size of indent depends on the cave size.
Personally, I have no problem with this. It is Minecraft, so some oddities are allowed... and fun. Also, fully simulating fluid dynamics is one of the most CPU intensive processes out there. So K.I.S.S. (Keep It Simple Stupid) makes sense.
Thirdly, if you give priority to gravity (i.e. you start block update triggers with the block above yourself). Then the low pressure wave will only propagate on the surface of the body of water. And only far enough to 'make up' for the 'lost' water. (I.e. once you get to the point where the pressure difference is 1 or less, you cannot balance anymore, and therefore stop issuing block updates. Allowing everything to return to passive.)
And even if you don't, if you do not allow pressure balances of less than 1 (integers used for pressure), it should even out in an area, rather than the entire body of water.
Example: Assume water's natural pressure is 15. If you remove a block at the bottom of the body of water. Only 1 pressure needs to be 'taken' from 15 nearby water blocks in order to make up for the 'missing' water. In fact, since balances of less than 1 is not allowed, it will stabilize at 14, thus only needing 1 pressure from 14 nearby blocks. The outer edges of this 'low pressure bubble' will ask their adjacent water to update, but since the balance is less than 1, nothing will happen, the water will go back to passive, and the cascading update calls will cease.
The only update calls that will carry on, are for those block above, that through gravity, can add that 1 pressure to the blocks below (i.e. gravity does not balance, it tops-up). But again, once you reach the surface, no more pressure changes, thus no more update calls. Thus no updating the whole ocean.
A truly gigantic cave might still cause lag by needing large volumes of water to fill it up.
Ooh... I had not considered that.
A small compromise to the method of djoslin might let it work with finite water though.
In real life rain effectively comes from water taken from the oceans to start with.
So in the game we could make a compromise and say: "If water flows down to the ocean y-level (64 I think) and it flows into an existing body of water at least X blocks big, then instead of forming a new block atop that 'ocean/large lake/river' at ocean level water, it gets deleted."
In short, we pretend that the rain water came from that body of water to start off with, and after topping off the body of water, we just delete all excess.
This would allow for the following:
Other than the y-64 rule, no need for any other special handling of finite liquids.
You could still use finite water for all large bodies of water, ocean / lakes / or rivers.
If someone drains out a body of water (and given it is finite, they can) it will top back up when it rains, but cap itself at y-level 64.
You do not have any of the problems that comes from infinite water sources.
We only need to cap at y-level 64, because even if water is added from below, it will eventually propagate up to y-level 65, and thus be subject to the deletion as per the normal y-64 rule.
New lakes/oceans could form, even in hollowed out quarries. And will cap themselves at y-level 64. Adding a new neat mechanic to protect low-lying housing, caverns, etc. against.
Similarly, caves will only even possibly fill up to y-level 64, so will not flood the world.
In the end, some compromises must be made, because of silly limitations such as CPU power. (WHY U NO QUAMTUM-COMPUTE?!!)
But overall I think you can get still-truly-awesome-finite-liquid-mechanics.
It's the flying cutlery that stresses me out.
[Ocean overfill from rain]
Well no, if I would have rain depositing, which I may once I figure it out, I would have the rain come from evaporation.
Lag is however the biggest REAL reason I have for not making oceans finite, due to undersea flooding.
[Lag from oceans]
ACTUALLY, oceans only lag when something is updating.
I've flown over a huge ocean area, and messed around with placing water to check for lag.
The only ocean oriented lag comes specifically from the ocean flooding underground caves and cave-ins.
This on top of my implementing the non-constant updating should prevent that problem.
[Ocean spread]
NO, I don't plan on making ocean blocks replicate.
If I go with the ocean block idea, Implement simple de-ocean-ing rules...
However I would not allow ocean tile replication.
OH BOY, THATS A LOT OF TEXT!!!
[PRESSURE]
Water blocks normally can have a value from 0-8 [0 being empty, and 8 being full]
If a water block has water above it, and that water is filled above a certain level.
The lower block can exceed it's normal max value of 8.
So if you place a water block above another, their values will become 9 and 7.
[UNDERSEA PROBLEM]
When an opening appears in the bottom of the ocean.
It allows water blocks to move their contents downward.
This then decreases their value, which triggers nearby block to flow into them.
The nearby blocks value being lower causes nearby blocks to flow into them...
You see the pattern?
Well it creates a low pressure wave which rapidly moves upward.
The number of updates required to find pressure equilibrium is enormous in an ocean.
[RAIN]
Well I honestly think the best solution is simply to create ocean blocks which absorbs finite water blocks.
having infinite oceanwater is no problem at all, if it does never spread upwards and if it gets converted into being finite water when the mass gets reduced/it gets seperated into smaller bodies of water.
also if you have finite oceanwater, a cavein will lead to a wave of computed blocks that might expand really fast and crash the server.
YOU ARE ABSOLUTELY RIGHT
I'm working on making oceans into infinite NON-DUPLICATING water sources.
Having the ocean finite results in giant low pressure waves to travel up and outward across the ocean.
if you have the ocean nonduplicating, what will happen if you dig on the coastline - water next to air not flowing there like being held back by some invisible wall...
I don't think you understood what I meant
The ocean blocks would fill air blocks with finite water blocks...
The ocean block would not turn any blocks into ocean blocks...
This would allow for the ocean to flood a cave without severe lag, and without filling it with ocean blocks.
I might allow oceanification under very specific circumstances, and deoceanification under more common circumstances.
Tried in both most recent and recommended version (1.4.7 and 1.3.2), neither of them work when I add modloader and the mod (also doesn't work with forge, sad).