Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0001915Dwarf FortressDwarf Mode -- Buildings, Generalpublic2010-05-16 22:162011-04-07 10:11
Toady One 
0001915: 'link a building to a trigger' or 'lever' list does not center on the selected building
It seems to center on the previous building in the list. This makes it pretty difficult to tell what you're connecting a lever to.
1) make few bridges
2) make a lever or pressure plate
3) try to link it to the bridges
4) observe
New to .04. This is a .03 save ported to .04, unknown if it affects pure .04 games.
No tags attached.
related to 0001951new  Delay between performing wrestling move and time advancing 
has duplicate 0002048resolved Footkerchief Linking levers to things 
has duplicate 0002583resolved Footkerchief Lever zooms to wrong item in selection screen 
has duplicate 0002833resolved Footkerchief Linking floodgates (and possibly other items) Z level out of sync with X indicator 
has duplicate 0003093resolved Dwarfu linking floodgates shows wrong floodgate 
has duplicate 0003191resolved Logical2u When linking lever to bridge building pointer points wrong bridge. 
Issue History
2010-05-16 22:16derigoNew Issue
2010-05-16 22:25FootkerchiefNote Added: 0006847
2010-05-16 22:28derigoNote Added: 0006848
2010-05-18 10:15pipesNote Added: 0006955
2010-05-18 10:15pipesIssue Monitored: pipes
2010-05-18 12:12KanddakNote Added: 0006966
2010-05-18 13:06KanddakNote Edited: 0006966bug_revision_view_page.php?bugnote_id=0006966#r2609
2010-05-18 14:50ItchyBeardNote Added: 0006978
2010-05-18 14:50ItchyBeardIssue Monitored: ItchyBeard
2010-05-20 14:37FarmerbobNote Added: 0007093
2010-06-01 09:42kamichu22Note Added: 0007530
2010-06-08 21:32Taranli MarenIssue Monitored: Taranli Maren
2010-06-08 22:07DarthCloakedDwarfNote Added: 0007971
2010-06-09 01:52MaXMCNote Added: 0007979
2010-06-09 02:51MrWigglesNote Added: 0007980
2010-06-09 05:58Rafal99Note Added: 0007986
2010-06-09 08:08Kyle_SoloNote Added: 0007993
2010-06-09 10:02Kyle_SoloIssue Monitored: Kyle_Solo
2010-06-09 11:10TelarinNote Added: 0007996
2010-06-10 08:04katyrnynNote Added: 0008051
2010-06-19 23:01RusAnonNote Added: 0008743
2010-06-19 23:01RusAnonIssue Monitored: RusAnon
2010-06-20 00:27burlingkNote Added: 0008746
2010-06-20 00:27burlingkNote Edited: 0008746bug_revision_view_page.php?bugnote_id=0008746#r3347
2010-06-20 00:28burlingkNote Edited: 0008746bug_revision_view_page.php?bugnote_id=0008746#r3348
2010-06-20 01:02FootkerchiefNote Added: 0008747
2010-06-21 12:27FootkerchiefRelationship addedhas duplicate 0002048
2010-06-21 12:27FootkerchiefIssue Monitored: Footkerchief
2010-06-21 12:27FootkerchiefIssue Monitored: Hieronymous Alloy
2010-06-21 13:07FootkerchiefSticky IssueNo => Yes
2010-06-21 13:07FootkerchiefTag Attached: SDL-only
2010-06-28 00:37pistoleroNote Added: 0009202
2010-06-28 11:24KTaipanNote Added: 0009261
2010-06-28 15:28hyndisNote Added: 0009271
2010-06-29 17:06hayaiNote Added: 0009340
2010-06-29 18:56slinkNote Added: 0009346
2010-06-30 08:46SilveronIssue Monitored: Silveron
2010-06-30 13:53drisherIssue Monitored: drisher
2010-07-01 03:56madmanIssue Monitored: madman
2010-07-07 04:33bicker x 2Note Added: 0009712
2010-07-07 07:35FootkerchiefTag Detached: SDL-only
2010-07-07 09:23lvkIssue Monitored: lvk
2010-07-07 09:23lvkIssue End Monitor: lvk
2010-07-07 09:33FootkerchiefRelationship addedhas duplicate 0002583
2010-07-07 09:41JinalealiaIssue Monitored: Jinalealia
2010-07-07 12:32priosNote Added: 0009734
2010-07-07 15:35xrogaanIssue Monitored: xrogaan
2010-07-08 10:58priosIssue Monitored: prios
2010-07-08 11:03novaalphaNote Added: 0009796
2010-07-08 11:26JZEIssue Monitored: JZE
2010-07-09 21:39cephaloNote Added: 0009859
2010-07-10 17:57JordixIssue Monitored: Jordix
2010-07-11 06:18kistoIssue Monitored: kisto
2010-07-11 08:04burlingkNote Added: 0009933
2010-07-13 23:51alexandertntNote Added: 0010219
2010-07-14 05:57ColedashIssue Monitored: Coledash
2010-07-19 04:24RetroIssue Monitored: Retro
2010-07-19 04:48NetkevNote Added: 0010621
2010-07-24 00:08wRARIssue Monitored: wRAR
2010-07-25 14:05FootkerchiefRelationship addedhas duplicate 0002833
2010-07-25 14:59SfonIssue Monitored: Sfon
2010-07-26 01:44DoctorZuberNote Added: 0011062
2010-07-26 01:45DoctorZuberNote Edited: 0011062bug_revision_view_page.php?bugnote_id=0011062#r4309
2010-07-26 05:56greycatNote Added: 0011069
2010-07-26 08:24KanddakIssue Monitored: Kanddak
2010-07-26 09:36DoctorZuberNote Added: 0011083
2010-07-26 09:38Rafal99Note Added: 0011084
2010-07-28 12:29bobbensIssue Monitored: bobbens
2010-07-28 14:09jwest23Note Added: 0011201
2010-07-29 05:32JimboOmegaIssue Monitored: JimboOmega
2010-07-29 14:41jwest23Issue Monitored: jwest23
2010-08-05 18:09HebaruSanIssue Monitored: HebaruSan
2010-08-15 18:10ShurhaianIssue Monitored: Shurhaian
2010-08-16 23:26kuketskiNote Added: 0011843
2010-08-17 01:10kuketskiNote Edited: 0011843bug_revision_view_page.php?bugnote_id=0011843#r4610
2010-08-17 04:55ShurhaianNote Added: 0011848
2010-08-18 07:30QuietustNote Added: 0011890
2010-08-18 07:53FootkerchiefRelationship addedrelated to 0001951
2010-08-23 07:08DwarfuRelationship addedhas duplicate 0003093
2010-08-23 17:32kwielandNote Added: 0012052
2010-08-23 17:33kwielandIssue Monitored: kwieland
2010-08-23 21:43FlyingBishopIssue Monitored: FlyingBishop
2010-09-06 02:12Toady OneNote Added: 0012443
2010-09-06 02:12Toady OneStatusnew => resolved
2010-09-06 02:12Toady OneFixed in Version => 0.31.13
2010-09-06 02:12Toady OneResolutionopen => fixed
2010-09-06 02:12Toady OneAssigned To => Toady One
2010-09-06 07:08bobbensIssue End Monitor: bobbens
2010-09-06 08:22DwarfuSticky IssueYes => No
2010-09-06 11:57kwielandIssue End Monitor: kwieland
2010-09-07 04:50Hieronymous AlloyIssue End Monitor: Hieronymous Alloy
2010-09-10 05:10Logical2uRelationship addedhas duplicate 0003191
2010-09-17 14:00SfonIssue End Monitor: Sfon
2010-11-03 14:03jwest23Issue End Monitor: jwest23
2010-11-26 12:35Taranli MarenIssue End Monitor: Taranli Maren
2010-12-28 15:23JinalealiaIssue End Monitor: Jinalealia
2011-04-07 10:11wRARIssue End Monitor: wRAR
2016-08-26 10:18ColedashIssue End Monitor: Coledash

2010-05-16 22:25   
This is a .03 save ported to .04, unknown if it affects pure .04 games.

Shouldn't affect anything, AFAIK.

There were plenty of mechanism-linking issues in the 40d# versions too:

http://www.bay12forums.com/smf/index.php?topic=51719.0 [^]
http://www.bay12forums.com/smf/index.php?topic=49617.0 [^]
http://www.bay12forums.com/smf/index.php?topic=49616.0 [^]
http://www.bay12forums.com/smf/index.php?topic=44829.msg1014460#msg1014460 [^]
2010-05-16 22:28   
yarp thats it.
2010-05-18 10:15   
This is also happening to me. New install of .04, new game. Definitely zooming to the previous item in the list, though highlighting the proper one.
2010-05-18 12:12   
(edited on: 2010-05-18 13:06)
Happens to me in a new game in .04.
It's not going to the previous item on the list, it's going to the item I had previously selected (which will always be the previous item on the list if you only scroll down through the list), UNLESS the two items are on the same z-level, in which case it works fine.
So it's putting the yellow selection X in the right place, but viewing the z-level of the previously selected item.

2010-05-18 14:50   
I've also been experiencing this with linking to bridges and floodgates. This is definitely a new problem related to the new display support in .04.

I've found it is possible to work around the problem by resetting the zoom while the buggy target is selected. The correct target will then be zoomed to.

e.g. select a structure to link to, and then hit F10, or mouse wheel up and then down.
2010-05-20 14:37   
I am also experiencing this issue. It is highly reproduceable.
2010-06-01 09:42   
Yeah, it seems the X cursor is drawn on the correct linking object. However, when you are scrolling through the list of objects the screen will center on the object previous in list (or perhaps next in the list, it depends on which direction you are scrolling).

If the next and previous objects are on the same Z level, you will see the correct object (since the X is drawn correctly) but if they are on different Z levels you will not see the object you're actually selecting.
2010-06-08 22:07   
I would like to mention that this is both incredibly irritating, and still occurs on fortresses founded and played in .05.
2010-06-09 01:52   
My solution for this is moving up and then down in the list, the view will then snap to the correct one (for me at least).
2010-06-09 02:51   
This is annoying as hell, and happens in .5 as well, on the Mac Build.

I resorted to building targeted gears out of unquie stone.
2010-06-09 05:58   
You can also forbid all stuff you don't want to connect, then connect the remaining stuff, then repeat this procedure for all levers.
2010-06-09 08:08   
Confirmed for 0.31.05.
2010-06-09 11:10   
I can confirm that this behavior still exists in 0.31.06, at least on a fortress brought forward from previous versions.
2010-06-10 08:04   
I ran into this bug last night, so it still exists in 31.06 even for new forts.

Yay for off-by-one faults (as this appears to be)!
2010-06-19 23:01   
Still exists in 31.08, also I dont think it was there .03, seems like regression.
2010-06-20 00:27   
(edited on: 2010-06-20 00:28)
I remember it there as early as .01 and every version sense. Maybe even in 40d. I think that it would be nice to be able to name bridges as well. That would help simplify things too (at the user level).

2010-06-20 01:02   
Still exists in 31.08, also I dont think it was there .03, seems like regression.

It's unique to the SDL versions.
2010-06-28 00:37   
Pressing tab finds the correct target.
2010-06-28 11:24   
check same problem for me - very frustrating
2010-06-28 15:28   
Definitely seeing this is 31.08. Moving back and forth through the list seems to help center the view on the object you want to link the lever to.

If you have a bunch of bridges, scroll down to the bridge you want. Then to the bridge below it. Then scroll back up one. Its a workaround and can usually get the game to show you the object you're selecting, but its still clunky.
2010-06-29 17:06   
Happening in my 31.08 legacy version. Seems to want to center on the previously selected option instead of what's selected currently.
2010-06-29 18:56   
It is happening in my 31.08 legacy version also.
bicker x 2   
2010-07-07 04:33   
happens in 31.8 SDL
2010-07-07 12:32   
As a workaround, try pressing 5 on the numpad after scrolling through the list; this recenters the view correctly for me.
2010-07-08 11:03   
Confirmed in 0.31.08 on linux.
2010-07-09 21:39   
You can see the target *after* you start assigning mechanisms, at that point you can cancel the operation if you picked the wrong one.
2010-07-11 08:04   
The point is that one should not have to cancel because they got the wrong one.

One possible option is to add a method to name bridges. Would be more realistic as an added benefit. ;)
2010-07-13 23:51   
Happening to me with 0.31.10 SDL on Windows. Have only tried doors.
2010-07-19 04:48   
Also happening to me in 31.10, the problem seems to occur whenever a switch in between z-levels happen, i don't seem to get the problem otherwise.
2010-07-26 01:44   
(edited on: 2010-07-26 01:45)
This seems to be an OB1 (off by one) error. It seems to be zooming to the right x,y but it's picking the z from the previous selection.

What I did is I build two floodgates right next to each other. When I first selected one to apply a trigger the x,y was in the right place, but many z-levels too high. Moving to the second floodgate, it displays correctly. Moving back to the first, it also displays correctly.

2010-07-26 05:56   
I try to match the type of rock between the lever and the thing it's linking to. Not only does this help work around the display bug mentioned here, but later, it helps me remember which lever does what.

Often this means I need to make a 1-tile stone stockpile right outside the mechanic's workshop, with a specific type of stone allowed, and then keep making mechanisms until I get at least one of the type needed for the lever.
2010-07-26 09:36   
color coding isn't a bad plan anyhow, although I typically end up with many many more levers than there are types of rock.

This bug made a real hash out of some of my first constructions which is going to cause me all sorts of headaches to fix later. At least now I understand it well enough to hopefully avoid any other mix-ups.
2010-07-26 09:38   
You can forbid all your floodgates or whatever you link, and then only unforbid the one you want to link, then link it, forbid again, repeat with another one.

Anyone tested if it happens in Legacy version too?
I remember this bug started happening in 40dXX versions, so that it is probably related to SDL code changes.
2010-07-28 14:09   
It happens on Legacy, too.
2010-08-16 23:26   
(edited on: 2010-08-17 01:10)
Confirmed for 0.31.12. Alas. Expecially annoying when targets are located on different z-levels.

2010-08-17 04:55   
@DoctorZuber, 0011062 - no, it's not using the proper x,y either. I had a trio of floodgates on the same z; they all could fit on the same view, but they were far enough apart in y that putting the cursor on the higher one would nudge the screen up, putting it on either of the lower two would nudge the screen down. The link list didn't handle this properly - it was, quite simply, centering on the prior selection, in x,y as well as z.

If you observed other behaviour, then there's some further inconsistency at work.

Recentering with Num5 seems to be the most viable way of dealing with the problem for now - it's an extra step to look at the item in question, but much less annoying than hunting down the others and forbidding them.
2010-08-18 07:30   
Clicking on the window also seems to update the camera position, making it very similar (if not identical) to the behavior seen in 0001951/0001952/0001907/0002095.
2010-08-23 17:32   
I stumbled upon a workaround for those following this bug. When you are on the select list and it is showing the incorrect item, hit the "v" key, and the view will zoom to the correct item.
Toady One   
2010-09-06 02:12   
Okay, this should be cleaned up for 0.31.13.