Print

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

[Forumsdwarf]

Every support throws a 7-square radius.  Any mined square not within a radius collapses.
It's a little too lenient, but it's simple.

[Capntastic]

quote:Originally posted by Forumsdwarf:
<STRONG>it's simple.</STRONG>

Then what business does it have being in DF?    :p

[Railick Stonemane]

Seems like it would be really simple to just highlight walls for supports instead of having them built in the middle of rooms. Any large room without supported walls would fall on itself after a set amount of stress or time. For example if you dig a small tunnel it could be left unsupported because there is very less stress on its walls. However if you build a large room with a two Z level high ceiling and don't support the walls before hand you will get a cave in. (Supporting the walls in this case would abstract away supporting the ceiling since they don't exist yet. Just imagine the dwarves building archs or supports up to the ceiling to hold it up) Maybe in VERY large rooms you could still require supports in the center for no amount of wall supports would hold up the center. Likewise you could put in archs that could go across the ceilings of high Z level rooms to support them without any supports on the ground level.

[Sowelu]

Any option that doesn't allow massive 12x12 open spaces, even with enormous multi-level vaulted ceilings and supports three tiles thick, just plain isn't good enough!

...Actually, now that I think about it, you could still vault ceilings based on that method.  But then you could also support an arbitrary-sized upside down pyramid on a single tile of sandstone.  Hmm.  

[Forumsdwarf]

Special constructions that allow larger rooms are a great idea.  It would give your architect more to do.

[Quintin Stone]

It'd be cool if your ceiling materials affected cave-ins.  For instance, a steel roof can have more unsupported than various types of stone.  Not a big deal though.

[Drahflow]

I have a proposal which reflects both weight and torque. (the latter being
the thing which usually beats you:

code:

WWWWWWWWWWWWWWWWWW
W

This will fail at the lowermost wall, not because of the weight of the stuff
above, but because it's hanging too far right.

So my proposal:
Attach to every voxel a grid of support it can give.

code:

[ 18][ 25][ 30][ 25][ 18]
[ 25][ 35][ 40][ 35][ 25]
[ 30][ 40][inf][ 40][ 30]
[ 25][ 35][ 40][ 35][ 25]
[ 18][ 25][ 30][ 25][ 18]

Every number in this grid specifies how many "Weight" the voxel can support
at a spefied position. The middle is right above the voxel and should usually
be infitiny, unless the material is really bad for building, say wet clay or
something.

When checking the mountain, start from the bottom and assign every voxel just
these values. Then continue checking voxels which have any connection to
neighbours but not yet assigned any values. Continue then in rounds until
no voxel changes values anymore or all voxels are supported.

To get the support values of this voxel, consider every already calculated
neighbour and maximize the results over them. Every entry in the grid of
support values will be the minimum of the associated entry in the neighbour
(reduced by the weight of the voxel itself) and
the maximum support value for the voxel material
For better realism, if the neighbour under
consideration is exactly below the voxel, just substract the weight on
those positions where the support from the neighbour is greater or
equal to the central support (this make higher pillars possible, which
still support roofs).

Additionally save into for support value which voxel was responsible for the
value (i.e. which voxel the minimum was from). If both values are equal,
use the newly considered voxel.

Example:

code:

I
GH
 F
BCDE
A

Assume for example purposes these small material support numbers:

code:

[ ][ ][1][ ][ ]
[ ][1][3][1][ ]
[1][3][3][1]
[ ][1][3][1][ ]
[ ][ ][1][ ][ ]

The above construction would get the following support grids:

code:

A:                minimum source
[ ][ ][1][ ][ ]   [A][A][A][A][A]
[ ][1][3][1][ ]   [A][A][A][A][A]
[1][3][3][1]   [A][A][A][A][A]
[ ][1][3][1][ ]   [A][A][A][A][A]
[ ][ ][1][ ][ ]   [A][A][A][A][A]
B:
[ ][ ][1][ ][ ]   
[ ][1][3][1][ ]   
[1][3][3][1]<, 
[ ][1][3][1][ ] | 
[ ][ ][1][ ][ ] | 
          ^-----C located here
    
C:
[ ][ ][ ][ ][ ]   [A][A][A][A][A]
[ ][1][ ][ ][ ]   [A][C][A][A][A]
[1][3][2][ ][ ]<, [C][C][A][A][A]
[ ][1][ ][ ][ ] | [A][C][A][A][A]
[ ][ ][ ][ ][ ] | [A][A][A][A][A]
          ^-----D located here
D will not be supported. Minimum source was A, so A will be failing.
F:
[ ][ ][ ][ ][ ]   [A][A][A][A][A]
[ ][ ][ ][ ][ ]   [A][C][A][A][A]
[ ][2][1][ ][ ]   [C][C][A][A][A]
[ ][ ][ ][ ][ ]   [A][C][A][A][A]
[ ][ ][ ][ ][ ]   [A][A][A][A][A]
                              
H:
[ ][ ][ ][ ][ ]   [A][A][A][A][A]
[ ][ ][ ][ ][ ]   [A][C][A][A][A]
[ ][1][ ][ ][ ]<, [C][C][A][A][A]
[ ][ ][ ][ ][ ] | [A][C][A][A][A]
[ ][ ][ ][ ][ ] | [A][A][A][A][A]
    ^-----------G located here
G:
[ ][ ][ ][ ][ ]   [ ][A][A][A][A]
[ ][ ][ ][ ][ ]   [ ][A][C][A][A]
[ ][ ][ ][ ][ ]   [ ][C][C][A][A]
[ ][ ][ ][ ][ ]   [ ][A][C][A][A]
[ ][ ][ ][ ][ ]   [ ][A][A][A][A]
I will not be supported, because of C, so C will be failing.

Furthermore I think it would be great if the failing voxels would be removed,
so chain reactions are indeed possible (as they are in reality).

It should be possible (maybe by an architect) to gather information about how
much support is available where so the user can plan where to mine and where
not.

The 5x5 Grids shown in these examples are most likely not sufficient, as they'd
only support 8x8 large rooms. But this can easily be fixed by using larger
grids. Since usually all voxels will be supported (or they won't need to be
calculated very often again), the algorithms will for usual caves be
linear in the number of voxels. Using elaborate up-down-left-right-zigzag
constructions of steel however, it could get a bit slower.

Since the support grids are attached to the material of the wall it would be
possible to build supports into walls, even some optimized supports for
certain directions:

code:

A steel support of the form
x-----x
|
|
X

(useful maybe in the corner of a room)

would have a support like:

code:

[ 1][ 2][ 7][13][12]
[ 2][ 8][11][15][13]
[ 7][11][uu][40][20]
[13][15][40][60][30]
[12][13][20][30][40]

The exact shape and values of the support grids would need to be found out
by simulation, I suppose. If Toady considers this approach to be
computationally feasible in his current framework, I'd be grateful to write
some simulation for it.

[Forumsdwarf]

Well it's not "simple" but ... wow ... nice work.

[TrombonistAndrew]

Any cave-in algorithm that will be feasible in DF will probably only run at digging or construction completion, or upon a special event like an earthquake or some poor tanrtuming dwarf destroying a support or something. Anything that requires checks every turn will automatically fail, being too much of a resource hog.

And the algorithm should not have to check the entire mountain; it should be able to isolate affected squares to save computation resources.

. . . and, since I'm on a roll that no one but me will probably ever read, this means that the algorithm should probably actually be two algorithms: one for cave-ins caused by digging, and one for collapses caused by building. The first checks higher Z-levels; the second checks the current and lower Z-levels.

[ January 31, 2008: Message edited by: TrombonistAndrew ]