Sorry, at the moment it is prohibitively resource-intensive (a flood of warnings about ABMs taking 2 to 6 times longer than 200ms). I should probably try to use voxelManips or whatever they're called, but I've no idea how, and can't find anything simple enough for me to understand.

To make the whole thing less cpu-intensive you could decrease the chance of the water-placement-abm(i mean actually increasing the value so it gets only executed for a few nodes)It should catch up eventually...

BuckarooBanzay wrote:To make the whole thing less cpu-intensive you could decrease the chance of the water-placement-abm(i mean actually increasing the value so it gets only executed for a few nodes)It should catch up eventually...

So... would an abm call every 10 seconds replacing all water be slower than one running every one second replacing 1 in 10? I'd have thought otherwise, but have never even touched the code itself, and this is sort-of my first serious mod, so I have no real idea.

question: does anyone know of any changes in 5.0.0-dev that might be preventing my abm from doing anything? (also, [it]something[/it] is bringing my water-level back up to what it was at worldgen, even when the tides are supposed to be low (as in -2))

markthesmeagol wrote:question: does anyone know of any changes in 5.0.0-dev that might be preventing my abm from doing anything? (also, [it]something[/it] is bringing my water-level back up to what it was at worldgen, even when the tides are supposed to be low (as in -2))

markthesmeagol wrote:question: does anyone know of any changes in 5.0.0-dev that might be preventing my abm from doing anything? (also, [it]something[/it] is bringing my water-level back up to what it was at worldgen, even when the tides are supposed to be low (as in -2))

Never mind, it isn't working in 4.15 either. Anyone know why?

Is it maybe the neighbouring water nodes flooding in? Haven't tested it though... :P

markthesmeagol wrote:question: does anyone know of any changes in 5.0.0-dev that might be preventing my abm from doing anything? (also, [it]something[/it] is bringing my water-level back up to what it was at worldgen, even when the tides are supposed to be low (as in -2))

Never mind, it isn't working in 4.15 either. Anyone know why?

Is it maybe the neighbouring water nodes flooding in? Haven't tested it though... :P

The thing that makes default:water_source behave that way is the property "liquid_renewable = true", if you override that to be false water will no longer "self-replicate" (lava already behaves this way if you want to see an example). I had to do this in my dynamic_liquid mod [here](https://github.com/minetest-mods/dynami ... t.lua#L173). You might potentially not need to mess with this, though, if you are removing all of the water on a particular y-coordinate fast enough. I'd set it to false for now while you're getting the rest of the mod to work and then see if you still need it once you're done.

Taking a quick look at the rest of the mod, I take it the idea here is that depending on the particular time of day you want to destroy the uppermost layers of water in the ocean at certain times of the day and then recreate them again on the other times? There's going to be some tricky edge cases to overcome here no matter how you approach this, but that's part of the fun of making mods. :)

Using minetest.register_globalstep is the correct approach to modifying the mapblocks that a player is currently in to account for time changing "before his eyes", IMO. To update blocks that a player enters into that were last left in a state other than the way it should be now (for example, it's low tide and the player has just entered a mapblock that was left in a high-tide state) I recommend using an LBM instead - look up LoadingBlockModifier in the api documentation, you'll want one with run_at_every_load = true and set to execute on water nodes.

That works well for making the water level go down when tide goes out, but making the water come back *up* again is more challenging. You'll need some way to figure out where water is supposed to be - if you just indiscriminately fill the entire y-coordinate's air layer with water you'll inundate the caves and any holes the player might have dug.

Unfortunately, I don't think the heightmap for most mapgens is not available after the map block has been generated. And you probably wouldn't want to rely on that anyway in case a player has built a dike and cleared water out of the area. I think what you'll need to do is look for existing water on the level below the one you're trying to fill, check if the water has a clear path through existing water to the edge of the mapblock (to avoid having isolated ponds rising and falling), place new water above it, and then do a flood-fill operation from the edge of that water to make it spread outward. There's still ways this can cause non-ocean water to rise and fall but I expect it'll be fairly rare and maybe not worth worrying about.

If you like the sound of that idea and nobody has better suggestions I could whip up some example code to show it in more detail.

It seems to me that converting the -1 and -2 layers of water into a specialized blocks (for instance tide_water) would allow the ABM to operate on a more limited number of blocks, and possibly to tune the ABM parameters (chance, interval) better; if one can replace the water/air blocks in one go (*), the water level would only have to change four times per in-game day (which suggests that the interval should take the duration of the day into consideration).

for instance if tide_water_node pos > height then change it to tide_air_node, if tide_air_node < height then change it to tide_water_node.

Obviously those two special nodes have the same properties as air and water.

As for the issue with ponds and lakes, a possible solution could be to replace source_water nodes with river_source_water at mapgen time or with a LBM. The tricky part though, determining a criteria to decide what is a pond or a lake, is still here. I would try water depth, as it seems to me that ponds are often shallow (almost by definition?).

(*) I'm not sure changing all block at once is ideal, those, because it could ground fishes, drown other mobs and surprise players. Maybe a more complicated concept that would simulate waves would allow more progressive tides. But then I'm not sure it would render well in the end, and the whole thing is easier said than done.

FaceDeer wrote:Taking a quick look at the rest of the mod, I take it the idea here is that depending on the particular time of day you want to destroy the uppermost layers of water in the ocean at certain times of the day and then recreate them again on the other times? There's going to be some tricky edge cases to overcome here no matter how you approach this, but that's part of the fun of making mods. :)

I'm not sure if I understand. Edge cases being... the peaks of the sine wave? I'd like to have it working before I worry about the range. It's just one line of code after all.

FaceDeer wrote:Using minetest.register_globalstep is the correct approach to modifying the mapblocks that a player is currently in to account for time changing "before his eyes", IMO.

So... instead of the ABM? I'm not sure how that would work. then again, I'm a noob.

FaceDeer wrote: To update blocks that a player enters into that were last left in a state other than the way it should be now (for example, it's low tide and the player has just entered a mapblock that was left in a high-tide state) I recommend using an LBM instead - look up LoadingBlockModifier in the api documentation, you'll want one with run_at_every_load = true and set to execute on water nodes.

Thanks for this advice, it's half-working now! Also, not crazy-slow!

FaceDeer wrote:That works well for making the water level go down when tide goes out, but making the water come back *up* again is more challenging. You'll need some way to figure out where water is supposed to be - if you just indiscriminately fill the entire y-coordinate's air layer with water you'll inundate the caves and any holes the player might have dug.

Heh. I can't get it to rise at all.

FaceDeer wrote:If you like the sound of that idea and nobody has better suggestions I could whip up some example code to show it in more detail.

Some help in getting the tide to go up would be really appreciated. The github repo is currently up to date, although it needs renaming.

Astrobe wrote:It seems to me that converting the -1 and -2 layers of water into a specialized blocks (for instance tide_water) would allow the ABM to operate on a more limited number of blocks, and possibly to tune the ABM parameters (chance, interval) better; if one can replace the water/air blocks in one go (*), the water level would only have to change four times per in-game day (which suggests that the interval should take the duration of the day into consideration).

for instance if tide_water_node pos > height then change it to tide_air_node, if tide_air_node < height then change it to tide_water_node.

Obviously those two special nodes have the same properties as air and water.

Actually, I was just thinking something similar: the tides go down with no problem, so having a special tidal water thing is probably unnecessary. However, if instead of air it was replaced with another gas (one that stinks, because of all the old seaweed, fish etc), then the problem of finding where to put the high-tide water is solved, and it will become simpler to raise the tide as well.

Astrobe wrote:As for the issue with ponds and lakes, a possible solution could be to replace source_water nodes with river_source_water at mapgen time or with a LBM. The tricky part though, determining a criteria to decide what is a pond or a lake, is still here. I would try water depth, as it seems to me that ponds are often shallow (almost by definition?).

I hereby declare, untill further notice, any pools of default:water_source to be part of the sea, since that way I don't have to worry about them.

side-note: if there is river_water, why isn't there any pond_water? there are, after all more ponds than rivers in minetest.

markthesmeagol wrote:I'm not sure if I understand. Edge cases being... the peaks of the sine wave? I'd like to have it working before I worry about the range. It's just one line of code after all.

"Edge case" means a situation where, even though the code works correctly 99.9% of the time, there's this one weird situation where it does something strange. For example if your approach is "destroy all water at y=-1 when the tide goes down and then fill all air at y=-1 with water when the tide goes up" then an edge case would be "what about a 1-node-deep pond? The water would magically appear and disappear completely in a pond like that." or "what about a cave that passes through the y=-1 level, water shouldn't just poof into existence in there."

Even my suggested approach - look for existing water at the boundaries of map blocks and flood-fill from there - has its own edge cases. You could have a small pond that happens to straddle a map block boundary, and then you'll see tides raising and lowering the water in it. With a game like Minetest it's really hard to eliminate *all* edge cases from situations like this, players build all kinds of weird stuff. Ideally we find solutions where edge cases are minimized and their effects are not obvious.

markthesmeagol wrote:

FaceDeer wrote:Using minetest.register_globalstep is the correct approach to modifying the mapblocks that a player is currently in to account for time changing "before his eyes", IMO.

So... instead of the ABM? I'm not sure how that would work. then again, I'm a noob.

Yeah. ABMs, LBMs, and globalstep callbacks all have different strengths and weaknesses, so different problems are best solved in different ways. In a nutshell:

ABMs are called at regular intervals on every single node (of the specified types) in the active block they're in. When using them with very common node types (like water_source) this results in a ton of function calls. ABMs are good for things that need frequent updates that happen before the player's eyes, like fires spreading or lava cooling.

LBMs are also called on every single node of the specified types in a block, but only at the moment when the block is loaded into memory - usually, that means when the player has approached near enough to see it. LBMs are ideal for making changes that the player would assume had happened while they were away from the region, and for housekeeping operations such as replacing obsolete nodes from an uninstalled or older version of a mod with new replacements.

globalstep callbacks are only called once per player, though at a high frequency (once per tick of the clock, which in a game is usually a small fraction of a second - most globalstep callbacks will keep track of elapsed time and only do the "meat" of their code at more widely-spaced intervals to reduce the overhead). They're better than ABMs for this particular purpose because you can have it keeping close track of the time (frequent runs) without also running it for every node - it eliminates a ton of redundancy.

There are some other tricks in the modding toolbox for making the world change over time beyond just these, but they're less relevant to the specific problem here I think. We'll see how those edge cases go. :)

markthesmeagol wrote:

FaceDeer wrote:If you like the sound of that idea and nobody has better suggestions I could whip up some example code to show it in more detail.

Some help in getting the tide to go up would be really appreciated. The github repo is currently up to date, although it needs renaming.

I'll take a look later today and make some specific suggestions. I'm in the middle of final testing to roll out a major release of one of my own mods, though, so don't wait up on me.

You've picked an interesting puzzle for your very first mod, but don't be discouraged. I've been modding for years and I'm still encountering weird situations and head-slappers where I realize I've made a bad choice without realizing it. Minetest has some non-obvious gotchas sometimes. :)

markthesmeagol wrote:Actually, I was just thinking something similar: the tides go down with no problem, so having a special tidal water thing is probably unnecessary. However, if instead of air it was replaced with another gas (one that stinks, because of all the old seaweed, fish etc), then the problem of finding where to put the high-tide water is solved, and it will become simpler to raise the tide as well.

A possible solution, but which comes with its own possible problems as well. A player could build a bunch of nodes in a low-tide-exposed area, replacing the airlike tidal water, and then dig those nodes to leave regular air. Or they could build a wall to isolate a patch of exposed land from the ocean, but it's still got those invisible tidal water replacement nodes in it.

A placeholder node like this could save a lot of work, though. Worth poking around with. The vacuum mod comes to mind as a possible related idea you could look at the code for, I stole a few ideas from it when creating mine gas.

markthesmeagol wrote:side-note: if there is river_water, why isn't there any pond_water? there are, after all more ponds than rivers in minetest.

As I understand it, river_water was created specifically for the "valleys" mapgen. That mapgen creates rivers whose surface rises and falls with elevation changes, resulting in flowing water being generated. But regular flowing water spreads like crazy, so the rivers would end up generating lots of weird flooding. river_water has a smaller liquid_range value, which keeps the flooding more local.

Pond water and ocean water wouldn't need different properties, so having two node definitions with the exact same properties would be redundant and complicate things (what happens if the player digs a channel between pond and ocean, for example? How do the two flowing types "mix"? Should there be two different bucket-of-water types?). Also, it's not necessarily obvious to the map generator what's a pond and what's an ocean. Mapgen can only "see" the specific map block that it's currently working on, it can't (reliably) take a peek at the next block over to see if the little bit of water on its edge is connected to a vast ocean or if it's just half of a tiny little puddle.

FaceDeer wrote:A placeholder node like this could save a lot of work, though. Worth poking around with. The vacuum mod comes to mind as a possible related idea you could look at the code for, I stole a few ideas from it when creating mine gas.

It's what open source is all about, innit? I noticed a few pieces of my "airtanks" mod in vacuum too, and so the wheel turns. :) Oh, if markthesmeagol will excuse the brief off-topic digression, I should mention that in vacuum's register_on_dignode callback you might want to use if minetest.get_item_group(oldnode.name, "digtron") > 0 then instead of if oldnode.name and string.sub(oldnode.name, 0, 7) == "digtron" then. That way if some other mod comes along that adds new digtron components vacuum will treat them right too. I don't know of any but it's a theoretical possibility.

A possible solution, but which comes with its own possible problems as well. A player could build a bunch of nodes in a low-tide-exposed area, replacing the airlike tidal water, and then dig those nodes to leave regular air. Or they could build a wall to isolate a patch of exposed land from the ocean, but it's still got those invisible tidal water replacement nodes in it.

Ouch. Didn't think of those cases. maybe some sort of cellular automaton (in the form of an abm) would sort things out? Or... could I use the liquid_whatever thing to get the gas to spread? Probably an entire new can of worms.

FaceDeer wrote:A placeholder node like this could save a lot of work, though. Worth poking around with. The vacuum mod comes to mind as a possible related idea you could look at the code for, I stole a few ideas from it when creating mine gas.

I've looked at the vacuum one, and understand the general idea... sort of. I'l look deeper into it sometime.

FaceDeer wrote:

markthesmeagol wrote:side-note: if there is river_water, why isn't there any pond_water? there are, after all more ponds than rivers in minetest.

As I understand it, river_water was created specifically for the "valleys" mapgen. [...]

I guess that makes sense... but:

markthesmeagol wrote:I hereby declare, untill further notice, any pools of default:water_source to be part of the sea, since that way I don't have to worry about them. .

Since the mapgen doesn't care if it's a pond or not, why should I (other than common sense)?

Very intresting concept. How well does it perform now? And: Dirt falling dry because of the water moving away ought to turn into a special form of dirt. Maybe it would be sufficient to calculate and replace those nodes once. Still, that would make it even more complicated.

What about ships? They'd have to sink as well. While houses don't. So...there are many of these annoying edge cases. But the idea as such is great! Just...probably beyound what MT physics can do.