0005991: Dwarf tries to build wall standing on the construction site

(0022872)
Footkerchief (manager)
2012-06-06 08:57

Reminder sent to: Lazygun

Although your diagram looks clear, it might still help to upload a save to http://dffd.wimbli.com/ [^] and post the link here.

(0022873)
Lazygun (reporter)
2012-06-06 10:49

I've one that at http://dffd.wimbli.com/file.php?id=6436 [^]

It looks like this is a sometimes repeatable problem

(0022875)
AVK (reporter)
2012-06-06 11:33

Did you use an old save? Somebody I know did, and he's got the exact same issue.

(0022876)
Lazygun (reporter)
2012-06-06 12:42

That's a good point. I started this fort in 0.34.10

(0022880)
UristMcMouse (reporter)
2012-06-06 17:35
edited on: 2012-06-06 17:39

I have run into this issue in my current fort, which was started from scratch on 34.11. To fix, I had to cancel the wall being built and build it again in the exact same place. The dwarf would cancel the build because of creature occupying site. I had already fixed the issue, but if it happens again, I will upload a save. Diagram below:

+++++++++
+#######+
+#+++++#+
+#+++++#+
+#++D++#+
+#+++++#+
+X+++++X+
+#######+
+++++++++

# = Wall built already
+ = Accessible soil floor
D = Down stairs (to accessible fort)
X = Walls that would not complete

Edited to pretty my diagram.

(0022881)
guebstrike (reporter)
2012-06-06 21:04
edited on: 2012-06-07 09:53

I've experienced the same problem with this brand new fort, trying to build a wall in a dug out staircase. This is a new world built in 34.11. Check the bottom of the stairs right next to the embark point. I immediately hit a cavern so I tried to build a wall. It doesn't matter if I delete it and try again; the builder just stands on top of the site, then cancels.
http://dffd.wimbli.com/file.php?id=6440 [^]

This build and save uses the LazyDorf repack uploaded June 5th, and the Mayday graphics set.

Update: I noticed a stone was sitting on the construction site so I dumped it. After than the dwarves were able to properly complete the wall.

(0022882)
mazterlith (reporter)
2012-06-06 23:26

I just got the same thing. Tried destructing all the buildings around it and it still wouldn't work.

(0022894)
krenshala (reporter)
2012-06-07 11:45

I'm attempting to build some walls in a murky pool (after draining) so wagons can get to my depot. http://koboldi.net/dwarffortress/mason-fail.png [^] is a screenshot of the two tiles I am experiencing this on.

The woodworker is removing an existing wall, as I'm hoping that will allow me to build the bottom right one (on the ramp). Deconstructing the wall directly south of the woodworker allowed me to build the wall SW of the woodworker, when the mason would stand in the square otherwise.

This is a new 34.11 world (Phoebus 34.11v00 for linux).

(0022925)
suicidejunkie (reporter)
2012-06-08 16:06

I have a save with a similar situation.
http://imagemodserver.dyndns.org/nick/tempstuff/region1c.zip [^]

I'm trying to build a 2 story tall room on the surface, and built a bridge for cheap access to the upper wall tiles.
The mason walks along the bridge, then moves diagonally from the bridge to the wall construction. Then cancels because he is in his own way.

My thought was that he was doing it because during his trip to the construction site, he never actually stepped on a legal tile to build from.
Building a second bridge and applying traffic designations proved that false; he walked through the legitimate tile, and then tried to build on top of himself again.

Cancelling the construction and redesignating it worked however.

(0022927)
slink (reporter)
2012-06-08 17:24
edited on: 2012-06-08 17:25

Same thing here, in a new 34.11 world. The two ends of a 9-tile rock block wall could not be built. Cancelling the almost completed construction and redesignating corrected the condition. I guess I don't need to upload a save. Plenty of saves available above.

(0022928)
suicidejunkie (reporter)
2012-06-08 18:13
edited on: 2012-06-09 09:01

Got a better save than above:
http://imagemodserver.dyndns.org/nick/tempstuff/region1c2.zip [^]
edit: zip was corrupted. recreated & uploaded again.

In this case, I'm trying to extend the wall between the trap entrance and the wagon entrance on the south wall of the fort. (1 z-level above the surface)

The mason's preferred path to the construction site involves going up a ramp which places him directly on the tile to be walled.
He tries to build while on the tile, rather than walking an extra space (to somewhere he's never actually been) and building successfully.

+O
vO
.X
.+

Where
+ = floor
v = ramp on z-level below
O = Previously built walls
X = construction site

I tried a some tests:
1) Cancelling and redesignating did not fix it - dwarves preferred to approach from the ramp, and never set foot on the floor access.
2) Designating the bridge and ramp as restricted did not fix it. Dwarves would approach from the floor access and then try to use the original mason's illegal build location.
3) Restricting the ramp AND cancel/redesignate does work. This time the first builder approaches from the floor and builds successfully.
4) Once the first mason has decided to build from the floor side, the task can be suspended and the restrictions lifted. The replacement mason will approach from the ramp, but then walk to the floor tile the first mason was working from.

(0022933)
Chaia (reporter)
2012-06-09 06:37
edited on: 2012-06-09 06:41

Same for me in 34.11

Happend on following Construction:

WWW+
WWW+
^^^+
++++

W = Natural Wall
^ = N. Ramp
+ = N. Floor

Ordered following:

WWW+
WWW+
^^c+
++C+

C = Constructed Wall
c = Ordered Wall with a ramp on this tile
(which gives the bug mentioned in this thread)

Added Save:
http://dffd.wimbli.com/file.php?id=6461 [^]

Edit:

Removing ramp and reordering (delete and new construction) solved the problem

(0022975)
castellan (reporter)
2012-06-12 20:19

Same here with a fresh world generated in 34.11 on the Mac. Makes the current version unplayable for my needs. No amount of canceling/un-suspending works. I can force the issue by channeling out the area I want a wall in, but that makes for other problems.

(0022980)
Maple47 (reporter)
2012-06-13 11:43

Same problem. Standard 34.11, first and only fortress so far. Downloaded and installed recently on Windows.

Simple tower. Several free tiles for the mason to stand on, but he repeatedly chooses to stand on the tile he is constructing a wall on (even if cancelled and replaced with a new build order). This causes:

<Name> cancels Construct Building: Creature occupying site.

Like Castellan, I feel that this makes the current version pretty much unplayble, since construction is critically important. Trying to work around the bug is just an exercize in pain and frustration.

(0023031)
Kobold6 (reporter)
2012-06-16 18:32

This bug appears to also apply to deconstructing floors.

Dwarfs will try to deconstruct from the same tile and fall into the dangers below.

(0023122)
ZzarkLinux (reporter)
2012-06-28 15:06

I experienced the "stand on wall" bug in my first 34.11 game. Cancel-And-Redesignate did not help in that case.

I was able to get this save: http://dffd.wimbli.com/file.php?id=6592 [^]
It shows a similar issue. Even though Urist and the-blocks are on the "left" side of map, the Urist paths to the "top-right" corner to build several walls. For some walls, Urist even walks over empty grass, and goes farther just to build the wall.

Hope this helps

(0023129)
eliotcougar (reporter)
2012-06-30 10:14

This bug made my current game very hard... I channeled out a long straight cliff and was going to build a wall on the edge of it:
Look from the side (.air ^ramp f-natural ground C-wall construction order)
...
ff^.

I ordered construction of walls along the edge
.C.
ff^.

And at the same time designated removal of the ramps
.C
ff..

Then I've got this (top-down view):
....................
WsssWWWsWsWssssssssW

where W - successfully built wall, s - suspended construction due to "creature occupying site"... Either resuming or cancelling-rebuilding does not help, worker stands on the same tile he builds the wall on... Dwarf behavior looks completely random to me (I know they are insane, but anyway)...

(0023138)
lorb (reporter)
2012-07-02 04:06

Same here. Unsuspending the construction never helps. Cancelling and rebuilding sometimes help.

(0023179)
krenshala (reporter)
2012-07-07 12:13

I have actually been having pretty good luck with canceling the job, waiting for the surrounding constructions to be completed, removing any ramps in the tile, and redesignating the wall. It still fails every now and then, but this almost always works.

I wonder if this is emergent behavior from the worker not wanting to stand in a tile designated for another construction, combined with the new construction code that allows them to build diagonally?

(0023183)
toybasher (reporter)
2012-07-08 12:48

I have the same problem, I was trying to do the bucket method of making a farm (Carve out a room below, and have it designated as a pond zone) but I didnt take something into consideration and wound up with a room too big for the buckets to fill.

When I tried to fill up the excess gap using walls, I had dwarves end up standing on the spot where they tried to build, causing the "Creature Occupying Site" error. Luckily I solved it by canceling the wall and rebuilding it.

(0023266)
Pufferfish (reporter)
2012-07-18 17:32

So far what I've noticed, is that this happens mostly when there's a down ramp in the surrounding eight tiles - It's what I've noticed on my maps and after I deconstruct/remove the ramp, the building continues along just fine. I'll do a little testing to see if there's anything else that causes the problem.

(0023274)
kwieland (reporter)
2012-07-19 12:50

My case was also with a down ramp.

(0023302)
Pufferfish (reporter)
2012-07-21 02:45

I think this bug is related to down ramps - most if not all cases here seem to be building them with one nearby. I'll see if it's because they decide to go up the ramp to start the job or if it's just the placement of the ramp in the area that makes it happen. I'm almost positive it's the first case.

(0023326)
Pufferfish (reporter)
2012-07-22 23:26
edited on: 2012-07-23 01:31

Yeah, I've got a workaround figured out. Designate the up/down ramp as a restricted area and make a high traffic road as a detour around the down ramp, so he builds from a different direction.

It's caused by the dwarf going up the down ramp to build the wall, but since he can't occupy the space where the ramp is, he ends up where the wall is to be constructed, so far as I see.

(0023332)
Telarin (reporter)
2012-07-23 10:39

The instances where I have had this issue occur had no up/down ramps anywhere near the construction area.

(0023358)
Pufferfish (reporter)
2012-07-25 18:11

Hmm. See if they come in on a diagonal. I've seen a few dwarves building that way so that may be the issue as well, because from what I got from the wiki, they have to be directly adjacent to the wall. That doesn't seem to be the case anymore as I've seen them build like that.

(0023472)
vadia (reporter)
2012-08-17 12:59
edited on: 2012-08-17 13:00

Not neccisarily down ramp related. I had the same problem; clear space, dorf works building wall -- silly statement
unsuspend -- dorf ignores
tried a second place also not near a ramp.

It was annoying because it let a blind ogre ruin my whole camp.

btw in 34.11

(0023516)
DDR (reporter)
2012-09-01 12:00

I've had the same problem, but I've also had a minor case crop up when just building a normal, straight wall on normal, flat ground. The dwarf will stand on the tile she's trying to build on until I remove the wall construction site and build it again. :(

(0023525)
nshapter (reporter)
2012-09-04 10:00

I saw this over the weekend with a 2 wide hall, building a wall...

key#

W = natural wall
w = Proposed construction
+ = floor
A = Carved fortification

hallway was

W++A
W++A
W++A
W++A
W++A
W++A
W++A

ordered building

Ww+A
Ww+A
Ww+A
Ww+A
Ww+A
Ww+A
Ww+A

got built

Ww+A
Ww+A
Ww+A
Ww+A
W++A
Ww+A
Ww+A

that last square, they just can't build it!

(0023646)
Aescula (reporter)
2012-10-09 19:19

Some tests after reading this log:
Had a wall that stubbornly refused to be built a la this bug.
It was adjascent to a ramp, like so: +=const. floor, v=DRamp, .=grass, O=wall, *=wall in question, =open space
+++...
vvvO..
   *..
   ...
This never ever worked. So I built around it to this:
+++...
vv OO.
   *..
   OO.
Canceled and retried. It worked.
Seems to be about arriving on a diagonal, yeah.

(0023647)
Aescula (reporter)
2012-10-09 19:20

PS: copy to Notepad or something Monospace to see my diagrams right >.<

(0023823)
MrC (reporter)
2013-01-07 05:26
edited on: 2013-01-07 05:27

I can confirm this bug I have managed to work around but I'm not exactly sure how to do it.

Sometimes its as simple as cancelling the construction and starting it again
sometimes i have to deconstruct it and move it.

Looks like a bug in the part of the code that stops the dwarf from walling themselves in. Because It has never happened until that feature was added.

(0023834)
lethosor (manager)
2013-01-19 11:00

It looks like channeling the square where the wall will be built works (obviously since the dwarves are forced to stand somewhere else). It's harder when building above ground level, because then you might have to remove a construction.

(0023887)
krenshala (reporter)
2013-03-06 15:40

Changing the construction order works as well, probably because this gives the dwarf a different option on where to stand.

Now that I think about it, when I cancel the construction and the building materials appear, they almost always appear in the NW tile (upper left) of those adjacent to the construction site. I'm thinking this is a useful bit of information in troubleshooting the problem.

(0023894)
ag (reporter)
2013-03-07 01:54

This problem happens if the dwarf doing the job, while in the phase of bringing the build item to the tile, reaches the tile via a path that doesn't cross any of the tiles that can be used to actually build the construction. As a result, the tile to work from is not set and remains equal to the position of the construction.

(0024009)
krenshala (reporter)
2013-06-16 22:30

If you are right, ag, then the diagonal positions that dwarves build from are not always considered "valid" sites to build from.

On top of a 1 tile wide east-west wall I build flooring off the south side for a walkway, then designated more wall tiles on top:

+O==X======O+
+++++++++++++

The X above is the wall tile that the masons continually stood on instead of next to when building. The wall was constructed from right to left, and every other tile worked just fine, with the dwarf standing SW of the wall tile constructed.

(0024636)
ag (reporter)
2014-03-25 23:46

I actually recently found the code that may be responsible by chance. What it seems to be doing is that when the worker first appears in the 3x3 square surrounding the construction, it changes the job location to the current position of the worker, and sets a flag in the job. If the unit somehow manages to appear directly in the center location via a ramp or otherwise, it still fires and permanently locks the wrong location. Clearing the flag using lua fixes it, because the next worker to do the job can rerun the code.

(0025707)
eliotcougar (reporter)
2014-07-11 00:59

It is sad to see that this bug is still present in 0.40... It's so annoying...

(0025754)
Rafal99 (reporter)
2014-07-11 08:07
edited on: 2014-07-11 08:09

Hopefully Toady will get to it soon.
It is one of the two annoying bugs that were introduced in 0.34.11, the last bugfix release before the two years of 40.01 development, so unfortunately they had to stay all that time.
The other one being 0005994.

Issue History
Date Modified	Username	Field	Change
2012-06-06 08:48	Lazygun	New Issue
2012-06-06 08:57	Footkerchief	Note Added: 0022872
2012-06-06 10:49	Lazygun	Note Added: 0022873
2012-06-06 11:33	AVK	Note Added: 0022875
2012-06-06 12:42	Lazygun	Note Added: 0022876
2012-06-06 17:35	UristMcMouse	Note Added: 0022880
2012-06-06 17:36	UristMcMouse	Note Edited: 0022880	View Revisions
2012-06-06 17:37	UristMcMouse	Note Edited: 0022880	View Revisions
2012-06-06 17:38	UristMcMouse	Note Edited: 0022880	View Revisions
2012-06-06 17:39	UristMcMouse	Note Edited: 0022880	View Revisions
2012-06-06 21:04	guebstrike	Note Added: 0022881
2012-06-06 21:09	guebstrike	Note Edited: 0022881	View Revisions
2012-06-06 21:15	Khym Chanur	Issue Monitored: Khym Chanur
2012-06-06 23:26	mazterlith	Note Added: 0022882
2012-06-07 09:43	guebstrike	Note Edited: 0022881	View Revisions
2012-06-07 09:53	guebstrike	Note Edited: 0022881	View Revisions
2012-06-07 11:45	krenshala	Note Added: 0022894
2012-06-07 11:45	krenshala	Issue Monitored: krenshala
2012-06-07 12:06	Rafal99	Issue Monitored: Rafal99
2012-06-08 16:06	suicidejunkie	Note Added: 0022925
2012-06-08 17:24	slink	Note Added: 0022927
2012-06-08 17:25	slink	Note Edited: 0022927	View Revisions
2012-06-08 18:13	suicidejunkie	Note Added: 0022928
2012-06-08 20:08	suicidejunkie	Issue Monitored: suicidejunkie
2012-06-09 06:37	Chaia	Note Added: 0022933
2012-06-09 06:38	Chaia	Note Edited: 0022933	View Revisions
2012-06-09 06:39	Chaia	Note Edited: 0022933	View Revisions
2012-06-09 06:40	Chaia	Note Edited: 0022933	View Revisions
2012-06-09 06:41	Chaia	Note Edited: 0022933	View Revisions
2012-06-09 09:01	suicidejunkie	Note Edited: 0022928	View Revisions
2012-06-11 18:39	Footkerchief	Relationship added	has duplicate 0006009
2012-06-12 20:19	castellan	Note Added: 0022975
2012-06-13 11:43	Maple47	Note Added: 0022980
2012-06-16 18:32	Kobold6	Note Added: 0023031
2012-06-19 09:43	Knight Otu	Relationship added	has duplicate 0006037
2012-06-19 09:43	Knight Otu	Issue Monitored: MrAnderson
2012-06-20 10:17	Snaake	Issue Monitored: Snaake
2012-06-27 12:07	Telarin	Issue Monitored: Telarin
2012-06-28 15:06	ZzarkLinux	Note Added: 0023122
2012-06-30 02:33	lorb	Issue Monitored: lorb
2012-06-30 10:14	eliotcougar	Note Added: 0023129
2012-07-02 04:06	lorb	Note Added: 0023138
2012-07-07 12:13	krenshala	Note Added: 0023179
2012-07-08 01:42	Knight Otu	Relationship added	has duplicate 0006077
2012-07-08 12:48	toybasher	Note Added: 0023183
2012-07-14 20:37	Pufferfish	Issue Monitored: Pufferfish
2012-07-17 03:12	Knight Otu	Relationship added	has duplicate 0006099
2012-07-17 06:55	oxinabox	Issue Monitored: oxinabox
2012-07-18 17:32	Pufferfish	Note Added: 0023266
2012-07-19 12:50	kwieland	Note Added: 0023274
2012-07-21 02:45	Pufferfish	Note Added: 0023302
2012-07-22 23:26	Pufferfish	Note Added: 0023326
2012-07-23 01:31	Pufferfish	Note Edited: 0023326	View Revisions
2012-07-23 06:55	SirusEasyE	Issue Monitored: SirusEasyE
2012-07-23 10:39	Telarin	Note Added: 0023332
2012-07-25 18:11	Pufferfish	Note Added: 0023358
2012-08-17 09:37	Knight Otu	Relationship added	has duplicate 0006169
2012-08-17 12:59	vadia	Note Added: 0023472
2012-08-17 13:00	vadia	Note Edited: 0023472	View Revisions
2012-09-01 12:00	DDR	Note Added: 0023516
2012-09-04 10:00	nshapter	Note Added: 0023525
2012-10-09 19:19	Aescula	Note Added: 0023646
2012-10-09 19:20	Aescula	Note Added: 0023647
2012-11-06 07:45	Footkerchief	Relationship added	related to 0005877
2013-01-07 05:26	MrC	Note Added: 0023823
2013-01-07 05:27	MrC	Note Edited: 0023823	View Revisions
2013-01-17 12:50	arclance	Issue Monitored: arclance
2013-01-19 11:00	lethosor	Note Added: 0023834
2013-03-06 15:40	krenshala	Note Added: 0023887
2013-03-07 01:54	ag	Note Added: 0023894
2013-03-14 01:20	HYBRID BEING	Issue Monitored: HYBRID BEING
2013-03-16 12:40	lethosor	Issue Monitored: lethosor
2013-06-16 22:30	krenshala	Note Added: 0024009
2013-06-20 14:59	madjoe5	Issue Monitored: madjoe5
2013-10-15 02:16	Knight Otu	Relationship added	has duplicate 0006381
2013-12-07 04:29	Thundercraft	Issue Monitored: Thundercraft
2014-01-27 21:14	Footkerchief	Relationship added	related to 0002119
2014-03-25 23:46	ag	Note Added: 0024636
2014-03-25 23:46	ag	Issue Monitored: ag
2014-03-26 01:44	Dwarfu	Assigned To	=> Dwarfu
2014-03-26 01:44	Dwarfu	Status	new => confirmed
2014-03-26 01:44	Dwarfu	Status	confirmed => acknowledged
2014-07-08 15:53	Dwarfu	Relationship added	has duplicate 0006725
2014-07-11 00:59	eliotcougar	Note Added: 0025707
2014-07-11 01:23	eliotcougar	Tag Attached: 0.40.02
2014-07-11 08:07	Rafal99	Note Added: 0025754
2014-07-11 08:09	Rafal99	Note Edited: 0025754	View Revisions
2014-07-11 08:09	Rafal99	Note Edited: 0025754	View Revisions
2014-07-15 22:03	Footkerchief	Relationship added	has duplicate 0007325
2014-07-18 13:15	Knight Otu	Relationship added	has duplicate 0007454
2014-07-25 12:41	Toady One	Status	acknowledged => resolved
2014-07-25 12:41	Toady One	Fixed in Version	=> Next Version
2014-07-25 12:41	Toady One	Resolution	open => fixed
2014-07-25 12:41	Toady One	Assigned To	Dwarfu => Toady One
2014-07-26 02:36	Rafal99	Issue End Monitor: Rafal99
2014-07-31 08:36	Footkerchief	Relationship added	related to 0007760
2014-08-11 18:11	krenshala	Issue End Monitor: krenshala
2015-06-02 04:38	Telarin	Issue End Monitor: Telarin
2015-10-07 15:31	Snaake	Issue End Monitor: Snaake
2016-05-26 22:00	Thundercraft	Issue End Monitor: Thundercraft

Notes
(0022872) Footkerchief (manager) 2012-06-06 08:57	Reminder sent to: Lazygun Although your diagram looks clear, it might still help to upload a save to http://dffd.wimbli.com/ [^] and post the link here.

(0022873) Lazygun (reporter) 2012-06-06 10:49	I've one that at http://dffd.wimbli.com/file.php?id=6436 [^] It looks like this is a sometimes repeatable problem

(0022875) AVK (reporter) 2012-06-06 11:33	Did you use an old save? Somebody I know did, and he's got the exact same issue.

(0022876) Lazygun (reporter) 2012-06-06 12:42	That's a good point. I started this fort in 0.34.10

(0022880) UristMcMouse (reporter) 2012-06-06 17:35 edited on: 2012-06-06 17:39	I have run into this issue in my current fort, which was started from scratch on 34.11. To fix, I had to cancel the wall being built and build it again in the exact same place. The dwarf would cancel the build because of creature occupying site. I had already fixed the issue, but if it happens again, I will upload a save. Diagram below: +++++++++ +#######+ +#+++++#+ +#+++++#+ +#++D++#+ +#+++++#+ +X+++++X+ +#######+ +++++++++ # = Wall built already + = Accessible soil floor D = Down stairs (to accessible fort) X = Walls that would not complete Edited to pretty my diagram.

(0022881) guebstrike (reporter) 2012-06-06 21:04 edited on: 2012-06-07 09:53	I've experienced the same problem with this brand new fort, trying to build a wall in a dug out staircase. This is a new world built in 34.11. Check the bottom of the stairs right next to the embark point. I immediately hit a cavern so I tried to build a wall. It doesn't matter if I delete it and try again; the builder just stands on top of the site, then cancels. http://dffd.wimbli.com/file.php?id=6440 [^] This build and save uses the LazyDorf repack uploaded June 5th, and the Mayday graphics set. Update: I noticed a stone was sitting on the construction site so I dumped it. After than the dwarves were able to properly complete the wall.

(0022882) mazterlith (reporter) 2012-06-06 23:26	I just got the same thing. Tried destructing all the buildings around it and it still wouldn't work.

(0022894) krenshala (reporter) 2012-06-07 11:45	I'm attempting to build some walls in a murky pool (after draining) so wagons can get to my depot. http://koboldi.net/dwarffortress/mason-fail.png [^] is a screenshot of the two tiles I am experiencing this on. The woodworker is removing an existing wall, as I'm hoping that will allow me to build the bottom right one (on the ramp). Deconstructing the wall directly south of the woodworker allowed me to build the wall SW of the woodworker, when the mason would stand in the square otherwise. This is a new 34.11 world (Phoebus 34.11v00 for linux).

(0022925) suicidejunkie (reporter) 2012-06-08 16:06	I have a save with a similar situation. http://imagemodserver.dyndns.org/nick/tempstuff/region1c.zip [^] I'm trying to build a 2 story tall room on the surface, and built a bridge for cheap access to the upper wall tiles. The mason walks along the bridge, then moves diagonally from the bridge to the wall construction. Then cancels because he is in his own way. My thought was that he was doing it because during his trip to the construction site, he never actually stepped on a legal tile to build from. Building a second bridge and applying traffic designations proved that false; he walked through the legitimate tile, and then tried to build on top of himself again. Cancelling the construction and redesignating it worked however.

(0022927) slink (reporter) 2012-06-08 17:24 edited on: 2012-06-08 17:25	Same thing here, in a new 34.11 world. The two ends of a 9-tile rock block wall could not be built. Cancelling the almost completed construction and redesignating corrected the condition. I guess I don't need to upload a save. Plenty of saves available above.

(0022928) suicidejunkie (reporter) 2012-06-08 18:13 edited on: 2012-06-09 09:01	Got a better save than above: http://imagemodserver.dyndns.org/nick/tempstuff/region1c2.zip [^] edit: zip was corrupted. recreated & uploaded again. In this case, I'm trying to extend the wall between the trap entrance and the wagon entrance on the south wall of the fort. (1 z-level above the surface) The mason's preferred path to the construction site involves going up a ramp which places him directly on the tile to be walled. He tries to build while on the tile, rather than walking an extra space (to somewhere he's never actually been) and building successfully. +O vO .X .+ Where + = floor v = ramp on z-level below O = Previously built walls X = construction site I tried a some tests: 1) Cancelling and redesignating did not fix it - dwarves preferred to approach from the ramp, and never set foot on the floor access. 2) Designating the bridge and ramp as restricted did not fix it. Dwarves would approach from the floor access and then try to use the original mason's illegal build location. 3) Restricting the ramp AND cancel/redesignate does work. This time the first builder approaches from the floor and builds successfully. 4) Once the first mason has decided to build from the floor side, the task can be suspended and the restrictions lifted. The replacement mason will approach from the ramp, but then walk to the floor tile the first mason was working from.

(0022933) Chaia (reporter) 2012-06-09 06:37 edited on: 2012-06-09 06:41	Same for me in 34.11 Happend on following Construction: WWW+ WWW+ ^^^+ ++++ W = Natural Wall ^ = N. Ramp + = N. Floor Ordered following: WWW+ WWW+ ^^c+ ++C+ C = Constructed Wall c = Ordered Wall with a ramp on this tile (which gives the bug mentioned in this thread) Added Save: http://dffd.wimbli.com/file.php?id=6461 [^] Edit: Removing ramp and reordering (delete and new construction) solved the problem

(0022975) castellan (reporter) 2012-06-12 20:19	Same here with a fresh world generated in 34.11 on the Mac. Makes the current version unplayable for my needs. No amount of canceling/un-suspending works. I can force the issue by channeling out the area I want a wall in, but that makes for other problems.

(0022980) Maple47 (reporter) 2012-06-13 11:43	Same problem. Standard 34.11, first and only fortress so far. Downloaded and installed recently on Windows. Simple tower. Several free tiles for the mason to stand on, but he repeatedly chooses to stand on the tile he is constructing a wall on (even if cancelled and replaced with a new build order). This causes: <Name> cancels Construct Building: Creature occupying site. Like Castellan, I feel that this makes the current version pretty much unplayble, since construction is critically important. Trying to work around the bug is just an exercize in pain and frustration.

(0023031) Kobold6 (reporter) 2012-06-16 18:32	This bug appears to also apply to deconstructing floors. Dwarfs will try to deconstruct from the same tile and fall into the dangers below.

(0023122) ZzarkLinux (reporter) 2012-06-28 15:06	I experienced the "stand on wall" bug in my first 34.11 game. Cancel-And-Redesignate did not help in that case. I was able to get this save: http://dffd.wimbli.com/file.php?id=6592 [^] It shows a similar issue. Even though Urist and the-blocks are on the "left" side of map, the Urist paths to the "top-right" corner to build several walls. For some walls, Urist even walks over empty grass, and goes farther just to build the wall. Hope this helps

(0023129) eliotcougar (reporter) 2012-06-30 10:14	This bug made my current game very hard... I channeled out a long straight cliff and was going to build a wall on the edge of it: Look from the side (.air ^ramp f-natural ground C-wall construction order) ... ff^. I ordered construction of walls along the edge .C. ff^. And at the same time designated removal of the ramps .C ff.. Then I've got this (top-down view): .................... WsssWWWsWsWssssssssW where W - successfully built wall, s - suspended construction due to "creature occupying site"... Either resuming or cancelling-rebuilding does not help, worker stands on the same tile he builds the wall on... Dwarf behavior looks completely random to me (I know they are insane, but anyway)...

(0023138) lorb (reporter) 2012-07-02 04:06	Same here. Unsuspending the construction never helps. Cancelling and rebuilding sometimes help.

(0023179) krenshala (reporter) 2012-07-07 12:13	I have actually been having pretty good luck with canceling the job, waiting for the surrounding constructions to be completed, removing any ramps in the tile, and redesignating the wall. It still fails every now and then, but this almost always works. I wonder if this is emergent behavior from the worker not wanting to stand in a tile designated for another construction, combined with the new construction code that allows them to build diagonally?

(0023183) toybasher (reporter) 2012-07-08 12:48	I have the same problem, I was trying to do the bucket method of making a farm (Carve out a room below, and have it designated as a pond zone) but I didnt take something into consideration and wound up with a room too big for the buckets to fill. When I tried to fill up the excess gap using walls, I had dwarves end up standing on the spot where they tried to build, causing the "Creature Occupying Site" error. Luckily I solved it by canceling the wall and rebuilding it.

(0023266) Pufferfish (reporter) 2012-07-18 17:32	So far what I've noticed, is that this happens mostly when there's a down ramp in the surrounding eight tiles - It's what I've noticed on my maps and after I deconstruct/remove the ramp, the building continues along just fine. I'll do a little testing to see if there's anything else that causes the problem.

(0023274) kwieland (reporter) 2012-07-19 12:50	My case was also with a down ramp.

(0023302) Pufferfish (reporter) 2012-07-21 02:45	I think this bug is related to down ramps - most if not all cases here seem to be building them with one nearby. I'll see if it's because they decide to go up the ramp to start the job or if it's just the placement of the ramp in the area that makes it happen. I'm almost positive it's the first case.

(0023326) Pufferfish (reporter) 2012-07-22 23:26 edited on: 2012-07-23 01:31	Yeah, I've got a workaround figured out. Designate the up/down ramp as a restricted area and make a high traffic road as a detour around the down ramp, so he builds from a different direction. It's caused by the dwarf going up the down ramp to build the wall, but since he can't occupy the space where the ramp is, he ends up where the wall is to be constructed, so far as I see.

(0023332) Telarin (reporter) 2012-07-23 10:39	The instances where I have had this issue occur had no up/down ramps anywhere near the construction area.

(0023358) Pufferfish (reporter) 2012-07-25 18:11	Hmm. See if they come in on a diagonal. I've seen a few dwarves building that way so that may be the issue as well, because from what I got from the wiki, they have to be directly adjacent to the wall. That doesn't seem to be the case anymore as I've seen them build like that.

(0023472) vadia (reporter) 2012-08-17 12:59 edited on: 2012-08-17 13:00	Not neccisarily down ramp related. I had the same problem; clear space, dorf works building wall -- silly statement unsuspend -- dorf ignores tried a second place also not near a ramp. It was annoying because it let a blind ogre ruin my whole camp. btw in 34.11

(0023516) DDR (reporter) 2012-09-01 12:00	I've had the same problem, but I've also had a minor case crop up when just building a normal, straight wall on normal, flat ground. The dwarf will stand on the tile she's trying to build on until I remove the wall construction site and build it again. :(

(0023525) nshapter (reporter) 2012-09-04 10:00	I saw this over the weekend with a 2 wide hall, building a wall... key# W = natural wall w = Proposed construction + = floor A = Carved fortification hallway was W++A W++A W++A W++A W++A W++A W++A ordered building Ww+A Ww+A Ww+A Ww+A Ww+A Ww+A Ww+A got built Ww+A Ww+A Ww+A Ww+A W++A Ww+A Ww+A that last square, they just can't build it!

(0023646) Aescula (reporter) 2012-10-09 19:19	Some tests after reading this log: Had a wall that stubbornly refused to be built a la this bug. It was adjascent to a ramp, like so: +=const. floor, v=DRamp, .=grass, O=wall, =wall in question, =open space +++... vvvO.. .. ... This never ever worked. So I built around it to this: +++... vv OO. *.. OO. Canceled and retried. It worked. Seems to be about arriving on a diagonal, yeah.

(0023647) Aescula (reporter) 2012-10-09 19:20	PS: copy to Notepad or something Monospace to see my diagrams right >.<

(0023823) MrC (reporter) 2013-01-07 05:26 edited on: 2013-01-07 05:27	I can confirm this bug I have managed to work around but I'm not exactly sure how to do it. Sometimes its as simple as cancelling the construction and starting it again sometimes i have to deconstruct it and move it. Looks like a bug in the part of the code that stops the dwarf from walling themselves in. Because It has never happened until that feature was added.

(0023834) lethosor (manager) 2013-01-19 11:00	It looks like channeling the square where the wall will be built works (obviously since the dwarves are forced to stand somewhere else). It's harder when building above ground level, because then you might have to remove a construction.

(0023887) krenshala (reporter) 2013-03-06 15:40	Changing the construction order works as well, probably because this gives the dwarf a different option on where to stand. Now that I think about it, when I cancel the construction and the building materials appear, they almost always appear in the NW tile (upper left) of those adjacent to the construction site. I'm thinking this is a useful bit of information in troubleshooting the problem.

(0023894) ag (reporter) 2013-03-07 01:54	This problem happens if the dwarf doing the job, while in the phase of bringing the build item to the tile, reaches the tile via a path that doesn't cross any of the tiles that can be used to actually build the construction. As a result, the tile to work from is not set and remains equal to the position of the construction.

(0024009) krenshala (reporter) 2013-06-16 22:30	If you are right, ag, then the diagonal positions that dwarves build from are not always considered "valid" sites to build from. On top of a 1 tile wide east-west wall I build flooring off the south side for a walkway, then designated more wall tiles on top: +O==X======O+ +++++++++++++ The X above is the wall tile that the masons continually stood on instead of next to when building. The wall was constructed from right to left, and every other tile worked just fine, with the dwarf standing SW of the wall tile constructed.

(0024636) ag (reporter) 2014-03-25 23:46	I actually recently found the code that may be responsible by chance. What it seems to be doing is that when the worker first appears in the 3x3 square surrounding the construction, it changes the job location to the current position of the worker, and sets a flag in the job. If the unit somehow manages to appear directly in the center location via a ramp or otherwise, it still fires and permanently locks the wrong location. Clearing the flag using lua fixes it, because the next worker to do the job can rerun the code.

(0025707) eliotcougar (reporter) 2014-07-11 00:59	It is sad to see that this bug is still present in 0.40... It's so annoying...

(0025754) Rafal99 (reporter) 2014-07-11 08:07 edited on: 2014-07-11 08:09	Hopefully Toady will get to it soon. It is one of the two annoying bugs that were introduced in 0.34.11, the last bugfix release before the two years of 40.01 development, so unfortunately they had to stay all that time. The other one being 0005994.