0001915: 'link a building to a trigger' or 'lever' list does not center on the selected building

(0006847)
Footkerchief (manager)
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 [^]

(0006848)
derigo (reporter)
2010-05-16 22:28

yarp thats it.

(0006955)
pipes (reporter)
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.

(0006966)
Kanddak (reporter)
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.

(0006978)
ItchyBeard (reporter)
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.

(0007093)
Farmerbob (reporter)
2010-05-20 14:37

I am also experiencing this issue. It is highly reproduceable.

(0007530)
kamichu22 (reporter)
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.

(0007971)
DarthCloakedDwarf (reporter)
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.

(0007979)
MaXMC (reporter)
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).

(0007980)
MrWiggles (reporter)
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.

(0007986)
Rafal99 (reporter)
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.

(0007993)
Kyle_Solo (reporter)
2010-06-09 08:08

Confirmed for 0.31.05.

(0007996)
Telarin (reporter)
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.

(0008051)
katyrnyn (reporter)
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)!

(0008743)
RusAnon (reporter)
2010-06-19 23:01

Still exists in 31.08, also I dont think it was there .03, seems like regression.

(0008746)
burlingk (reporter)
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).

(0008747)
Footkerchief (manager)
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.

(0009202)
pistolero (reporter)
2010-06-28 00:37

Pressing tab finds the correct target.

(0009261)
KTaipan (reporter)
2010-06-28 11:24

check same problem for me - very frustrating

(0009271)
hyndis (reporter)
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.

(0009340)
hayai (reporter)
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.

(0009346)
slink (reporter)
2010-06-29 18:56

It is happening in my 31.08 legacy version also.

(0009712)
bicker x 2 (reporter)
2010-07-07 04:33

happens in 31.8 SDL

(0009734)
prios (reporter)
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.

(0009796)
novaalpha (reporter)
2010-07-08 11:03

Confirmed in 0.31.08 on linux.

(0009859)
cephalo (reporter)
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.

(0009933)
burlingk (reporter)
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. ;)

(0010219)
alexandertnt (reporter)
2010-07-13 23:51

Happening to me with 0.31.10 SDL on Windows. Have only tried doors.

(0010621)
Netkev (reporter)
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.

(0011062)
DoctorZuber (reporter)
2010-07-26 01:44
edited on: 2010-07-26 01:45

(31.12)
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.

(0011069)
greycat (reporter)
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.

(0011083)
DoctorZuber (reporter)
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.

(0011084)
Rafal99 (reporter)
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.

(0011201)
jwest23 (reporter)
2010-07-28 14:09

It happens on Legacy, too.

(0011843)
kuketski (reporter)
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.

(0011848)
Shurhaian (reporter)
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.

(0011890)
Quietust (reporter)
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.

(0012052)
kwieland (reporter)
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.

(0012443)
Toady One (administrator)
2010-09-06 02:12

Okay, this should be cleaned up for 0.31.13.

Issue History
Date Modified	Username	Field	Change
2010-05-16 22:16	derigo	New Issue
2010-05-16 22:25	Footkerchief	Note Added: 0006847
2010-05-16 22:28	derigo	Note Added: 0006848
2010-05-18 10:15	pipes	Note Added: 0006955
2010-05-18 10:15	pipes	Issue Monitored: pipes
2010-05-18 12:12	Kanddak	Note Added: 0006966
2010-05-18 13:06	Kanddak	Note Edited: 0006966	View Revisions
2010-05-18 14:50	ItchyBeard	Note Added: 0006978
2010-05-18 14:50	ItchyBeard	Issue Monitored: ItchyBeard
2010-05-20 14:37	Farmerbob	Note Added: 0007093
2010-06-01 09:42	kamichu22	Note Added: 0007530
2010-06-08 21:32	Taranli Maren	Issue Monitored: Taranli Maren
2010-06-08 22:07	DarthCloakedDwarf	Note Added: 0007971
2010-06-09 01:52	MaXMC	Note Added: 0007979
2010-06-09 02:51	MrWiggles	Note Added: 0007980
2010-06-09 05:58	Rafal99	Note Added: 0007986
2010-06-09 08:08	Kyle_Solo	Note Added: 0007993
2010-06-09 10:02	Kyle_Solo	Issue Monitored: Kyle_Solo
2010-06-09 11:10	Telarin	Note Added: 0007996
2010-06-10 08:04	katyrnyn	Note Added: 0008051
2010-06-19 23:01	RusAnon	Note Added: 0008743
2010-06-19 23:01	RusAnon	Issue Monitored: RusAnon
2010-06-20 00:27	burlingk	Note Added: 0008746
2010-06-20 00:27	burlingk	Note Edited: 0008746	View Revisions
2010-06-20 00:28	burlingk	Note Edited: 0008746	View Revisions
2010-06-20 01:02	Footkerchief	Note Added: 0008747
2010-06-21 12:27	Footkerchief	Relationship added	has duplicate 0002048
2010-06-21 12:27	Footkerchief	Issue Monitored: Footkerchief
2010-06-21 12:27	Footkerchief	Issue Monitored: Hieronymous Alloy
2010-06-21 13:07	Footkerchief	Sticky Issue	No => Yes
2010-06-21 13:07	Footkerchief	Tag Attached: SDL-only
2010-06-28 00:37	pistolero	Note Added: 0009202
2010-06-28 11:24	KTaipan	Note Added: 0009261
2010-06-28 15:28	hyndis	Note Added: 0009271
2010-06-29 17:06	hayai	Note Added: 0009340
2010-06-29 18:56	slink	Note Added: 0009346
2010-06-30 08:46	Silveron	Issue Monitored: Silveron
2010-06-30 13:53	drisher	Issue Monitored: drisher
2010-07-01 03:56	madman	Issue Monitored: madman
2010-07-07 04:33	bicker x 2	Note Added: 0009712
2010-07-07 07:35	Footkerchief	Tag Detached: SDL-only
2010-07-07 09:23	lvk	Issue Monitored: lvk
2010-07-07 09:23	lvk	Issue End Monitor: lvk
2010-07-07 09:33	Footkerchief	Relationship added	has duplicate 0002583
2010-07-07 09:41	Jinalealia	Issue Monitored: Jinalealia
2010-07-07 12:32	prios	Note Added: 0009734
2010-07-07 15:35	xrogaan	Issue Monitored: xrogaan
2010-07-08 10:58	prios	Issue Monitored: prios
2010-07-08 11:03	novaalpha	Note Added: 0009796
2010-07-08 11:26	JZE	Issue Monitored: JZE
2010-07-09 21:39	cephalo	Note Added: 0009859
2010-07-10 17:57	Jordix	Issue Monitored: Jordix
2010-07-11 06:18	kisto	Issue Monitored: kisto
2010-07-11 08:04	burlingk	Note Added: 0009933
2010-07-13 23:51	alexandertnt	Note Added: 0010219
2010-07-14 05:57	Coledash	Issue Monitored: Coledash
2010-07-19 04:24	Retro	Issue Monitored: Retro
2010-07-19 04:48	Netkev	Note Added: 0010621
2010-07-24 00:08	wRAR	Issue Monitored: wRAR
2010-07-25 14:05	Footkerchief	Relationship added	has duplicate 0002833
2010-07-25 14:59	Sfon	Issue Monitored: Sfon
2010-07-26 01:44	DoctorZuber	Note Added: 0011062
2010-07-26 01:45	DoctorZuber	Note Edited: 0011062	View Revisions
2010-07-26 05:56	greycat	Note Added: 0011069
2010-07-26 08:24	Kanddak	Issue Monitored: Kanddak
2010-07-26 09:36	DoctorZuber	Note Added: 0011083
2010-07-26 09:38	Rafal99	Note Added: 0011084
2010-07-28 12:29	bobbens	Issue Monitored: bobbens
2010-07-28 14:09	jwest23	Note Added: 0011201
2010-07-29 05:32	JimboOmega	Issue Monitored: JimboOmega
2010-07-29 14:41	jwest23	Issue Monitored: jwest23
2010-08-05 18:09	HebaruSan	Issue Monitored: HebaruSan
2010-08-15 18:10	Shurhaian	Issue Monitored: Shurhaian
2010-08-16 23:26	kuketski	Note Added: 0011843
2010-08-17 01:10	kuketski	Note Edited: 0011843	View Revisions
2010-08-17 04:55	Shurhaian	Note Added: 0011848
2010-08-18 07:30	Quietust	Note Added: 0011890
2010-08-18 07:53	Footkerchief	Relationship added	related to 0001951
2010-08-23 07:08	Dwarfu	Relationship added	has duplicate 0003093
2010-08-23 17:32	kwieland	Note Added: 0012052
2010-08-23 17:33	kwieland	Issue Monitored: kwieland
2010-08-23 21:43	FlyingBishop	Issue Monitored: FlyingBishop
2010-09-06 02:12	Toady One	Note Added: 0012443
2010-09-06 02:12	Toady One	Status	new => resolved
2010-09-06 02:12	Toady One	Fixed in Version	=> 0.31.13
2010-09-06 02:12	Toady One	Resolution	open => fixed
2010-09-06 02:12	Toady One	Assigned To	=> Toady One
2010-09-06 07:08	bobbens	Issue End Monitor: bobbens
2010-09-06 08:22	Dwarfu	Sticky Issue	Yes => No
2010-09-06 11:57	kwieland	Issue End Monitor: kwieland
2010-09-07 04:50	Hieronymous Alloy	Issue End Monitor: Hieronymous Alloy
2010-09-10 05:10	Logical2u	Relationship added	has duplicate 0003191
2010-09-17 14:00	Sfon	Issue End Monitor: Sfon
2010-11-03 14:03	jwest23	Issue End Monitor: jwest23
2010-11-26 12:35	Taranli Maren	Issue End Monitor: Taranli Maren
2010-12-28 15:23	Jinalealia	Issue End Monitor: Jinalealia
2011-04-07 10:11	wRAR	Issue End Monitor: wRAR
2016-08-26 10:18	Coledash	Issue End Monitor: Coledash

Notes
(0006847) Footkerchief (manager) 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 [^]

(0006848) derigo (reporter) 2010-05-16 22:28	yarp thats it.

(0006955) pipes (reporter) 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.

(0006966) Kanddak (reporter) 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.

(0006978) ItchyBeard (reporter) 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.

(0007093) Farmerbob (reporter) 2010-05-20 14:37	I am also experiencing this issue. It is highly reproduceable.

(0007530) kamichu22 (reporter) 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.

(0007971) DarthCloakedDwarf (reporter) 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.

(0007979) MaXMC (reporter) 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).

(0007980) MrWiggles (reporter) 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.

(0007986) Rafal99 (reporter) 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.

(0007993) Kyle_Solo (reporter) 2010-06-09 08:08	Confirmed for 0.31.05.

(0007996) Telarin (reporter) 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.

(0008051) katyrnyn (reporter) 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)!

(0008743) RusAnon (reporter) 2010-06-19 23:01	Still exists in 31.08, also I dont think it was there .03, seems like regression.

(0008746) burlingk (reporter) 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).

(0008747) Footkerchief (manager) 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.

(0009202) pistolero (reporter) 2010-06-28 00:37	Pressing tab finds the correct target.

(0009261) KTaipan (reporter) 2010-06-28 11:24	check same problem for me - very frustrating

(0009271) hyndis (reporter) 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.

(0009340) hayai (reporter) 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.

(0009346) slink (reporter) 2010-06-29 18:56	It is happening in my 31.08 legacy version also.

(0009712) bicker x 2 (reporter) 2010-07-07 04:33	happens in 31.8 SDL

(0009734) prios (reporter) 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.

(0009796) novaalpha (reporter) 2010-07-08 11:03	Confirmed in 0.31.08 on linux.

(0009859) cephalo (reporter) 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.

(0009933) burlingk (reporter) 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. ;)

(0010219) alexandertnt (reporter) 2010-07-13 23:51	Happening to me with 0.31.10 SDL on Windows. Have only tried doors.

(0010621) Netkev (reporter) 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.

(0011062) DoctorZuber (reporter) 2010-07-26 01:44 edited on: 2010-07-26 01:45	(31.12) 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.

(0011069) greycat (reporter) 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.

(0011083) DoctorZuber (reporter) 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.

(0011084) Rafal99 (reporter) 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.

(0011201) jwest23 (reporter) 2010-07-28 14:09	It happens on Legacy, too.

(0011843) kuketski (reporter) 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.

(0011848) Shurhaian (reporter) 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.

(0011890) Quietust (reporter) 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.

(0012052) kwieland (reporter) 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.

(0012443) Toady One (administrator) 2010-09-06 02:12	Okay, this should be cleaned up for 0.31.13.