Print

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

[NW_Kohaku]

All right, now I'm going to go out on a limb here and assume that whatever form rubble takes, we won't have to micromanage its disposal.  I highly doubt this will be the case, but for the purpose of argument I'll yield on that point for now.

Spoiler: By NW to keep the size of this down (click to show/hide)

Rubble Implemented as Item:

First off, if rubble is an item then there must be much difficulty traversing rubble-strewn landscapes in order to prevent people from paying it as much attention as they do with stones in the current version.  This includes an anti-quantum stockpile method, including a way to prevent dumping all that rubble into a 1x1x1 hole.

If more than one tile's worth of rubble can be compacted into a single tile, including via the dump method, then one may simply build everything wider then pack the rubble in the sides.  This defeats the purpose of having rubble entirely, except for making mining a slower process (which could have been done more easily by making tiles take longer to mine).

I cannot think of a way which this would work without either:

• a) the miner going back to idle until someone comes and hauls the rubble away, or
• b) the miner himself interrupting his work to haul the rubble away.

At least when trying to dig out hallways, without a job rewrite that lets multiple dwarves work together on a task.


Rubble Implemented as pseudo-fluid:

This method has some advantage over the previous, in so far as much that a miner could conceivably work continuously by spreading out rubble behind him as he goes.  However, as rubble will need to come 7/7 or suffer the compaction problem mentioned above, he will need to be constantly supported by rubble haulers or have to stop repeatedly.

This will require that the haulers stay on task and work efficiently, which in order to prevent micro would be a huge AI overhaul.

And of course, let's not forget the rewrite necessary for pseudo-fluids to exist in the first place.  Or the lag it is likely to cause.


Personally, I think rubble would be cool but I don't see a way to implement it that would work as part of the game.  Of course, I'm sure I didn't think of everything so feel free to enlighten me.  I'd like to be proven wrong here, but right now it looks like the fruit at the very top of the tree, if you understand what I mean.  Even if it can be done, if it can't be done easily I'd prefer that something else (maybe even two or three somethings) be done in the time which would be spent on it.

I don't think the semi-fluid method is proper, but I do believe that, while it will take some work to make function properly, making sand and rubble (gravel) behave as items which share some properties of fluids from an observer's perspective without actually being coded like a flow would work.

For starters, I think we're going to have to give up on a thought of having 5/7 gravel and 2/7 water fill a tile from the start - you would be able to have 5 gravel and 7/7 water in the same tile.  In fact, I still think we'd do best with a 3/3 gravel system than a 7/7 gravel system.

The idea would merely be that when a gravel item was dropped, it would look to "spill" into nearby tiles.  This would mean looking for open tiles adjacently below where it is landing to spill into instead of just staying in its own tile.  No concept of a one tile having 6/7 and the next having 3/7 type deal.  Only non-wallness of adjacent tiles on the z-level below counts.  It would spill randomly into any of those available tiles.  This should create the "step pyramid" concept.  Ramps would be reasonable, and might be created for "free" - as in, they don't count as gravel or need to be destroyed to return to gravel.  It's just an artifact of the sloping nature of the gravel walls created, spread out to the next tile, not a symbol of actual gravel being in the ramp itself. 

If gravel hits the amount that forms a wall and cannot spill elsewhere, it forms a wall.  Dwarves will need AI updates to keep them from doing this stupidly/accidentally like putting a wall in their own tile and killing themselves.

Miners should not stop and wait for rubble to be cleared per se - they should simply suspend jobs where there is no access due to rubble, and go on to the next mining job.  If you have a 3-tile wide hallway going from east to west that you are expanding further into the mountain, the miner might excavate the first northern tile, then the central tile, then the southern tile of that hallway, while allowing the rubble clearing crews to work.  If the northern part of the passage is not clear yet, the mining dwarf will check to see if other mining jobs are awaiting a miner.  If not, the miner will pitch in and help haul some rubble just far enough to give him some space. 

I would also like to reiterate that I think 3/3 gravel in a tile is enough.  Wheelbarrowers could take 2/3 at once, and carts might take something magical like 5/3s at a time if need be.  Being visited by a single hauler should be sufficient to clear a tile enough for mining to continue, in any event. 

Gravel/rubble should have at least some sort of option for auto-dumping, the way that the useless crap from butchering does.  Perhaps a special zoning designation could be set aside just for gravel/rubble, in case you want that stuff going somewhere other than where you want the rest of your trash.  In that way, you only have to designate where it gets dumped, have wheelbarrows or other stuff, and designated haulers. 

[Sadrice]

I think that if you haven't yet designated a rubble dump, it should have a somewhat sensible default behavior, like taking it to the nearest empty outside tile.  That should let new players get started on fortress building before they figure out zone management, as well as being handy for everyone else.I

I also think that wheelbarrows should carry more than a tile's worth of gravel, realism be damned.  Given how much time it takes haulers to dump stone as is, that sort of slowdown would be immensely frustrating both to new players and many (many) experienced players.

[Leafsnail]

I think that if you haven't yet designated a rubble dump, it should have a somewhat sensible default behavior, like taking it to the nearest empty outside tile.  That should let new players get started on fortress building before they figure out zone management, as well as being handy for everyone else.

So in other words new players would be confused when the entrance to their fort is suddenly blocked up without any input from them?

I also think that wheelbarrows should carry more than a tile's worth of gravel, realism be damned.  Given how much time it takes haulers to dump stone as is, that sort of slowdown would be immensely frustrating both to new players and many (many) experienced players.

Quantum stockpile of rubble filled wheelbarrows .

[Arkenstone]

Miners should not stop and wait for rubble to be cleared per se - they should simply suspend jobs where there is no access due to rubble, and go on to the next mining job.  If you have a 3-tile wide hallway going from east to west that you are expanding further into the mountain, the miner might excavate the first northern tile, then the central tile, then the southern tile of that hallway, while allowing the rubble clearing crews to work.  If the northern part of the passage is not clear yet, the mining dwarf will check to see if other mining jobs are awaiting a miner.  If not, the miner will pitch in and help haul some rubble just far enough to give him some space.

I was thinking of the case in which the number of miners isn't less than half the number of tiles being dug; which would mean every 1-tile wide hallway in existence.  And 3-wide hallways too, if you have more than one miner and don't want to micro with burrows.

I just don't see a way to avoid either the miner hauling every bit of rubble himself or leaving the site frequently without a job rewrite.  First off, you'll have to have priorities so he won't go hauling rubble when there's still more to mine.  Second, you'll have to be sure that he gets priority for that job over the hauler at the other end of the map.  Third, how do you keep the haulers on-site?


Imagine if you will that 3-wide tunnel of yours.  Let's assume the miner digs from the west, is the only miner, and doesn't get distracted; however all the haulers (which are assumed to be plenty) are over in your dining hall.  The miner digs three tiles, north to south, and the first two have haulers dispatched.  Now, your miner hauls that third.

Suppose he hauls it just one tile over, then mines the next tile, just northeast of the now-clear tile.  This one gets a hauler dispatched, and he mines the next tile, the one to his east.  He then puts the rubble in the only open spot available, the one at the entrance.  If this doesn't block it, the next rubble he hauls will.


Suppose he hauls it all the way out though.  First he'd probably need a wheelbarrow.  Assuming he had one already, then you'll still be making fairly erratic progress, what with only three tiles being mined at a time.  Of course, at this point you could say "that's why you use minecarts".  But even then the minecart will be full eventually.  Then who takes it out?  The one who fills it?  That could be the miner.  A hauler?  Then the miner will soon be back to the situation without a cart.  What if it went unaccompanied?  In that case you'll need powered rollers if it's going uphill at all, and you still are back to the miner without a cart.


Frankly, I don't see rubble 'working' (see note) without an overhaul of how jobs work.  That is my only problem with it.  I like the idea of realism; now that I've thought of it a bit I've shot down several of my own assumptions and am actually starting to want it in the game.  I'd like to see my dwarves acting together in concert on a complex operation like this.  But to get things running smoothly requires those gears to intermesh perfectly, and I just don't see a way to make them do so in the timescale (as in how long a year is) DF is set with.

Spoiler: Note - Definition of "Working" (click to show/hide)

By working, I mean working as part of a game.  Games are supposed to be an escape from reality; while realism (as in copying reality) can help one 'get into' the game more easily, too much quickly becomes wearisome.

Sure, realism is nice; but I don't want to see the reason why underground halls don't exist in real life.

I also think that wheelbarrows should carry more than a tile's worth of gravel, realism be damned.  Given how much time it takes haulers to dump stone as is, that sort of slowdown would be immensely frustrating both to new players and many (many) experienced players.

I think this would help, although I don't know if it'd be enough.  Especially given that the timescale means they take an in-game week or more to move one load.

And yes, quantum wheelbarrows would break the realism.  That they (or some other form of handwave) seem a probable prerequisite to make rubble work at this point is the problem I'm trying to point out.


EDIT:
I guess that rubble could work if all miners were rubble haulers and vice verse.  But the kind of system NW_Kohaku suggests (with separate miners and haulers) doesn't seem feasible to me.

[Martin]

Well, rubble and other items should never completely block movement. Not only does it prevent a gameplay difficulty it makes things like pathing basically impossible to implement, so we just can't go there. But it could make movement cost very high, which I think is fine.


I also agree that 7 jobs to clear one tile is too much. That's crippling considering that the hauling changes don't help that case until you get mine carts working. I think two wheelbarrow jobs or one mine cart job to clear one tile is adequate. We're already going to have to accept impossible things like caged elephants in wheelbarrows - so we need to strike a balance on realism no matter what.


More and more I think the winning benefit to rubble would be for it to have solid flow characteristics so you can make a giant tailings pile outside your fortress, with fully buried gravel reverting to the natural soil type so you can actually terraform the place a bit. It's also an important characteristic of above-ground fortress defense as the area surrounding forts were routinely leveled flat so there was no way to hide from line-of-sight and so that the defenders had a height advantage. While we're likely never going to get fractional heights (I think Toady mentioned that) we can at least be able to level out depressions in the land, and create new pastureland/forest land on maps that lack it.


The gravel would still have a block movement function only if there is gravel directly above it. That way you could still have a mechanism that could stop sappers without having it block movement when clearing out a room.

[Sadrice]

I think that if you haven't yet designated a rubble dump, it should have a somewhat sensible default behavior, like taking it to the nearest empty outside tile.  That should let new players get started on fortress building before they figure out zone management, as well as being handy for everyone else.

So in other words new players would be confused when the entrance to their fort is suddenly blocked up without any input from them?

That would be why I specified "sensible".  It should keep moving out, forming an anthill, rather than dumping onto your entrance.  It would also need to avoid burying the wagone or trade depot or other near entrance buildings.

[NW_Kohaku]

Quantum stockpile of rubble filled wheelbarrows .

If you want to keep constructing new wheelbarrows for every pile of rubble you generate per tile you dig out, go right ahead.

Personally, I think designating a downward slope to just chuck the stuff would be faster.

[NW_Kohaku]

Suppose he hauls it all the way out though.  First he'd probably need a wheelbarrow.  Assuming he had one already, then you'll still be making fairly erratic progress, what with only three tiles being mined at a time.  Of course, at this point you could say "that's why you use minecarts".  But even then the minecart will be full eventually.  Then who takes it out?  The one who fills it?  That could be the miner.  A hauler?  Then the miner will soon be back to the situation without a cart.  What if it went unaccompanied?  In that case you'll need powered rollers if it's going uphill at all, and you still are back to the miner without a cart.

It may be slightly abusable, but letting the miners just drag a rubble item one tile (with some slowdown) one at a time just until it hits the bare minimum in order to continue digging would be acceptable.

I still would think that any major excavation (meaning - you are removing stone from a broad area, like excavating rock to form an entire block of housing or a large room or excavating a whole vein of ore) would probably result in the "bucket brigade" where a wheelbarrow team would run from the mining site to the nearest cart stop stockpile and back while the miner(s) would be bouncing from one clear mining tile to another inside that work area. 

If you aren't doing anything terribly major, or if you're just doing a single tile wide hallway, then yes, it's going to be slower - that was one of the specific cases that are supposed to be slower. 

By working, I mean working as part of a game.  Games are supposed to be an escape from reality; while realism (as in copying reality) can help one 'get into' the game more easily, too much quickly becomes wearisome.

Sure, realism is nice; but I don't want to see the reason why underground halls don't exist in real life.

But keep in mind that of that three-types-of-gamers list, one of those three actually is called "Simulationist", and they actually want this kind of simulation in the game.

One of the other three, the gamist, may very well like the challenge of a logistics system needed to counter this problem.  This applies to those of mixed-types, as well, (and I include myself in those numbers), that enjoy designing and construction and also a challenge to constrain my construction. 

Seriously, if you have ever played any of the Sierra City-Builder games, or any city-builder type game beyond the old Sim Cities, this sort of thing is all you ever do, and people DO play those games.  (In fact, Cities in Motion is pretty much an entire game about setting up subway systems.)

I realize there are people who aren't going to want to play this way, they can turn the init option off, but there are people who DO want to play this way.  It's not just me and Sadrice, either, who enjoy playing logistics simulation games, just as the people who don't want rubble aren't just the half dozen people who chimed in during this thread. 

[Arkenstone]

It may be slightly abusable, but letting the miners just drag a rubble item one tile (with some slowdown) one at a time just until it hits the bare minimum in order to continue digging would be acceptable.

I do believe I considered that possibility in my post.  It ended with the miner walling himself in with rubble.

I still would think that any major excavation (meaning - you are removing stone from a broad area, like excavating rock to form an entire block of housing or a large room or excavating a whole vein of ore) would probably result in the "bucket brigade" where a wheelbarrow team would run from the mining site to the nearest cart stop stockpile and back while the miner(s) would be bouncing from one clear mining tile to another inside that work area. 

I don't know about you, but that sounds to me like that arrangement would take a lot of micro to pull off.

If you aren't doing anything terribly major, or if you're just doing a single tile wide hallway, then yes, it's going to be slower - that was one of the specific cases that are supposed to be slower.

I don't follow; are you saying that 1-wide hallways are supposed to be slower to carve out than 3-wide ones?

But keep in mind that of that three-types-of-gamers list, one of those three actually is called "Simulationist", and they actually want this kind of simulation in the game.

The reason I put that bit in spoilers was because I didn't want to argue that topic, only to clarify what my point of view was.  I am completely aware that my views are mine alone, and none others.  I did not assume anything about anyone's views in my argument; I was only pointing out what my problems were with your suggestion.

I realize there are people who aren't going to want to play this way, they can turn the init option off

An init option can be used to justify literally anything.  Therefore, I do not consider it a useful argument in our current discussion.

I am trying to work out if it is possible at all to include rubble in a way that 'ruins' the game for none (or at least few).  If it is not, then it is my opinion that it should be off by default if included at all.  I do not wish to argue the preceding sentence here, but am willing to on a separate thread if you desire.

[Leafsnail]

Personally, I think designating a downward slope to just chuck the stuff would be faster.

Until it gets covered in rubble?

[Arkenstone]

Well, rubble and other items should never completely block movement. Not only does it prevent a gameplay difficulty it makes things like pathing basically impossible to implement, so we just can't go there. But it could make movement cost very high, which I think is fine.

[...]

The gravel would still have a block movement function only if there is gravel directly above it. That way you could still have a mechanism that could stop sappers without having it block movement when clearing out a room.

Hm, that's a very clever solution.  I think that rubble might actually work like that.  This idea invites further discussion and inquiry.

[vidboi]

I feel that a lot of these problems can be solved with existing game mechanics. Firstly there's pathing, which I propose would be solved using a similar system to that used when a dwarf's path is blocked by another dwarf. In the current situation the dwarf finds another path to the tile where they were blocked before continuing with the original path. In the case of rubble the dwarf would push the rubble to a nearby tile as long as it doesn't cause a blockage (unless this is the only option). The system shouldn't require micromanagement and won't involve our dwarves running outside with wheelbarrows of rubble at inopportune moments. I also believe that the current fluid mechanics would also make rubble easier implement as they would form pyramids by "flowing" to other tiles. Unlike water and magma which flow to an adjacent tile when they are filled 1 level higher the rubble may only flow when it's 4 or 5 levels higher. Any non full tile could also act as a ramp, solving the ramp creation problem. Finally, modelling it as a fluid already has the existing mechanics for path blocking and would prevent rubble and liquids from doubly occupying a tile which I'm sure would please the realists.

[Arkenstone]

In the current situation the dwarf finds another path to the tile where they were blocked before continuing with the original path. In the case of rubble the dwarf would push the rubble to a nearby tile as long as it doesn't cause a blockage (unless this is the only option).

I thought that a blocked path currently meant being assigned an entirely new path, which in most cases would involve parts of the original path.

What you suggest with the "push out of way" and especially "as long as it doesn't cause a blockage" is no mean feat from a programming point of view.

[Martin]

Well, the real problem with items blocking paths is that you can't clear the items if you can't path to it. Toady would have to allow you to clear the tile from the neighboring tile. Every other blocking element in the game is either part of a larger structure (like a workshop) or a construction you can approach from the side - like a wall or tree, which then creates a drop, which the dwarf can then stand on and recover. Items as far as I can think of are NEVER picked up from an adjacent tile, except for a few special cases like fish and water, and the former is really 'created' in the inventory - it's never picked up, and the latter is 'created' in the bucket, also never picked up.


My approach allows you to *always* clear a tile because you can always path to it. Worst case with a deep pile of rubble is you need to clear the topmost tile, then you can approach the one below it. Blocking is REALLY problematic with items.

[Askot Bokbondeler]

except for a few special cases like fish and water, and the former is really 'created' in the inventory - it's never picked up, and the latter is 'created' in the bucket, also never picked up.

since we don't really want rubble to be traceable in the same way as regular items to save memory, it could use the same code as water. i'd even suggest using a bucket or handcart as a requirement for gathering rubble
the way i see it, toady would only need to implement a mechanic for semi fluids based on the fluid physics we already have in game, tweaking it to make those fluids only flow when there was a difference greater than 1/7
so this would stabilize like this and stop using up cpu in a few ticks

Code: [Select]

... .1. .1. .1. .1. 11.
.7. .6. .51 .41 131 121
... ... ... .1. .1. .1.

and this would flow like this

Code: [Select]

▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒
▒7. ▒61 ▒51 ▒41 ▒32 ▒22
▒.. ▒.. ▒1. ▒11 ▒11 ▒21
this could be done with a simple tweak to the cellular automata that governs current flow mechanics, and would only be cripplingly taxing to the cpu during very large caveins as flow wouldn't be continuous like current water flow