Print

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

[Draco18s]

quote:Originally posted by Eagle of Fire:
<STRONG>This thread make no sense.</STRONG>

I concure.

[Fedor]

quote:Originally posted by Eagle of Fire:
<STRONG>
Are you guys insane. Of course it did! The game always crawled to an almost halt everytime you tryied to flood a big room in 23a. It's only when the room was either completely full or completely empty that the game was going back to it's original framerate...

This thread make no sense.</STRONG>

My bad.  I was unclear.  That particular section dealt with, not artificial flooding, but the cave river overflowing.  Perhaps I should have reiterated that in my response to maximize clarity.

---

Just to press the point on a similar topic, this time the case of artificial floods:  One much-appreciated thing about the (admittedly MUCH less interesting!) 2D rendition of fluid motion was that, once a room or channel finished flooding, the fluid hardly used up any CPU time.  So we players had the freedom to build absurdly elaborate shaped channels (within the limits of the old game, of course) without worrying about play slowing down excessively.

[Stromko]

I don't see much wrong with the initial post, and I don't see how people can get all whipped up and fanboyish when he's suggesting Toady add features from a game that Toady made. "Are you saying that Toady is a better dev than Toady? I hate you, go play Dwarf Fortress if you don't like how Dwarf Fortress is!" <-- huge exaggeration to try to make my point.

I don't agree with some of the suggestions, like I don't mind the 1/7 water scatter thing because they don't block movement or even building. I would expect to see puddles after I flood an area, and they're temporary anyway so they don't matter.

I was just thinking myself though that I'd like to see replenishing cave features and more cave dangers though. There should be logical methods to 'tame' these features, like covering up or collapsing pits and chasms, but it'd be a real project instead of just one big do-or-die clearance operation followed by calm.

I would expect it'd make cave features less laggy as well, if instead of having a few dozen entities constantly in them, they'd just appear from a logical 'off the map' location every so often in appropriate numbers. They could also be more dangerous in this way if they came in enough numbers to wreak atrition on your military, creating a desperate situation where you had to tame these features ASAP.

[ January 06, 2008: Message edited by: Stromko ]

[CharonX]

The main objection I took was to the "he did it before, just do it again (lazy git)" tone I felt from the posts. Suggestions are nice, that speed should be increased, code optimized and lags removed is a given, but saying "just do what you did before" when the circumstances have totally changed seemed a bit snobbish.

[Sergius]

quote:Originally posted by Fedor:
<STRONG>I'd like an apology for this statement. You're grossly out of line here. I'll be happy to explain precisely why if you're still in any doubt.</STRONG>

I also love apologies. I suggest you apologize to me now.

[Deto]

Fedor has its points. I do think its a suggestion, just in... well... informative way, not suggestive way  

I've got two ideas, probably already considered, didn't just see in the post.

///
Water splash, level 1 water:
Maybe it could be displayed as blue ground icon, if ground is smoothed, it would be blue +, if not, it could be ,. etc

Maybe level 2 should be what level 1 is now, you could walk on it, build on it and so on. Sort of like small flood kind of water level?

///
Another thing, toady probably already has considered it, or is working on it already. Water, as... currently... only 7/7 'map starting' water is considered static and others are all the time running on fluid mechanics, maybe there could be change that when water reaches 7/7 status, by any means necessary, the game would run fluid checks for say... one second (whichever amount of frames that is) and then convert the fluid mechanic water to static water similiar to onces in rivers?

I don't know if it would reduce lag, might, and might not... But... I think its worth a shot  

[rkyeun]

I think a lot of flow framerate issues could be solved by removing the 'randomness' from a flow. It's common to see a 6 zipping around in a pool of 7 after you draw water from it, and all those motions and the decision of which direction to move are both pointless and time-consuming.

I would propose that tiles keep track of their water contents as floating point numbers from 0.0 to 7.0. 0.0 would mean the mud has worn off and you have dirt or bare floor again, <1 would be muddy tiles which don't flow, 1 to <2 would behave like 1 does now, and so forth.

Outdoor spaces could have water and mud slowly evaporate based on temperature, adding to the weather flow, and rain down somewhere else outside and add to that water/mud.

Then instead of randomly deciding which way a single unit of water is moving, split it so it spreads evenly across the tiles it can fill. This will resolve floods faster instead of having laggy bits where you have to wait for all the 5's to get through so the 6's can start flowing. It'll all move smoothly.

[Nate879]

I agree that finer granularity in water would be nice.  But floating-point numbers are slow.  One way to have finer granularity would be to represent water level internally as a number from 0 to 255 (a byte).  If you want to keep the 0-7 water level, just show the player the quantity WaterLevel >> 5.  That would give a number in the range of 0-7.

[CharonX]

This might impact speed from flow mechanics even worse...

I don't know the the code but I guess there is a section in it that disables flow calculations if an equilibrium has been reached (7/7 pools mostly) until  said equilibrium is disturbed somehow (water leaves through new channel etc.).
Going to finer granularity would make reaching an equilibrium much slower...
Also it would double the space required to store information about the square.

Then again, by adding a finer granularity (without causing killer lag) Toady might be able to create some nifty effect:

code:

Current workings of "space"       Idea for new "space" model
###  <- Ceiling (T/F)             # -
# -                               # |
# |                               # | <- Top Layer of Air size (256-X)
# |                               # |    filled with up to (256-X) fluid
# |  <- Solid or "air" filled     # -
# |     with 0/7 to 7/7 fluid     # -
# |                               # | <- Bottom Layer of "Solid" size X
# -                               # |
###  <- Floor (T/F)               # -

The presence (or absence) of a ceiling would be determined if the space above the current cell has a Bottomlayer > 0 (can be done via setting a flag to avoid constant re-checks)
The actual height of the Bottom layer should probably (at least initially) work like it works right now - either it is there with fixed Height 32 or it has height 0. (Later Toady could expand the system by allowing a finer granulation e.g. for determining where rain would gather etc. - of course without doing a detailed drop-for-drop-I-kill-your-framerate-calculation)
Brooks could be implemented by having the brook flow in a square with 0 bottom layer (the surroundings have a bottom layer "boxing" the brook in) over a solid ground square. Deeper rivers would flow similarily but over squares that have "air" space (filled with water). Dwarves would be able to wade through water less than 3*32 deep (crossing brooks).

Further ideas: like mentioned above a "still water" check, for lakes and pools (probably already implemented), but with a bit of extension. Group water that is adjacent to other water into groups. If a group of water (in total) does not gain or lose water fox X seconds AND if it is (roughly) equal in height (max diffence over all "surface water" <=32 aka 1/7) AND if the body of water has settled down (no changes in water height heigher than 32 aka 1/7 in the last X seconds) assume water has settled down and equalize water height among all surfaces (this will either lead to a surface to be slightly heigher than k*32 or slightly lower, deping on if we shuffled around "gaps" or waves) then shut down flow mechanics for waterbody until it is disturbed again.

Actually I think this was part of the "magmawall" bug a few versions ago (a body of 7/7 magma wouldn't flow if you had it "walled in" by building walls, then removing a wall - the body was still considered inert due to failure of the wall-removal to flag the magma "disturbed", and so no flow mechanics check would be run)

[ January 06, 2008: Message edited by: CharonX ]

[numerobis]

The new flood mechanics seem to have increased the flamerate at any rate.

I'm not convinced that every map should have danger.  However, the UI for picking the initial map could be improved: "give me maps that have feature X" would be a nice-to-have (where X is magma, or aquifer, or dragons raiding every other year -- their flamerate really increases the framerate a lot, by the way).  There are many things I'd prioritize much higher than this, though.

[Mike Mayday]

In my opinion, digging in the vertical level should be a much more tedious experience:
Digging all the way to the bottom-most level from the surface should take approximately as much time as digging to adamantine in the 2d version. To preserve the ease of digging the initial fortress level, digging vertically in soil could still be as quick as it is.

Vertical based obstacles are also a good idea (already mentioned). My dream is an actual Underworld to dig down to (Ultima5 style). It could be made so that exploring the system of caves looking for a good place to descend would be easier than just digging down. Impenetrable or nigh-impenetrable rock? I mean, why not? This is a fantasy world after all.

[rkyeun]

My apologies. I realize now I was too vague about my previous flow suggestion.
I did not suggest only finer granularity, I also suggested a new algorithm to take advantage of it.
Floating point numbers aren't that much slower, but they do take more memory space.

Suppose a tile 5 full of water is connected to four other open spaces, and has a 7 trapped behind it.

000
05X
XX7

Currently the game decides randomly how water will flow between the 5 and the surrounding 0s. One will get 2 or 3, another few will get 1, and some still may be left blank. A 2 in a sea of 1 zips around randomly looking for that last 0 to plop down on top of and stop. All of that is wasted framerate.

Using floating point lets you split the water evenly across all accessible tiles.
Now the 5 looks at the four 0 tiles, and just assigns them and itself 1 to smooth itself out.

111
11X
XX7

The 7 behind it looks out over that and sees
the five 1s it can reach. So it splits itself.

222
22X
XX2

And the flow is done.

This might be a bit shortsighted on my part, but I'm hoping it can help some.

[I3erent]

quote:Originally posted by Bricktop:
<STRONG>What the game really needs for more interesting gameplay is more hidden stuff. At the moment there is barely any challenge. The armies will probably add a bit more challenge as seiges could be more common, but we need more stuff underground. There have been hundreds of topics listing loads of possibilities ranging from buried temples to caverns full of dinosaurs.</STRONG>

Apparently there is tons of hidden stuff we never found even from the old version, toady said so once.

[Align]

quote:Originally posted by rkyeun:
<STRONG>I did not suggest only finer granularity, I also suggested a new algorithm to take advantage of it.[..]</STRONG>

Don't really see how floating-point helps with that. Might as well just make it fill adjacent space with least water in it, assuming water-level difference > 1. So 1-level water wont move, and a 2 in a sea of 1-level water won't move either.

[rkyeun]

So I can build a water pyramid that never drains?