Print

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

[Rowanas]

[CAVEINS:OFF]

Next topic.

[cerapa]

[CAVEINS:OFF]

Next topic.

You missed the topic. This is about having to dig smaller than 7x7 areas in the 2d version and still not digging them out, regardless of the differences of the 2d version and 3d version.

[smjjames]

What happened in the 2D version if you tried to dig out an area bigger than 7x7 a cave in I guess?

Sometimes I do put supports (the constructed kind) under big hanging ledges as it seems like they wouldn't stay up under it's own weight.

I was also putting pylons under the dock for a lake that ended up failing since it just made sense.

[Granite26]

I think some of the strain of a physics system could be taken off by prioritizing stress-prone areas, or even keeping track of only which objects exceeded a certain stress threshold. Then objects could update and transmit those stress variables as needed and adjust the list. While this wouldn't be 100% realistic it would be pretty decent, and CPU stress would be highest only in times of collapse or near collapse. However this is not only non-trivial to implement, but it probably would still have fairly detrimental effects on FPS. Another way to handle this is to bundle several connected structures together that have similar stress readings, so that stress is transmitted between macro units before being distributed on the micro level.

I'd be surprised if water doesn't already have some kind of optimization in place for grouping bodies of water into major units, but if it doesn't then there's actually room for significant improvement in the framerate.

Except it's basically a huge math and map rewrite for the benefit of 'Caveins', so the cost/benefit isn't quite there.  I imagine it's on the pile of things that will happen the next time the map code gets hit (and I don't think even UD involved that)

[Lummox JR]

Except it's basically a huge math and map rewrite for the benefit of 'Caveins', so the cost/benefit isn't quite there.  I imagine it's on the pile of things that will happen the next time the map code gets hit (and I don't think even UD involved that)

Yeah, definitely; I don't think this is really that practical at all. It seems in theory like it'd be possible to do and do it at a decent framerate with some thoughtful design, but I don't see it happening anytime soon. I think a lot higher benefit will be achieved from many other new features on the drawing board.

[Hyndis]

Too much cost, both in terms of coding time (do you really want Toady to spend 4 months on this?) as well as CPU cycles and too little of a benefit.

Often times you can abstract away complex things and get a good enough result. Its not perfect, but its good enough. And the abstraction saves tons of manhours of programming/testing time as well as system resources which will be better put to use on other things.

[Jimmy]

What happened in the 2D version if you tried to dig out an area bigger than 7x7 a cave in I guess?

You'd get a warning message a few times, then it would cave in, leaving a few times of wall that was similar to half-mined stone (i.e. not smoothable).

[Rose]

One advantage of the current system is that it's possible to build bridges out of constructed floors instead of using retractable bridges or drawbridges. When I built a long aquifer I gave it supports, but a proper bridge over a major river would never be possible if this was re-implemented without some changes.

wait.... so nothing like this?

[Sizik]

It'd make more sense to only re-calculate cave-in physics whenever the structure changes (e.g. during mining, construction, etc.) instead of every frame like water, as water moves while stone doesn't (unless there's a cave-in).

[Endek]

I think the main problem with applying real physics (shear/tensile strength and compressive stresses) to DF is that it would need to check every single tile against a minimum of 26 others, but in 99.99% of cases, it would need to check against a whole lot more.

It would be lovely to see, and it could be quite simplified so that the stresses are only recalculated any time there is a big change, and that large areas are treated as a single unit - or Toady could go down the Red Faction Guerrilla route and apply the physics to constructions only, and maybe soil/aquifer/wet rock layers.

Example from real life: When digging tunnels if the excavation crews encounter softer rock or water they are forced to slow right down because of the number of extra precautions they have to take to prevent cave-ins.

This could be represented by your miners slowing down, with the structural integrity being implicitly based on the knowledge of your miners.

Dabbling or Novice miners might go at full speed and cause (potentially delayed, but with the old creaking ceiling warnings) cave-ins in these circumstances, but other more experienced miners could have an Inspecting Excavation job and would then be involved in shoring up shonky excavations that they have found on their inspection tours.

[Grendus]

I think it would greatly slow down FPS while mining, in theory the game could calculate stress every time something changes, in practice since things change VERY fast when mining the game would be making constant, heavy calculations. I expect Toady will come up with something elegant to deal with this, but I doubt it's high on the priority queue.

[Atlas]

I think the main problem with applying real physics (shear/tensile strength and compressive stresses) to DF is that it would need to check every single tile against a minimum of 26 others, but in 99.99% of cases, it would need to check against a whole lot more.

It would be lovely to see, and it could be quite simplified so that the stresses are only recalculated any time there is a big change, and that large areas are treated as a single unit - or Toady could go down the Red Faction Guerrilla route and apply the physics to constructions only, and maybe soil/aquifer/wet rock layers.

Example from real life: When digging tunnels if the excavation crews encounter softer rock or water they are forced to slow right down because of the number of extra precautions they have to take to prevent cave-ins.

This could be represented by your miners slowing down, with the structural integrity being implicitly based on the knowledge of your miners.

Dabbling or Novice miners might go at full speed and cause (potentially delayed, but with the old creaking ceiling warnings) cave-ins in these circumstances, but other more experienced miners could have an Inspecting Excavation job and would then be involved in shoring up shonky excavations that they have found on their inspection tours.

Oooooh.

A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.

That would be a reason to start with proficient miners instead of a team of novice ones...

[Hyndis]

Oooooh.

A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.

That would be a reason to start with proficient miners instead of a team of novice ones...

No, that sounds horrid.

Let say you start your fort. Your dwarves are rookies at what they do because you're just starting up.

A 3x3 underground space isn't enough room to store much of anything from the wag. Even corridors should really be 4 tiles wide to accomodate future growth for mature forts. You can't even reliably put a workshop into a 3x3 room, as this depends on where the blocked tiles of the workshop are.

So your newbie miners are digging, and you get a cave-in. The miner is killed by the collapse, and now your mining pick is lost under the rubble.

Also there could be no planning for future constructions. You'd essentially have to have your miners practice until legendary, and then start digging out the fortress. Expanding from small tunnels to decent traffic paths can be quite difficult to do, particularly if you're planning on engraving. Constructed walls cannot be engraved.

[Granite26]

A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.

That would be a reason to start with proficient miners instead of a team of novice ones...

I like that.

I think it would greatly slow down FPS while mining, in theory the game could calculate stress every time something changes, in practice since things change VERY fast when mining the game would be making constant, heavy calculations. I expect Toady will come up with something elegant to deal with this, but I doubt it's high on the priority queue.

Given the reasonable way flows are working now, it shouldn't be too bad, although I wouldn't mind if mining slowed down a good bit to begin with. You wouldn't want to calculate from scratch everytime, just know enough to know what depends on that block.  Any pressure on it would need to be redistributed.  If it couldn't THEN you hit the cave-in code.

Bonus points for adding 'capacity' so that a dwarf could cause a cavein by standing in the wrong place without checking everything again.

[LordZorintrhox]

Well, the game already tracks the accessibility of locations to each other.  This means it must run the pathing algorithm, at least when accessibility matters, to see if you can path to a location.  Also, Dwarves check if they can path to a specific job before they take it on, or at least before they move.

This means that there is a crap-ton of information being produced all the time about where there is open walkable space.  If this information could be saved and culled only for areas considered "inside," then the engine has a way of checking only a subset of the map area where cave-ins would matter, as 1: if a dwarf can mine or build something, then it must be able to path to it and 2: only mining or building something can lead to a location that can cave-in, assuming world gen can take such things into account either explicitly or implicitly.

Since your fortress likely only includes no more than 10% of the total volume of the map (in standard play), and if the pathing information is compressed enough, this should give the CPU enough hints to check only a small subset of the total map for cave-ins.  Ideally, you'd set up a really dump algorithm that can determine, with very few operations, if a given tile cannot support itself.  Something like IF (solid density * volume constant) > (shear strain max), THEN COLLAPSE.  If you normalize shear strain in by dividing by a volume constant at load time, then it is a simple comparison.  That pushes the collapsed tile onto a stack of collapsing tiles, which cause the engine to check surrounding tiles next frame (with higher priority than the rest of the check list).  A "has changed" flag on the check list also speeds this up and is easy to determine.  You'd still get some lag with mining, but with some tweaks this could be minimized (check only every fifth frame, etc., or maybe a dynamic check spacing).