Print

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

[Jamini]

quote:Originally posted by Toady One:
<STRONG>
Dwarf-made holes don't refill because I don't have a good way of detecting what should fill and what shouldn't.  It's not impossible -- as Zemat said, it would be vaguely like the cave-in-code, or something.  It can't just put water everywhere without causing a CPU crisis -- I tried this, and we're not ready for it yet (it also looks silly without more water soaking into the ground initially, at least in biomes with permeable soil).Ponds/rivers don't have to have water to refill. Each raindrop event adds 1 unit of water to any pond or river square that has less than 7 units (and yeah, 0-7 units comes from the 3 bits available, allowing that to be modded might be an optimization issue, at least with my scant programming knowledge, since the flow code would have to respect/access any new init variables). Outdoor 1-deep water will no longer evaporate if the weather isn't clear, so rainfall should ensure some filling. It's a little goofy that only the ponds/rivers can refill, but that's how it'll be until something CPU-safe arises, and yeah, you should be able to dig tunnels from the dry ponds and so on to collect water in a underwater pool or however you'd like to handle it.
</STRONG>

Perhaps smoothed and constructed tiles could function the same way as murky pool tiles and river tiles if you go with the 1-deep water increase per raindrop. In permeable soil it's unlikely that enough water to create a standing pool will collect on the surface unless there is a deposit of impermiable material (like clay) that causes the ground to get saturated quickly. It's pretty easy to concive that soil and rough ground would have natural runoff that would cause rain to be lost if you smooth over the tile or build a floor there, while a built or smoothed surface would collect water even if you didn't want it too. Unless a player has a fairly large fortress in a temprate climate with a ton of roads or aboveground buildings that would not cause an issue. Indeed it might actually cause people to consider making drainage ditches in the case of a particularily violent storm, al-la flash flooding. Plus it would allow dwarves to "catch" rain in maps without naitive water sources (deserts primarily, and some exceptionally small plains maps).

Food for thought, anyway.

[Patarak]

Re-filling pools? Hell yeah!

[Arkose]

quote:Originally posted by Jamini:
<STRONG>
Perhaps smoothed and constructed tiles could function the same way as murky pool tiles and river tiles if you go with the 1-deep water increase per raindrop. In permeable soil it's unlikely that enough water to create a standing pool will collect on the surface unless there is a deposit of impermeable material (like clay) that causes the ground to get saturated quickly. It's pretty easy to concive that soil and rough ground would have natural runoff that would cause rain to be lost if you smooth over the tile or build a floor there, while a built or smoothed surface would collect water even if you didn't want it too. Unless a player has a fairly large fortress in a temperate climate with a ton of roads or aboveground buildings that would not cause an issue. Indeed it might actually cause people to consider making drainage ditches in the case of a particularly violent storm, al-la flash flooding. Plus it would allow dwarves to "catch" rain in maps without native water sources (deserts primarily, and some exceptionally small plains maps).
Food for thought, anyway.</STRONG>

I really, really like this idea. Dwarf cities and goblin towers would probably flood too easily if you have every raindrop that hits a smoothed tile creates one unit of water, though; maybe a one in four or one in eight chance of it happening would be more reasonable, experimentation is probably necessary.

It would cause problems with everything becoming muddy, though; there unfortunately doesn't seem to be be a "water not muddy" flag. This would be a huge issue, as looking at the dev notes it seems that Toady now has vegetation growing over engravings destroy those engravings; at the very least, we need a way to request our dwarves to clean specific muddy tiles. (Even if Toady decides to use a precious bit to store whether the water is muddy, we still really need this if getting mud on a masterpiece engraving will cause inevitable tantrums.)

[Sean Mirrsen]

If you think about it, it's actually perfectly reasonable to have all smooth floors, roads included, to collect water.

There really aren't that many flat smooth surfaces, most of the time. If rain falls thick, then having a "shadow bit" that makes the ground wet, as opposed to generating a puddle straight away, can help - the ground, even flat, will soak the first drops of rain that hit it, and only rain falling on wet ground will make a puddle. Non-smooth ground will then always only become wet, and will not gather water.

Goblin towers are lined with fortifications on top, which will let water drain away most of the time, and on soild or rock the water will sip off gradually. One unit of water not surrounded by other units of water will not flow anywhere, forming a "puddle" you could drink from if you wanted to.

[Armok]

Yea, the flat-surface-colects-water sounds good to me to.

[Sindai]

quote:Originally posted by Toady One:
<STRONG>I dunno.  When I take the map dims and multiply them by 29, it always seems sort of scary, especially in a canyon that somebody criss-crosses with tunnels so that the dynamic allocation is out of the picture.  480x480x20x29 doesn't seem far-fetched....  130MB, just for the map, and if you go out of your way it can be much worse (768x768x90x29 or so?  Some people find these terrible cliffs...)  Certainly for basic play, the extra bits aren't a problem.  There's probably some nice way to switch over to the compressed method depending on the map size without making too much of a mess, but my own attempt would be tragic.</STRONG>

Premature optimization is generally a bad idea. Do things the easy way first, and if the performance you get out of that is unacceptable make sure you know exactly what's causing it and then optimize that.

And for what it's worth, I don't think 130 megs is very scary at all. Memory is dirt cheap these days so I'd target 1 gigabyte machines, as someone else implied above. In practice that might mean 500 megs, though, once you account for the OS and people wanting to run other programs...

 

quote:Originally posted by Frobozz:
<STRONG>(2) tends to make porting code to an opposite endian device a pain (not like this really applies anymore).     :p</STRONG>

Is this really correct? I would have thought the compiler would keep the effects the same, at least for bitfield purposes, since the bitwise operators are defined by the language specs. There might be something really tricky I'm not thinking of, though.

[ June 06, 2008: Message edited by: Sindai ]

[SirPenguin]

I'm thinking, to help to game know when to fill and when to not, water should only collect on tiles that satisfy the following conditions:

1. Smoothed
2. Has a hole leading up the the surface
3. Has ramps lead down into it

The last, I think, might be the most important. Watch it rain outside. Unless it's really hard, it'll barely accumulate an inch or so, dissipating quickly once it stops raining. However, if you have slanted paths leading to a flat area, all the rain will collect, and then you'll see puddles and the like large enough to drink out of.

I guess my thought is that you'll have situations where you have (1) and (2), but NOT want it filled. By adding the (3), which is pretty logical, you add a list of things you need that aren't that hard to satisfy.

In order to save the CPU when it rains, I say we can of rough it...have it so when rain "hits" a ramp, it generates 1/7 water, and "rolls" down the ramp into the next available non-ramp. And that'll be the ONLY time it checks if it should generate water.

[ June 06, 2008: Message edited by: SirPenguin ]

[termitehead]

I would PAY just to get a chance to help with the coding Mr. Toady.  Seriously!  I do it for a living and I got to say it's hard to hear you say you know nothing about programming and then see what you've accomplished.  I can't imagine what DF would be like if you felt like you knew programming.

[Sindai]

On the other hand, when it comes to programming, it's probably easier to just know stuff than to know enough to know how much you know.

[Zemat]

quote:Originally posted by Toady One:
<STRONG>Kobolds just dig themselves a medium size cave.  I didn't have them expand it because they get popcapped pretty early on, but I could make them do it dynamically...  okay, there.</STRONG>

Yay! I was going to mention also all other stuff about expanding world-gen dwarf-fortresses and dark-fortresses. That's the kind of stuff I like to see. Naturally expanding "dungeons" that seem unique yet not totally random.

[Frobozz]

quote:Originally posted by Sindai:
<STRONG>
Is this really correct? I would have thought the compiler would keep the effects the same, at least for bitfield purposes, since the bitwise operators are defined by the language specs. There might be something really tricky I'm not thinking of, though.

[ June 06, 2008: Message edited by: Sindai ]</STRONG>

I think the Wikipedia sums it up nicely...

"However, bit members in structs have practical drawbacks. First, the ordering of bits in memory varies from compiler to compiler. In addition, many popular compilers generate inefficient code for reading and writing bit members, and there are potentially severe thread safety issues relating to bit fields (especially on multiprocessor systems) due to the fact that most machines cannot manipulate arbitrary sets of bits in memory, but must instead load and store whole words."

However a lot of other sites mention it as well. Like this one.

"C gives no guarantee of the ordering of fields within machine words, so if you do use them for the latter reason, you program will not only be non-portable, it will be compiler-dependent too. The Standard says that fields are packed into ‘storage units’, which are typically machine words. The packing order, and whether or not a bitfield may cross a storage unit boundary, are implementation defined. To force alignment to a storage unit boundary, a zero width field is used before the one that you want to have aligned.

Be careful using them. It can require a surprising amount of run-time code to manipulate these things and you can end up using more space than they save."

[Neonivek]

Well I was hoping for a release this week (at the rate it was going it was very likely) but it looks like more speed bumps.

Ohh well

[Sindai]

quote:Originally posted by Frobozz:
<STRONG>"C gives no guarantee of the ordering of fields within machine words</STRONG>

Oh well guess I was completely wrong.

Does this mean that you can't actually use shift operators to multiply/divide by powers of 2 depending on the architecture? That seems really weird.

[ June 06, 2008: Message edited by: Sindai ]

[Tahin]

I like the idea to have raindrops generate water on smoothed/constructed tiles, but it would have to have a strong tendency to be "pulled" towards adjacent non-smoothed/open space tiles, else roads and such will flood far to easily.

[Toady One]

I'm hesitant to embrace the smoothed floor idea without some clarifications.  If water collects on smooth rooftops, it will eventually flow off the side of the house, which is fine, but then the water will radiate outward from the house in a circle.  This would look silly.  The ramp condition isn't enough, as just putting a little ramped steeple thingy on top of the house would lead to the same problem.  If the frequency of water placement for smooth surfaces is decreased vs. pools, you don't solve the problem until the frequency is low enough that it's essentially an aesthetic feature, which doesn't solve the water collection problem.  Making water soak into the ground would solve the rooftop issue, but then player-controlled water that you want to cover the surface would have troubles -- the core problem is that rain water should be less than 1/7 units, but the game doesn't operate at a finer resolution, and rain is only realized as a flow when it is around the scale of regular water (ie a river).

There are all sorts of different angles that could be used to attack this problem.  Raindrops don't place water all the time, so depression detection could be pretty easy -- once the raindrop says that it is one of the 0.1% of raindrops that actually tries to place water, it could just flood out a very small distance searching for ramps and walls, and if it gets a certain percentage of the frontier blocked off, it can place the water.  Since 0.1% is very small, and the flood out just needs to check 25 squares or so, there would be no lag from this -- it could also be precalculated and stored as a flag, updated with mining etc., if this were to be used elsewhere to the point that lag becomes a problem.  This would be enough to get aqueducts and player-made pools to fill up -- adding the smooth floor requirement would spare some trouble from existing map features, but that would just be something to test out.

On the other hand, there's a certain attraction to having water fall off of rooftops and so on.  As I said above, this is tricky with the current resolution of water.  The "wet bit" idea just puts off puddle formation by one step, so it doesn't address the main problem of circles flowing out from rooftops, but changing the idea a bit might work.  The goal might be to somehow let the wet areas spread out until they find a depression square as defined above (even if its underground), at which point they can consider adding one unit of water.  The issue here is how to judge the wet frontier -- tracing a raindrop from the roof down through wet areas to a depression underground would be expensive, even if it only does it for a few drops.  Combined with aesthetic puddle formation from a very low placement frequency on any smooth stone, it would work, I think, but I don't have an angle on the wet frontier at this point.  It would be cool to be walking up out of a smoothed stone tunnel and have the entrance inside be "wet" though, since some rain ran down there, or during a heavy ran have the lowest parts of the tunnel fill up with some water.  I haven't thought much about the ground saturation and so on, and combined with aquifers and all that, there might be more to do here.  CPU issues abound when specifying the aquifer amounts though.