Content: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Background: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to TerraFirmaCraft Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    • Dries007

      ATTENTION Forum Database Breach   03/04/2019

      There has been a breach of our database. Please make sure you change your password (use a password manager, like Lastpass).
      If you used this password anywhere else, change that too! The passwords themselves are stored hashed, but may old accounts still had old, insecure (by today's standards) hashes from back when they where created. This means they can be "cracked" more easily. Other leaked information includes: email, IP, account name.
      I'm trying my best to find out more and keep everyone up to date. Discord (http://invite.gg/TerraFirmaCraft) is the best option for up to date news and questions. I'm sorry for this, but the damage has been done. All I can do is try to make sure it doesn't happen again.
    • Claycorp

      This forum is now READ ONLY!   01/20/2020

      As of this post and forever into the future this forum has been put into READ ONLY MODE. There will be no new posts! A replacement is coming SoonTM . If you wish to stay up-to-date on whats going on or post your content. Please use the Discord or Sub-Reddit until the new forums are running.

      Any questions or comments can be directed to Claycorp on either platform.
Sign in to follow this  
Followers 0
Draco18s

Better Cave-Ins

16 posts in this topic

Because my day was slow I happened to sit down with pencil and paper and work out a lovely set of cave-in rules for a voxel-based engine (such as Minecraft or Dwarf Fortress) that is transparent and doesn't rely on random numbers. This was targetting my hypothetical minecraft mod, inspired by TFC, but the rules work equally well for the goals of TFC.

Goals:

1) digging a block should always result in the same outcome. No "1 in 40 chance" of causing a collapse, the way TFC currently does for blocks that are sitting above an air block (i.e. "digging up").

2) a set of rules that translates to clear, visual structures ("a 6x6 room is safe, 7x7 is not")

3) being semi-realistic / believable ("sure, you can build a dome")

The following rules likely go back a long way, to a suggestion for Dwarf Fortress, though I'd be hard pressed to locate it. In either case, they were drafted without reference.

The mechanics:

1) Stone "damage." That is, there's raw stone (or smooth stone), fractured stone, and broken stone (along with cobblestone). Each has slightly different collapse conditions. The more damaged, the harder it will be to satisfy the rules to remain supported.

2) Stone "strength." That is, a given material can only extend over open space so far before it succumbs to flexural pressures and breaks, resulting in collapse. This is measured as a distance, in blocks, and applies only to raw stone.

3) When a block is mined, it forces a support check in the blocks orthogonally radiating outward (X/Z), that may potentially relying on it to remain supported. These blocks then determine if they are still supported, and if not, fall. (The code here is deceptively simple: block above and all blocks radiating along the X and Z axis out to a known distance (maximum strength value of all materials, which is either explicitly defined, or determined by reading the material properties, or determined at check-time by only updating blocks in a direction until a block that is directly above a solid block or a non-collapsing material is encountered)).

4) Support works thus: if a block is within "strength" number of blocks of a wall, it is supported. If it is not, it collapses. A wall is defined as a block that is 1 block lower than itself and orthogonally adjacent through solid blocks (any non-damaged stone). Eg:

###BW
Where B is the block doing the checking, and W is a valid wall. # are the orthogonally adjacent blocks. The number of these blocks is compared to the strength of the checking block (ease of coding, compared to checking the structural strength of every intermediate block).

5) If the distance exceeds the strength, then the checking block turns into cobblestone, turns the block above it into cobblestone, and turns the 9 blocks adjacent to both blocks into broken stone (which will also collapse, see broken stone below).

6) Fractured stone collapses if it is not orthogonally adjacent to an undamaged stone block (or supported from directly below). This is actually fairly easy to pass, but as it does not itself provide support, it may cause other collapses, or get damaged by other collapses (or both). When it collapses, it increases the damage of orthogonally adjacent blocks by 1 and turns into cobblestone.

7) Broken stone collapses if it is not downwards-diagonally adjacent to at least two other solid blocks (any type except dirt, sand, gravel, or cobblestone (see rule 8)). Per the creation in rule 4, those blocks will be immediately subject to collapse. When it collapses, it increases the damage of orthogonally adjacent blocks by 1 and turns into cobblestone. Per rule 4, this will cause all stone blocks 2 away from the originally collapsing block to become fractured.

8) Cobblestone is gravity effected. Cobblestone will provide support at a maximum of 2 blocks high. If pillared greater than two blocks and targeted for support it will attempt a side-ways shift (per the recent sand and dirt change to TFC) and likely cause a further collapse by doing so. This makes cobblestone a cheap way to support large, but low, rooms, as well as providing some insurance against continual collapse (as each collapse creates some cobblestone, which would stack up to support the ceiling, but digging it out might cause another collapse).

9) Minimum material strength would be 2, allowing for the creation of safe 4x4 rooms within even the weakest stone (technically 4xN, as only nearest wall is checked). Greater values would allow for rooms up to 2xValue in size (Dwarf Fortress in the 2D version had a global strength of 3, allowing for the existence of 6x6 rooms without internal support, although collapses were not instantaneous as they would be with these rules).

Fractured and broken stone would drop cobblestone (as expected) when mined (and have the same dig time as cobblestone).

Rules also allow for the creation of domed ceilings, simply due to how Rule 4 works. It merely looks for a single solid block 1 down and up to strength away. This would be safe, as every block is within a distance 2 of a supporting "wall" and would work for even the weakest of materials.

.....####........###..###.....##......##....#........#...##........##..#..........#..#..........#.

The rules also allow for some unrealistic structures, that should not be stable, but are:

(Assuming strength 3)

############################...#......#...###!####.....##.....#

Where ! is a block that is taking a large amount of weight and probably should collapse. However, it is valid with the mechanics presented here and attempting to locate oddities such as this are a programming nightmare, and can be ignored in favor of game play.

TFC already has horizontal and vertical support beams, these would be valid targets for "walls" per the above rules, and in fact, already behave in a very similar manner to the rules presented here.

These rules do not attempt to govern the building of structures, just the hollowing out of mines and other holes in the ground, but would probably work in any case.

5

Share this post


Link to post
Share on other sites

A simple, elegant solution is the best solution. This is both simple and elegant.

1

Share this post


Link to post
Share on other sites

What about in instances where you have a tunnel like this:

###############

###############

?

each little hanging down bit counts as a wall no? Shouldn't this configuration create infinite ceilings? The problem with doing this REALISTICALLY, is that to make it behave exactly as you want it to, you need to do block updates on all the loaded rock blocks on each update of a single block. There needs to be more concrete definitions of what a "wall" is, and better pathing algorithms for cave-in tracking. Cave ins shouldn't affect rock tunnels that aren't horizontally connected to the caving-in area, so you would need to path to all the blocks that cave in and recalculate whether they should cave in or not.

We chose to do a random algorithm for cave-ins because it appears to be pseudo-realistic without killing cpu on machines.

1

Share this post


Link to post
Share on other sites

What about in instances where you have a tunnel like this:

###############

###############

?

each little hanging down bit counts as a wall no? Shouldn't this configuration create infinite ceilings?

And each of those little hanging down bits is supported by what wall, where? ;) Remember, ever block is subject to the same rules. In order to get "infinite ceilings" you'd have to place a naturally floating block (such as a wood planks, bricks, inventory-hacked bedrock, pistons; assuming that such blocks count as support, which in the case of broken stone, does, but broken stone does not itself provide support, and in the case of smooth stone, should not--smooth stone should only respect smooth stone and bed rock) where each of those handing bits are.

(i.e. no, it won't allow for the creation of infinite ceilings)

The problem with doing this REALISTICALLY, is that to make it behave exactly as you want it to, you need to do block updates on all the loaded rock blocks on each update of a single block. There needs to be more concrete definitions of what a "wall" is, and better pathing algorithms for cave-in tracking. Cave ins shouldn't affect rock tunnels that aren't horizontally connected to the caving-in area, so you would need to path to all the blocks that cave in and recalculate whether they should cave in or not.

All of that is accounted for. The mined block only causes a set number of updates. If, for example, that all materials have a strength of 3, then only (up to) five blocks will get an update: X +/- 3, Z +/- 3, and Y+1 and will reference up to 80. If it ranges from 2 to 5, then it's 17 blocks and references up to 408. You don't need to path-find anything, all it does it check to see if a block in a path known at code time is solid or not. I.e. (X+1,Y,Z), (X+2,Y,Z), (X+3,Y,Z), and (X+3,Y-1,Z) (then the same for X-, Z+, and Z-). All of the checks are orthogonal and strait-line. As soon as a check fails, the entire path returns false (i.e. block (X+2,Y,Z) is not solid, (X+3,Y,Z) and (X+3,Y-1,Z) aren't checked).

Also, a mined block doesn't effect open spaces on the other side of a wall. When attempting to update blocks, if it passes through a stable wall, that ray is terminated and no blocks are updated beyond it.

i.e:

##......################X#####  <-- X is being mined####.#########.#########.#########.#####

A cave in check is not calculated north, east, or west of the drawing, because the mined block could never be the last support for any block in those directions. In the case of the south block, the mined block has no way of knowing for sure, so it tells the south block to check.

We chose to do a random algorithm for cave-ins because it appears to be pseudo-realistic without killing cpu on machines.

Fair enough. It just bothered me that I could cause a cave in by digging a 1 wide, 2 tall tunnel, simply by digging the bottom rock first. Or digging an upward stairway. Neither of which should happen.
0

Share this post


Link to post
Share on other sites

He does bring up one question. If one would define a wall as continuous vertical blocks that reach the floor, how would one calculate the floor?

(and keep in mind, that though running a cave-in check whenever a block is broken is simple, it gets substantially more cpu intensive the more blocks you need to check (ie. checking if it's touching a wall, then checking if that wall is actually a wall, then repeating 40 times). No one wants half second lag spikes whenever you break stone.) But you probably already though of that.

0

Share this post


Link to post
Share on other sites

He does bring up one question. If one would define a wall as continuous vertical blocks that reach the floor, how would one calculate the floor?

Bed rock. But you don't need to path all the way way to the floor. As long as any given block can calculate a block that is below itself and in range horizontally, that block is known to be stable when the calculation is run. Open space created due to terrain generation/caves is ignored, in order to save CPU. 99% of the time, cave structures will adhere to the rules above, and when it doesn't, we shouldn't cause mass on-map-load collapses, for the same as with floating sand.

And if a collapse occurs to leave hanging structures that shouldn't otherwise exist. Whatever, it's Minecraft: land of the floating islands. It happens, and it's guaranteed to collapse if you try digging near it.

(and keep in mind, that though running a cave-in check whenever a block is broken is simple, it gets substantially more cpu intensive the more blocks you need to check (ie. checking if it's touching a wall, then checking if that wall is actually a wall, then repeating 40 times). No one wants half second lag spikes whenever you break stone.) But you probably already though of that.

You only need to run the check the number of times I indicated. If a block finds a wall, that wall does not also need to check for support as it already checked and it is known to still be stable, because it is impossible for an update to have occurred for causing it to lose is last support and not cause it to collapse.

0

Share this post


Link to post
Share on other sites

so then

###############.#.#.#.#.#.#.#.#.#.#.#.#.#...............##############

would work?

0

Share this post


Link to post
Share on other sites

so then

###############.#.#.#.#.#.#.#.#.#.#.#.#.#.

would work?

And what's supporting that bottom row? ;)

At some point you have to go "well that's un-touched ground" / "bedrock"

If you're saying that it's a bunch of 1x2 tunnels boring through the mountain: yeah, that's stable. But it's not an infinite ceiling.

0

Share this post


Link to post
Share on other sites

No, you don't seem to understand. Your idea would cause tens of thousands of block updates each time a block was mined. It would lag many lower end computers and put a heavy strain on servers, and for a server based mod, this won't work.

a 10x10x10 cube of blocks has 1000 blocks in it.... (as you should know)

0

Share this post


Link to post
Share on other sites

How would my suggestion cause tens of thousands of updates? Any given block can only update 5 other blocks, most of which will do nothing. A moderately complex redstone contraption would have more updates.

You're probably trying to see a support cascade effect, but it's not there. All blocks are assumed stable at generation time. It's only when a block is mined that a mere 5 blocks need to check to see if they are still stable. Those 5 blocks do not cause additional updates unless they collapse, but a collapse cascade would be extremely rare and not involve more than two dozen blocks, unless intentionally set up to cause a cascade effect.

0

Share this post


Link to post
Share on other sites

That's not how it works in real life. We went through permutations of code rather similar to yours and all were way too easy to exploit. There is always a configuration that gave perfectly stable ceilings, even if they shouldn't have worked in real life. TFC isn't a shot in the dark, we experiment with each new feature.

0

Share this post


Link to post
Share on other sites

That's not how it works in real life. We went through permutations of code rather similar to yours and all were way too easy to exploit. There is always a configuration that gave perfectly stable ceilings, even if they shouldn't have worked in real life. TFC isn't a shot in the dark, we experiment with each new feature.

Can I go ahead and quote you back at yourself?

That whole "TFC isn't about realism, it's about believability" thing?

The current implementation already allows for infinite ceilings, as long as you only dig downwards.

0

Share this post


Link to post
Share on other sites

calm down. I've had a chat with Bioxx. TFC already has code that would do EXACTLY what you have suggested, but we can't use it because it requires 1000s of block updates to function at any level NEAR where it currently does. I'm sorry if you can't see why your suggestion is flawed, but it is.

0

Share this post


Link to post
Share on other sites

Then either a) you're going to have to explain it or b] show me the code or at least c) tell me what class file to find it in, so I can decompile it and look at it for myself.

0

Share this post


Link to post
Share on other sites

no time bro

2

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0