Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mr. Boh]

I'm loving the new version. I've got a couple of suggestions though - they may have been mentioned already.

I tapped into a full river using a very long system of tunnels in order to water my farm rooms, but it took ages for the water to fill up the system. I estimate that it would probably take several game years. Water from the river in the old version moved quickly, but maybe there's a happy medium. Would having lots of turns make a difference, or is it just a matter of rapid evaporation? Having water spread 4 or more times faster would be great.

Would it be possible to have fortresses abandoned within the first season not be saved at all? Since the sites are so different I find myself abandoning 10 sites before I find one I like and it's cluttering up my reclaim menu. This brings me to my next suggestion:

Could we have the ability to save selections in the "plan carefully" menu? I invariably pick the same items (meat type differs, I suppose) and if I could just tap a few buttons it would save quite a bit of time.

Thank you Toady! The wait was so worth it!

[Karlito]

I think having water flow faster could cause a lot of problems as well.  How do you tap into that river system when as soon as you do it floods and your miner drowns.

[Freddybear]

Dig your tunnel complex one z-level underground, right up to the edge of the river, but not *into* the river. Then make a *channel* on the last square from ground level. Bingo, river floods tunnel, miner is not in danger.

[JT]

I also build in a floodgate so I can, if need be, block flow and pump out all the water to retrieve things like propelled corpses, junk, and other things that wind up in the channel over time.  I'm always surprised to discover that people put their miners in direct danger of drowning. =)

[Mr. Boh]

Good ideas regarding the channel and backup pump systems. I just flooded my fortress despite having an emergency floodgate stop in place.

I tapped the river with the idea of dropping it 3 floors down into a small reservoir that I would eventually put a well over. I expected the water to flow at the same speed it did in my last game, but it went down through my tunnel and back up through channels and eventually my main staircase before the lever could be thrown. I guess something strange was happening last game.

Anyways, scratch that first suggestion. On to the next fortress!

[BlackboX]

It seems that the water expands just like temperature, on each calculation step randomly flowing from each place with deep water to some place with shallow water. For example, all 8 directions would be of equal probability:

code:

water map:      probability map:
111             222
121             202
111             222

In that case making water spread faster won't help because it will slow down exponentially. Also, the vanguard of the water flow (1-deep water) will become longer and evaporate, further slowing the flow down.

Unlike temperature, water flow has inertia. So, if the water came from the left, it will most probably not turn around and flow back to the left:

code:

water map a moment before:
111
211
111
water map:      probability map:
111             123
121             004
111             123

Walls could just nullify the speed:

code:

water map a moment before:
11#
21#
11#
water map:      probability map:
11#             220
12#             200
11#             220

... or do something more complex:

code:

water map a moment before:
11#
21#
11#
water map:      probability map:
11#             240
12#             100
11#             240

[Nadaka]

Another option would be to consider a mass of water to be a single object rather than a mass of distinct squares. This has the distinct advantage that it would cut down on the general calculation load of working with water. Each square would not need to have its flow determined each clock, rather only when the boundary of the water object is changed will any water calculations be needed.  In this case the water expands into a void left by removed material at a rate determined by the height of the body of water and the cross sectional area of the void.

such a body of water could have 3 effective zones. The surface layer, from where water is drawn during flow. The main body that is a homogenous and non-moving volume below the surface. And the flow area where volume is added to the water object.

When the surface zone drains all its volume it vanishes and a new full surface zone is designated on the layer beneath it.

When a flow zone reaches a depth of 7 units of water in a given tile, it is absorbed by the body of the water.

The rate of water flow is determined by the z-level difference between the flow boundaries and each boundary produces adjacent flow. As water moves into the flow areas, these flow areas also flow int adjacent areas creating sloping effect. and allow dwarves to move/swim out of the area more so than filling with water.

[Quintin Stone]

quote:Originally posted by Karlito:
<STRONG>I think having water flow faster could cause a lot of problems as well.  How do you tap into that river system when as soon as you do it floods and your miner drowns.</STRONG>

Oh come on, right now water is so slow, even the slowest crippled dwarf in full steel plate can run from it!  I think we can get faster water without it being an instant death sentence.

[Core Xii]

It's funny how many people suggest so many optimizations to the game without any knowledge whatsoever how the underlying system even currently works.

[Nadaka]

Well then, how does it really work?

[Yag Alone]

quote:Originally posted by Quintin Stone:
<STRONG>
Oh come on, right now water is so slow, even the slowest crippled dwarf in full steel plate can run from it!  I think we can get faster water without it being an instant death sentence.</STRONG>

Ever tried to tap water from the bed of an ocean? I tried it once...

As soon as my miner opened the door supposed to block the water, the game freezed for a few minutes and then... half of my fortress was flooded  :p

Now, I *always* use at least two doors

[Draco18s]

A suggestion that WOULD make water flow faster is to take into account the hight differences between the two tiles

666
676
666

of course has a differnce of 1 and the 7th unit will move around as it will.
The problem comes along when all of a sudden...

777#
777.
777#

The game currently goes, "oh, open space"

777#
7761
777#

And thus proceeds to flood out the door 1 unit of water at a time.

But what if instead we did...

777#
7743
777#

Where half the water "falls down" into the mined-out section, well then we have...

776##
76532
776##

In two itterations, the game as it stands would take 6 or 7 itterations to get to.  It also means deeper water flows faster (ah la fake water presure).

[mickel]

quote:Originally posted by Draco18s:
<STRONG>A suggestion that WOULD make water flow faster is to take into account the hight differences between the two tiles

---  

It also means deeper water flows faster (ah la fake water presure).</STRONG>

Brilliant suggestion! Seconded!

[BlackboX]

quote:Originally posted by Core Xii:
<STRONG>It's funny how many people suggest so many optimizations to the game without any knowledge whatsoever how the underlying system even currently works.</STRONG>

Well, I don't know how it works, but I can watch the water flow and make some suggestions, right? I dug a long, long tunnel into a river and watched the water while sturgeons were eating my dwarfes. Of course, I did it with [SHOW_FLOW_AMOUNTS:YES] in config.
At first, water flows very fast. But then it slows down, and we can clearly see random behaviour of the tiles with deep water: on each step water randomly flows from deep tiles to some not-so-deep tiles, changing directions all the time. This is just like temperature (which is just an effect of randomly flying molecules) works in real life. So, if temperature in DF works like temperature in RL, I can assume that the water flows in DF are calculated exactly like temperature.
Maybe I'm wrong, and DF actually solves Navier-Stokes equations in real time or something, I don't know. But if it uses temperature-calculating code, it *will* slow down exponentially in long tunnels no matter how fast it flows initially (how many exchange steps happens in a second) or how much water units it can exchange in one step.