Print

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

[SquashMonster]

Grek: Unfortunately, it would mean making the algorithms work differently to keep checking upwards like that.  Currently weight only moves one tile at a time, and moving the weight back up would probably cause very weird interactions with the downward weight distribution.  I can't look into it now, but if I get a chance I'll get back to you.

Merlon: Thank you.  The weighting for collapse strategy you proposed will work most of the time.  However, sometimes the cube that gets removed will cause a cascade failure.  You can simulate this yourself in the program by getting a cave-in state and removing all the highlighted tiles (or shifting down the column, as appropriate).  It'll sometimes leave new highlighted tiles.  Though, personally, I like the idea of using cave-ins to engineer caverns carrying a risk of complete failure.

Draco: The weight distribution of above layers does effect what is possible.  This is intentional, as without it doing that you can do some very ridiculous things.  For example, if above layers had no effect, you could support a gigantic room on a massive pillar, and then have another large room directly under the pillar.  ...Without the force of the pillar above it destroying the entire room.

Fieari: I agree.  I tried to get as close as possible to the 7x7 rule with the material I used for that example.  A more complete approach would have different properties for different materials.  Hopefully the devs will like my algorithm enough that thinking of properties for all the different materials will be worth it  .

[Fatum]

SquashMonster, your algorithm is an iterative one, isn't it? So, the more tiles we have, the more computing resources each tile requires?
If so, how can it be implemented in the game with it's multi-layer huge maps?

[Elvenshae]

[Draco18s]

That's....terrible.

[Cavalcadeofcats]

Nice.

Man, this bit of necromancy confused the heck out of me. Took me half the thread to realize what had happened.

Elvenshae made it all worth it, though.

[Elvenshae]

Yeah, I saw the day, but skipped the year, and thought this was all current until I came across a post that said, "Dwarves will walk diagonally in the next version."
 
Then I was all, "Waitaminute ..."

[SquashMonster]

Yeah, it is an iterative method.  It's relatively fast, though with the current speed DF runs at, adding anything is a problem.

I think you could get it in without causing much slowdown if you used the same iteration to handle this algorithm as used to handle the fluids algorithm.

That is, if the fluids algorithm used such an iteration.  At the moment it does not.  However, the fluids algorithm is also currently not a local model, which Toady said he wanted to use.  The only local model I know of requires an iteration of around 6 steps*, which would work with the suggestion of merging them.

So really, if he wanted to use a cave-in algorithm like the one I suggested, it would be best for him to wait until he redoes the fluids, then handle it at the same time.

[Sukasa]

Well, what you could do is combine a feature of the water physics in, that is to have a flag on tiles that controls their stability- for X number of tiles past a stable tile, calculate them as part of the satbility check, and after calculating anything that is in no danger of collapsing should be marked 'stable.'  Every time you dig out a tile, then the surrounding ~7x7 area has that flag cleared, all along the Z axis.  Thus, stability checks only happen on newly modified or particularly stressed sections of the fortress architecture.

[DJ]

I fear that any realistic algorithm will be too much of a drain on system resources right now. So, until DF gets some optimization done, I propose return of the old 7x7 algorithm. Basically, if a tile doesn't have a supporting tile one z level below and within 7x7 tile on x and y coordinates, it caves in.