Print

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

[JasonMel]

It strikes me that just telling a dwarf which side to stand on would be simpler than making sure to forbid all stone on the wrong side.

[Draco18s]

It strikes me that just telling a dwarf which side to stand on would be simpler than making sure to forbid all stone on the wrong side.

And have to specify for each and every wall or floor we build?  (Adding a minimum 2 keystrokes)

No thanks.  I'd much rather have them semi-intelligently figure it out for themselves (and make the occasional mistake).

[Jibekn]

Ide like to see 2 features from this vein of thought;

1. Selectable "Build from" just like the bridge designation of raise direction, build direction is applied the same way, if the construction is not accessible from that direction, standard logic gets applied.

2. Prioritization based on accessibility after the fact, meaning. when a dwarf goes to build a, lets say wall. It does a check, is there any constructions that will be 100% blocked if a build this tile? If yes, build the would be blocked tile (and redo the check) You could also do a hidden suspension system whereby a dwarf that cant build what he wants, but has to wait for another dwarf to finish a 'would be blocked' tile can go about his business. On construction complete, it would clear these hidden suspension flags from all 10 directions so construction can continue.

This 'should' create a build system that is low weight cpu wise, that would stop dwarfs from building constructions like a gnat with no concept of future planning

[Draco18s]

2. Prioritization based on accessibility after the fact, meaning. when a dwarf goes to build a, lets say wall. It does a check, is there any constructions that will be 100% blocked if a build this tile? If yes, build the would be blocked tile (and redo the check) You could also do a hidden suspension system whereby a dwarf that cant build what he wants, but has to wait for another dwarf to finish a 'would be blocked' tile can go about his business. On construction complete, it would clear these hidden suspension flags from all 10 directions so construction can continue.

This would be, except....not.

1) It doesn't solve the "builder entraps himself" problem
2) Breaks the known workaround of a suspended building where you DO NOT want the builder standing ("Gee, this construction I am doing will block that suspended one over there.  I guess I won't build this!"
3) How do you check "will this block another construction?"  It leads back to the "pathing to [meeting area|booze|bed|food]" problem.

[Bohandas]

It strikes me that just telling a dwarf which side to stand on would be simpler than making sure to forbid all stone on the wrong side.

And have to specify for each and every wall or floor we build?  (Adding a minimum 2 keystrokes)

No thanks.  I'd much rather have them semi-intelligently figure it out for themselves (and make the occasional mistake).

Factoring game lag into account, the extra two keystrokes might be faster.

(That said, I think that both ideas sound potentially good)

[Draco18s]

Factoring game lag into account, the extra two keystrokes might be faster.

(That said, I think that both ideas sound potentially good)

Really.  Two keystrokes.  Faster decrement.

You must have very fast fingers.

Or a very slow computer.

Because I already proposed a solution that makes the system 85% better than it is now, and is 100% lag free.

The absolutely only way to do this is to path to the X,Y,Z cooridinates of the wall itself and stop 1 tile short.

Additionally, you could put in a check that if the dwarf walks over his built site before picking up the rock, he builds from the tile he was standing on just prior to standing on the build site (which is just a sidestep tacked onto the end of his movement).  Although personally I think this would actually cause more issues than it'd solve (dwarf starts on the side you want sealed: no matter where he gets a rock, he'll end up in the wrong place, whereas without this check, you can forbid stones on the far side (the sealed side) in order to prevent accidentally (and unknowingly) picking a "bad" stone).

[Jibekn]

This would be, except....not.

1) It doesn't solve the "builder entraps himself" problem
2) Breaks the known workaround of a suspended building where you DO NOT want the builder standing ("Gee, this construction I am doing will block that suspended one over there.  I guess I won't build this!"
3) How do you check "will this block another construction?"  It leads back to the "pathing to [meeting area|booze|bed|food]" problem.

1, correct, it wouldn't solve that, building direction would.

2, I was unaware of this workaround, however I wouldn't say it would break that, I dont see why it would. While I did use the term 'suspended' it was inaccurate in the context of the existing 'Suspended' construction system, it would be a new label on the construction, lets call it "Pending" which would be completely disassociated from the existing suspended system, this "Pending system" is a way for the engine to determine the order that a grouping of constructions should be built.

Picture time! as even my crude horrible drawings are better than I can explain.
w = unbuilt wall
W = Built wall
p = Pending wall
e = exempt construction(player would never see this, as the whole chain would be calced in a step)

Here we can see, a U shaped section of wall, and we want to fill it in. We designate 3 more walls.

Code: [Select]

WWWW
Wwww
WWWW

We will task the rightmost tile first, but the steps work for any scenario i can think of. It goes through the following check;

Do i have free* spots in all 4 compass directions?
Yes, task the build.
No, Goto next step.

Are all of the tiles that are 'blocking' me a pending flagged construction?
Yes, task the build
No, goto next step

Are any of the tiles that are 'blocking' me a unpending Construction awaiting tasking?
Yes, flag current tile as exempt, run check the unpending tile, then recheck the parent tile.
No, next step

Are the only tiles blocking me exemption tiles?
Yes, set all exemptions in the chain to pending and break (we've exempted ourselves into a corner)
No, set to pending

Now lets walk through the check in our current situation. The first point, is of course a No, we have an unpending, unsuspended construction blocking us.

The second part, no again.

Third part, is yes, we are in fact blocked by an unbuilt construction, so we now run a check on that tile, but before that we flag the tile we were checking as exempt.

Code: [Select]

WWWW
Weww
WWWW

First part of the check, nope, no free spot.

Second part, yup, 2, but one has been flagged as exempt from further checks in this nest, but the other isnt, so we can check that one! Flag current as exempt, and onward!

Code: [Select]

WWWW
Weew
WWWW

First check, here we have 3 'free' spots, 2 existing constructions, and an empty space, but alas, the exempt tile makes this check a no, next step.

We're only blocked by an exempt tile, so this is a no as well. Next step.

Ah! our first no on step 3, we move to the final check, which sets ourselves as pending.

Code: [Select]

WWWW
Weep
WWWW

Back to the middle tile, unflag as exempt, and recheck.

1st step: nope.
2nd step. nope
3rd step, nope, pending assigned.

Code: [Select]

WWWW
Wepp
WWWW

Regress, unflag exempt and recheck.

1st step, nope.
2nd step, yes! task the build.

Code: [Select]

WWWW
WWpp
WWWW

But of course, when the construction completed, we clear pending flags in 4 directions

Code: [Select]

WWWW
WWwp
WWWW

that tile is now up for task, it clears the check and is built. clearing the pending tag on the 3rd section.

Code: [Select]

WWWW
WWWw
WWWW

*a free tile is a tile that is in no danger if blocked in, such a an existing construction, or wall etc.

3, Programatically, pretty easy, however my examples dont account for some nuances like multi tiled constructions, but thats fairly easily worked around.

[Draco18s]

This would be, except....not.

1) It doesn't solve the "builder entraps himself" problem
2) Breaks the known workaround of a suspended building where you DO NOT want the builder standing ("Gee, this construction I am doing will block that suspended one over there.  I guess I won't build this!"
3) How do you check "will this block another construction?"  It leads back to the "pathing to [meeting area|booze|bed|food]" problem.

1, correct, it wouldn't solve that, building direction would.

2, I was unaware of this workaround, however I wouldn't say it would break that, I dont see why it would. While I did use the term 'suspended' it was inaccurate in the context of the existing 'Suspended' construction system, it would be a new label on the construction, lets call it "Pending" which would be completely disassociated from the existing suspended system, this "Pending system" is a way for the engine to determine the order that a grouping of constructions should be built.

1) I was under the impression this was an "either / or" situation, not a "both."

2) Your use of the term wasn't what I objected to, but rather that the builder goes to build his wall, finds a neighboring construction that would be blocked if he built his wall, and as that task is suspended, but requires completion first, he would cancel his own task.

Also, I can't read your pseudocode, although I get it conceptually.  Here's the problem:

Two unbuilt walls:


<-- To Caverns
###################
........ww.........
###################
        To Fort -->


Is one of them blocking the other?

Flood Fill is a remarkably expensive algorithm, as are any pathfinding algorithms.

[Jibekn]

1) I was under the impression this was an "either / or" situation, not a "both."

2) Your use of the term wasn't what I objected to, but rather that the builder goes to build his wall, finds a neighboring construction that would be blocked if he built his wall, and as that task is suspended, but requires completion first, he would cancel his own task.

Also, I can't read your pseudocode, although I get it conceptually.  Here's the problem:

Two unbuilt walls:


<-- To Caverns
###################
........ww.........
###################
        To Fort -->


Is one of them blocking the other?

Flood Fill is a remarkably expensive algorithm, as are any pathfinding algorithms.

1. Nope, both compliment each other nicely I think.

2. Suspension would override the pending, suspension is something the player can toggle, its a way of you saying dont build this at all, until i tell you to. For the purposes of the pending algorithm, suspension is completely ignored, a suspended building, is treated just like any other pending construction, it just of course wont be built until you unsuspend it. In your example, the builder would not even have approached the wall to try and build it. Because the suspended wall is the 'first step' it needs to be built for, and will be. However, because its been suspended, it will hold up the entire chain of building. Picture all the checks I laid out, happen before any dwarf is assigned the build task, he wouldnt have canceled his own task because of the suspended building, he never would have been given the task in the first place.

Example:

W = Built Wall
S = Suspended Wall
w = construction designation
p = pending flagged construction

Code: [Select]

WWWW
WSww
WWWW

Here we see the same U shaped pocket, only we have suspended the inner most tile.

After the algorithm runs, we have something looking like this:

Code: [Select]

WWWW
WSpp
WWWW

So, we have 2 pending constructions that will NOT be tasked out to a dwarf to build, until the suspended construction is done. But that suspended construction will not be tasked either until we unsuspend it. This means that the above example, will not be built, and no dwarf will even try and build it, until we unsuspend the inner most tile.

Your second example (the one with the drawing) is a great example of a decision the player will have to make, the algorithm wouldn't effect it at all, but would be a perfect example of directional building.

<-- To Caverns
###################
........w->..........
###################
        To Fort -->

build one wall, with the direction ->

And i would go as far as to say, that when building directional assigned walls beside each other, they auto-assign pending tags properly.

So, if we built your original 2 walls, with build direction east, we would be left with:

<-- To Caverns
###################
........wp...........
###################
        To Fort -->

This ensures that the first wall gets built first, not trapping a dwarf in the caverns, and then the second wall is built.

EDIT: I just noticed that the pathing thing wasn't part of your sig, Im not really sure how expensive this algorithm would be, but i dont think it would be anywhere near as pricey as pathfinding or floodfill, as we are running the algorithm just before a build task gets assigned a dwarf, its not searching any tiles past designated constructions, and would only fire once per step, as once the initial examination of a building cluster is done, everything is pending flagged properly and there's no need to run the algorithm again and again, like what needs to happen for every creature finding a path, or every piece of liquid finding its resting place.

[Draco18s]

1. Nope, both compliment each other nicely I think.

I refuse to accept any system that manually asks which direction a wall should be built from.  It does for bridges, for good reason (it has a mechanical impact).  But it shouldn't ask for walls.  Especially for every wall and requires more than 0 additional keypresses to build walls as they are currently (i.e. directionless).

EDIT: I just noticed that the pathing thing wasn't part of your sig, Im not really sure how expensive this algorithm would be, but i dont think it would be anywhere near as pricey as pathfinding or floodfill, as we are running the algorithm just before a build task gets assigned a dwarf, its not searching any tiles past designated constructions, and would only fire once per step, as once the initial examination of a building cluster is done, everything is pending flagged properly and there's no need to run the algorithm again and again, like what needs to happen for every creature finding a path, or every piece of liquid finding its resting place.

The point of that quote is to point out that the game needs to figure out "does this count as blocked?" and that such a question is not trivial to answer.  The wall, could in fact, be built from both directions, just the one is significantly more out-of-the-way than the other (so maybe it should be built first, but it's not critical that that be the case, unlike a wall that can never be built if it's in an alcove).

And because we cannot (easily) know if a wall will block another construction, it shouldn't be factored in.  At least, not in completion.  We can check for "interior walls" (ie. walls surrouned by only walls and open space) and always build outward from that (it's a very small search space), but what we cannot do, is check to see if a wall could never be built if it is adjacent to at least one floor tile simply because there is not enough information within a reasonably easy reach in order to infer entrapment.

[Jibekn]

I refuse to accept any system that manually asks which direction a wall should be built from.  It does for bridges, for good reason (it has a mechanical impact).  But it shouldn't ask for walls.  Especially for every wall and requires more than 0 additional keypresses to build walls as they are currently (i.e. directionless).

Its an option, just like a bridge, if you don't care what direction, you don't select anything, and its built just like it is now, directional building only adds the option, not the requirement, it only adds a keypress when you need them.

The point of that quote is to point out that the game needs to figure out "does this count as blocked?" and that such a question is not trivial to answer.  The wall, could in fact, be built from both directions, just the one is significantly more out-of-the-way than the other (so maybe it should be built first, but it's not critical that that be the case, unlike a wall that can never be built if it's in an alcove).

And because we cannot (easily) know if a wall will block another construction, it shouldn't be factored in.  At least, not in completion.  We can check for "interior walls" (ie. walls surrouned by only walls and open space) and always build outward from that (it's a very small search space), but what we cannot do, is check to see if a wall could never be built if it is adjacent to at least one floor tile simply because there is not enough information within a reasonably easy reach in order to infer entrapment.

Hmm, I think we're trying to solve different problems with our suggestions. I want a system, where if i designate walls, they all get built. Thats it. I dontt want the system to try and figure out which side of the building cluster it should start from(from a my base is on this side point of view). That is trivially solved by designating build direction. Im sorry you dont see that as a valid solution, I see it as the perfect solution, as its light weight, calls no flood fill algorithms, and puts a conscious decision in the hands of the player. So on that topic we will have to agree to disagree. Which of course means that the rest of my suggestion as a stand alone of wouldn't appeal to you, which is reasonable. But I do stand by my suggestion as a solution to problems with builders canceling jobs, and getting themselves stuck, and about as lightweight as its going to get.

[Draco18s]

I refuse to accept any system that manually asks which direction a wall should be built from.  It does for bridges, for good reason (it has a mechanical impact).  But it shouldn't ask for walls.  Especially for every wall and requires more than 0 additional keypresses to build walls as they are currently (i.e. directionless).

Its an option, just like a bridge, if you don't care what direction, you don't select anything, and its built just like it is now, directional building only adds the option, not the requirement, it only adds a keypress when you need them.

Except that it still adds 1 keypress ("Yes, do that, [ENTER]").

I dontt want the system to try and figure out which side of the building cluster it should start from(from a my base is on this side point of view).

This is a Straw Man.  This issue has not come up previously.

as its light weight, calls no flood fill algorithms, and puts a conscious decision in the hands of the player.

Actually, your suggestion is none of these things.  You keep presenting your system in a closed environment and going "see, see?  it works!" and it does, but only in a narrowly defined set of circumstances (constructed walls only being blocked by other constructed walls, and only if you specified a build direction!)

The only reason to ever put something into the hands of the player (especially for something like this) is only if they request it.  I have nothing against being able to view a designated wall and telling it a build direction, what I am against is the game asking (on EVERY designated wall*) what direction to build from.  "Do you want to specify?  No.  Do you want to specify?  No.  Do you want to specify?  No."

So on that topic we will have to agree to disagree. Which of course means that the rest of my suggestion as a stand alone of wouldn't appeal to you, which is reasonable. But I do stand by my suggestion as a solution to problems with builders canceling jobs, and getting themselves stuck, and about as lightweight as its going to get.

You haven't actually built a system that's lighter weight than mine, actually.  Mine doesn't require 2 additional bits of map data per construction.  Or a lengthy (relatively speaking) loopthrough check-recheck algorithm.

Here's mine:

Dwarf.pathToDestination.length--;

*How do you handle the case where a planer designates a 10x10 block of walls?  Individually loop through each one and ask the player "What direction for THIS wall?" or do you take one direction for the whole group?

[Qmarx]

I think the ability to designate a (forbid labor) area would work just as well.

[Jibekn]

Except that it still adds 1 keypress ("Yes, do that, [ENTER]").

you are misunderstanding me, it would work EXACTALY like a bridge, do you have to designate a side if you just want a retracting bridge? nope, its the default.

Would you have to press a key to set a wall as "no build direction"? nope, its the default, it would literally add no extra keypresses unless you wanted to specify a direction.

This is a Straw Man.  This issue has not come up previously.

Im misunderstanding your point then, as i thought that is what you were getting at.

Actually, your suggestion is none of these things.  You keep presenting your system in a closed environment and going "see, see?  it works!" and it does, but only in a narrowly defined set of circumstances (constructed walls only being blocked by other constructed walls, and only if you specified a build direction!)

The only reason to ever put something into the hands of the player (especially for something like this) is only if they request it.  I have nothing against being able to view a designated wall and telling it a build direction, what I am against is the game asking (on EVERY designated wall*) what direction to build from.  "Do you want to specify?  No.  Do you want to specify?  No.  Do you want to specify?  No."

Please give me an example that breaks my system. And yes, build direction gets included in it, as that is part of my system.

As to the 'no' spam, ive addressed that, and im not touching your comment on giving a player a decision as that's a subjective topic, I dont like playing games that play themselves, but at the same time, I dont like tedious micromanagement, like when i tried to build a 60x60 labyrinth in an empty field.. that was.. trying on my patience.

You haven't actually built a system that's lighter weight than mine, actually.  Mine doesn't require 2 additional bits of map data per construction.  Or a lengthy (relatively speaking) loopthrough check-recheck algorithm.

Here's mine:

Dwarf.pathToDestination.length--;

*How do you handle the case where a planer designates a 10x10 block of walls?  Individually loop through each one and ask the player "What direction for THIS wall?" or do you take one direction for the whole group?

b C w uuuuuuuuu kkkkkkkkk d enter

Build
Construction
Wall
create the 10x10 block
select direction
place

So yes, one direction for the whole group.

Pathing is way more expensive than a limited flood fill, very limited at that to the point is barely a fill, as its only 'filling' tiles that you designated as construction. I really think your mistaken if you believe that ANY pathing algorithm is lighter than a pseudo flood fill that only scans through designated constructions. Either that, or i havent relayed my idea correctly.

While yes, you can visually display your system in a line, explain the function behind that line and you;ll quickly grasp how expensive a calc pathing is.

but I will admit that yes, this is another bit that needs to be stored in every designated construction tile (the 'exempt' bit would be local to the function and wouldn't require any persistence)

EDIT: This is my last post today, as my work day is over, however I will pickup this thread again on Monday, or if you want to discuss this on IM's before that, feel free to PM me.

[Starver]

There's a lot of useful discussion in here, but to address something in the OP that I haven't seen being mentioned (apols if it has)...

The game might well be able to look at a construction effort and automatically determine that building from one particular side would seal the dwarf in[1], but why should it then assume that this is undesired?

Imagine you've got an infestation of... clowns, jugglers and trapeze artists, let's say...  Perhaps then you deliberately wish to seal the wall-builder away for the duration.  And there are other, possibly less rare, circumstances where you'd want to do likewise, including impending flood-style doom (hot or plain wet varieties) that you know you can drain away, but not before it would normally swamp and drown your hapless wall-builder-in-potentia if they did not act upon said potential and hide in an alcove.

Yes, the current workarounds used to ensure non-trapping (where there's a danger that it could happen) could also be used to ensure deliberate-trapping (where the program would otherwise ensure it did not), but it's all complexity.  And you ought to see the hoops I routinely go through to pre-define heterogenous mass of floors, walls, stairs and fortifications, so as to avoid the need for micromanagement during the construction (at the expense of some convoluted construction definitions at the start), and arranging to guarantee directionality of construction isn't anywhere as convoluted as that, so I say there's no need.


(What I would like, and have mentioned before, is that path-generating changes (digging out solid rock, perhaps joining two tunnel systems, or placing the final floor/bridge across a gap that can be accessed from both sides) do not similarly have the current work-direction preference where more than one alternative (with drastically differing pathfinding solutions to each), but instead treat the work-tile as a temporarily-possible destination.  Just like you'd path the short way down the short tunnel to harvest some itinerant cave-plant, rather than wander all the way around the mountain and into the longer tunnel, actually mining out the square (or cutting down the tree) on that tile does not go "I want to stand... to the west... right, path there", but instead temporarily adds the destination tile to the stack of walkable tiles and uses that as the destination and, according to what the pathfinding algorithm comes up with as the best path, it takes the penultimate tile in the eventual route as the "go to and work from" point.  With perhaps a little modification to deal with "must work orthogonally, not diagonally" jobs, where that matters, of course.  But this has very little to do with the OP, saving that it would make more intelligent "unblocking" job fulfillment, the direct counterpart to the wish to have more intelligent path-blocking jobs.)



[1] Trivially or non-trivially, depending on the complexity of the... complex.  But even if it only extends to a single-level concave area, and gives up on anything more complex, the above still applied.