Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2

Author Topic: Brooks defy common logic.  (Read 2728 times)

catpaw

  • Bay Watcher
    • View Profile
Brooks defy common logic.
« on: August 29, 2008, 10:46:17 am »

Okay I was last night playing around with water... and no I didn't understand the waterwheel wikipage at first. Now I do, I think.

However take this sentence: To turn a brook into a river, dig through its surface...
As experienced DF player you know what it means, and it might make sense to you. But gosh, turning on common sense, turning a brook into a river? digging through the surface of a brook? ... seriouosly...

I know its current propably just a hack to the engine to make rivers you can walk through.. but wouldn't it be much nice if a brook would be 3/7 or 4/7 high water? Without invisible surfaces?
Logged

TheSpaceMan

  • Bay Watcher
    • View Profile
    • http://www.digital-lifeform.com
Re: Brooks defy common logic.
« Reply #1 on: August 29, 2008, 11:00:08 am »

like someone said. Imagine the brook being filled with lots and lots and lots of diffrent sized rocks. you can still walk over it on the right stones and it's to shallow to drive a water wheel with the stones in place, channeling out the squares would remove the rocks from that area and show the entire unhindered depth of the brook. I guess.
Logged
Poking around with a DFParser.
Bodypart names, creatures names in one easily overviewable place.

Oh my new (old) picture?

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #2 on: August 29, 2008, 11:15:59 am »

Say I manage to dam the brook close to the beginning of the map, or I redirect it into a bottomless pit.. and I would enter the brook bed from the bottom... would the "rocks" still be there making up walls now or would there be a long empty hall with an invisbile ceiling?
Logged

Granite26

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #3 on: August 29, 2008, 11:28:37 am »

Nobody (especially the developer) thinks that the current situation is ideal.  The problem is that given the current flow models and the z level situation, it's a reasonable approximation that saves a significant amount of FPS heartache.

You can't 'just say that it's 4 deep' because it's water, it flows.  If you wanted to have a naturally four deep river, you'd have to find some way of adding water at the source while taking it away at the drain, and still keeping it uniformly four deep, without breaking the way flows work now, and without it bunching up at the source while being to shallow at the outlet.  (The reason real brooks work is that there are increments of water depth less than 8-9 inches, and there are differences in rock height less than 5-6 feet.  Also, inertia helps)

Try coming up with an algorithm if you don't believe me.

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #4 on: August 29, 2008, 11:58:12 am »

Hmm, I'd suggest following algorithmn... first any creature can wade through 7/7 water if the z-level aboth is empty, second water can stack upon water. that is, if there is 7/7 water in a z-level below, it wont fall down. If a creature is in a 7/7 water tile, and there is water in the z-level aboth stacking onto this, it can either swim up if swimming or it drowns if not water-breathing.

brooks are a 1 z-level deep water with watered ramps on the side... so creatures can walk through it.... rivers on the other hand are 2 z-levels deep... so normally not easily passable.

How does that sound?
----------------------------------------------------------------------------------------
Other idea: At the source of brook, whenever the first tile on the map drops below 4/7 add a water tile, and at the end of the map only take a water away every second or third time frame if its not 3/7 or below... Except when for a longer time it has never been 4/7 ... that is the river must have been interrupted in any way, then slowly lower the edge to 2/7 then 1/7 then 0/7 to drain the remaining brook bank empty. This should in net result in some 3/7 watertiles "traviling upward" the brook....

or you can further modify this by introducing a "4.5/7" water level, the user always only sees it as level 4/7 layer, and also is regarded 4/7 for any other operation. Add 4.5/7 water at the source. At the end of the map, only reduce 4.5/7 water to 4/7 waters ... Only if the drain hasn't eaten any 4.5 water level for a given time (to be gathered by experiment), that is the brook is interupted, reduce its draining level to 3, 2, 1 and finally zero. This sounds like pretty workable to me... not?

Unfortunally altough being a C/C++ coder I can obviously not really try it out...if it works like imagined...
« Last Edit: August 29, 2008, 01:50:05 pm by catpaw »
Logged

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #5 on: August 29, 2008, 12:02:24 pm »

About waterwheels, I'd have a suggestion too.. Look at real water wheels, they don't just put a wheel in flowing water and hope the water turns it. In reality this hardly works. Waterwheels always need a z-level difference. Look at a mill, usuall it is near a steep brook, and the water is taken from some way aboth, directed in a a near horizontal kanal to the wheel, and then dropped upon the wheel. I think it would be nice if in DF waterwheels would also need a z-level difference to operate... However this would need the map to change the river, that is a river entering from 1,2 or 3 z-levels from above, and dropping these z-levels while it runs through the map. That would be the points you could build waterwheels at.
Logged

FFLaguna

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #6 on: August 29, 2008, 05:30:51 pm »

You mean brooks defy common logic.
Logged

Neonivek

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #7 on: August 29, 2008, 05:42:44 pm »

Sometimes I feel like the Suggestion forum is simply used as a complaints department

The problem with having Brooks actually be 3-4/7 is that they would cause a lot of lag for one.
Logged

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #8 on: August 29, 2008, 07:22:40 pm »

Sometimes I feel like the Suggestion forum is simply used as a complaints department

Sorry but I consider this a pretty unfair allegation, I have been trying to be constructive from a start. Of course a complain and a suggestion are near things, to one view it is in core the same thing. I consider the difference from simple complaining to suggesting to try to be constructive in the second case.

Quote
The problem with having Brooks actually be 3-4/7 is that they would cause a lot of lag for one.

So explain somebody to me why 4/7 water tiles take more CPU power than 7/7 water tiles
Logged

Neonivek

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #9 on: August 29, 2008, 07:26:16 pm »

Sometimes I feel like the Suggestion forum is simply used as a complaints department

Sorry but I consider this a pretty unfair allegation, I have been trying to be constructive from a start. Of course a complain and a suggestion are near things, to one view it is in core the same thing. I consider the difference from simple complaining to suggesting to try to be constructive in the second case.

Quote
The problem with having Brooks actually be 3-4/7 is that they would cause a lot of lag for one.

So explain somebody to me why 4/7 water tiles take more CPU power than 7/7 water tiles

Alright let me see

A) Complaints can be constructive... I didn't mean for what I said to be so offensive or rather I didn't mean for it to be offensive... So I appologise

B) Because the way the game runs it calculates any water level below 7/7 constantly.
Logged

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #10 on: August 29, 2008, 07:28:16 pm »

B) Because the way the game runs it calculates any water level below 7/7 constantly.

Hmmm Okay. So why has it to calculate a 4/7 water constantly, while not a 7/7 water?
Logged

i2amroy

  • Bay Watcher
  • Cats, ruling the world one dwarf at a time
    • View Profile
Re: Brooks defy common logic.
« Reply #11 on: August 29, 2008, 07:36:42 pm »

Because with 4/7 water you generally end up with a combination of 4/7's 5/7's and 3/7's. This leads the game to be constantly moving the water around as it tries to equalize, which in dwarf fortress, can take years. (I one time had waves in a lake for five years after a damming experiment) If the water tiles are 7/7, then the game says that no water can move to those tiles and doesn't need to recalculate them unless something in those exact tiles changes. Technically, a pool that was perfectly 4/7 all the way across would take no more CPU power than a pool that was 7/7 across. However, it is very hard to get a pool that is 4/7 all of the way across, where it is very easy to get a pool that is 7/7 across.
Logged
Quote from: PTTG
It would be brutally difficult and probably won't work. In other words, it's absolutely dwarven!
Cataclysm: Dark Days Ahead - A fun zombie survival rougelike that I'm dev-ing for.

Nesoo

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #12 on: August 29, 2008, 10:27:36 pm »

tl;dr: brooks should have a special tile that acts like a constructed wall (with brook "floor" above) that lets water pass through, assuming I'm not missing some glaring logical problem with such.

like someone said. Imagine the brook being filled with lots and lots and lots of diffrent sized rocks. you can still walk over it on the right stones and it's to shallow to drive a water wheel with the stones in place, channeling out the squares would remove the rocks from that area and show the entire unhindered depth of the brook. I guess.

I'm sure I'm not the only one, but here's a post where I even drew a diagram.

Say I manage to dam the brook close to the beginning of the map, or I redirect it into a bottomless pit.. and I would enter the brook bed from the bottom... would the "rocks" still be there making up walls now or would there be a long empty hall with an invisbile ceiling?

I can't say that I've done it, but I would assume that the long hall with ceiling is what happens. So yeah, there's an example of where my way of viewing it breaks down.

Hmm, I'd suggest following algorithmn... first any creature can wade through 7/7 water if the z-level aboth is empty, second water can stack upon water. that is, if there is 7/7 water in a z-level below, it wont fall down. If a creature is in a 7/7 water tile, and there is water in the z-level aboth stacking onto this, it can either swim up if swimming or it drowns if not water-breathing.

brooks are a 1 z-level deep water with watered ramps on the side... so creatures can walk through it.... rivers on the other hand are 2 z-levels deep... so normally not easily passable.

How does that sound?

I don't like this (also, water already can stack on water, though I think brook tiles are special and eat water that falls on them). AFAIK, 7 is supposed to be the "height" of a tile, representing that the tile is completely full of water. It doesn't make much sense that dwarves would be able to wade through something like that and yet carve tunnels in the mountain that are the same height... not that current brooks make much sense either (well, they do okay as long as you don't try to break my view of them ;) ).

Quote
Other idea: At the source of brook, whenever the first tile on the map drops below 4/7 add a water tile, and at the end of the map only take a water away every second or third time frame if its not 3/7 or below... Except when for a longer time it has never been 4/7 ... that is the river must have been interrupted in any way, then slowly lower the edge to 2/7 then 1/7 then 0/7 to drain the remaining brook bank empty. This should in net result in some 3/7 watertiles "traviling upward" the brook....

This is a possibility, though you have to be careful about how you handle the drain. For instance, how does it know that the flow has started again and it's not just that the brook is taking a long time to drain? It might be better to have a drain that just takes away at the same rate that water is added, or however it is that it works now.

Quote
or you can further modify this by introducing a "4.5/7" water level... <snip>

I doubt that the game is set up to handle water at fractional fraction levels... if that made sense. Not to say that it couldn't be if it isn't, but if Toady's saving memory by packing different bits of data in a single byte/short/long (which is my guess; 3 bits for the amount of water in the tile, at least 5 more for other data/flags), I'd rather have that :)

Maybe brooks could be filled with a special tile in the "tunnel" underneath the brook tiles; call it "gravel" for this example, treat it like soil layers for mining (obviously you aren't going to get usable rock from it). Gravel could act like a wall except it allows water to flow through it. Mining out a gravel tile should remove the brook tile above as well. If there's no water in the gravel tile the brook tile turns brown/grey/whatever and stops animating (and is changed back to blue/cyan/whatever and animates if water is re-introduced to the gravel tile). The gravel tile should be scooped out if the brook tile is channeled (just like channels in regular rock work). Water should probably fall through brook tiles into the gravel tiles, if possible.

Any glaring logical problems that I'm missing? I had thought that cave-ins would cause problems, but the last line above fixed my first problem with them, and just flat out makes sense anyway. To fix the other problem I can think of with regards to cave-ins, the brook floor should be intimately linked with the gravel tile, so a falling gravel tile brings a brook tile down with it... of course, I think that's the only way to make the gravel tiles fall in the first place (they'd "hang" from the brook tiles if nothing else, so you'd have to channel out all around them... which would make the brook tiles loose and fall as well), so it shouldn't be an issue anyway.

Ok, that was a bit of a hijack... sorry about that :)
Logged
000508 □ [dwarf mode][flows] flooding over a full pond will kill the fish inside

catpaw

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #13 on: September 03, 2008, 07:27:41 am »

I have a new idea! What is a brook actually? Its something that just isnt as deep as most things are.

1 idea step:. Make a new tile, the "half tile" that is that is just like the bottom half of a wall. It can be walked upon if the square above is empty. Now since the tile is half full already, it can never have more than 4/7 water. So if it has 4/7 the game engine can consider it as full, and apply the same optimizations as with 7/7 normal tiles...

second thought. Since the dwarfes should be able to go through the river, this half tile should act like a ramp/slope.

third thought: Hey! What about making ramps/slopes like this! That is since a ramp/slope is actually half full of material, it should be considered full of water when it has 4/7... So you don't a new tile after all. To make a brook, just make a line of slopes... and add the logic that slopes/ramp can have 4/7 max of water only + they are not drowning you dwarfes if the the tile above is open and waterless.
Logged

Silverionmox

  • Bay Watcher
    • View Profile
Re: Brooks defy common logic.
« Reply #14 on: September 03, 2008, 07:46:30 am »

third thought: Hey! What about making ramps/slopes like this! That is since a ramp/slope is actually half full of material, it should be considered full of water when it has 4/7... So you don't a new tile after all. To make a brook, just make a line of slopes... and add the logic that slopes/ramp can have 4/7 max of water only + they are not drowning you dwarfes if the the tile above is open and waterless.
This is a good idea: it would solve the need to make brooks passable, so the brook ceiling/floor/tile is no longer necessary. At the same time FPS rationing would still be possible by considering ramps full at 4/7.

The problem could be water creation/absorption. Creation is ok I think, excessive pumping should lead to brooks drying up. Water absorption will be a problem; that could be solved by labeling the tile "brook" and let it do the absorption thing. That would also help the game to keep recognizing brook tiles that are pumped dry, but which will be refilled (for sleeping dwarves, etc.).

And a typical brook should be no wider than 1 tile, of course. That's already 2/3 less water to hog calculations.

Do brooks dry up in summer in dry climates, by the way?
Logged
Dwarf Fortress cured my savescumming.
Pages: [1] 2