View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001915 | Dwarf Fortress | Dwarf Mode -- Buildings, General | public | 2010-05-16 22:16 | 2011-04-07 10:11 |
| Reporter | derigo | Assigned To | Toady One | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.31.04 | ||||
| Fixed in Version | 0.31.13 | ||||
| Summary | 0001915: 'link a building to a trigger' or 'lever' list does not center on the selected building | ||||
| Description | 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. | ||||
| Steps To Reproduce | 1) make few bridges 2) make a lever or pressure plate 3) try to link it to the bridges 4) observe | ||||
| Additional Information | New to .04. This is a .03 save ported to .04, unknown if it affects pure .04 games. | ||||
| Tags | No tags attached. | ||||
| related to | 0001951 | new | Delay between performing wrestling move and time advancing | |
| has duplicate | 0002048 | resolved | Linking levers to things | |
| has duplicate | 0002583 | resolved | Lever zooms to wrong item in selection screen | |
| has duplicate | 0002833 | resolved | Linking floodgates (and possibly other items) Z level out of sync with X indicator | |
| has duplicate | 0003093 | resolved | linking floodgates shows wrong floodgate | |
| has duplicate | 0003191 | resolved | Logical2u | When linking lever to bridge building pointer points wrong bridge. |
|
|
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 |
|
|
yarp thats it. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
I am also experiencing this issue. It is highly reproduceable. |
|
|
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. |
|
|
I would like to mention that this is both incredibly irritating, and still occurs on fortresses founded and played in .05. |
|
|
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). |
|
|
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. |
|
|
You can also forbid all stuff you don't want to connect, then connect the remaining stuff, then repeat this procedure for all levers. |
|
|
Confirmed for 0.31.05. |
|
|
I can confirm that this behavior still exists in 0.31.06, at least on a fortress brought forward from previous versions. |
|
|
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)! |
|
|
Still exists in 31.08, also I dont think it was there .03, seems like regression. |
|
|
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). |
|
|
Still exists in 31.08, also I dont think it was there .03, seems like regression. It's unique to the SDL versions. |
|
|
Pressing tab finds the correct target. |
|
|
check same problem for me - very frustrating |
|
|
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. |
|
|
Happening in my 31.08 legacy version. Seems to want to center on the previously selected option instead of what's selected currently. |
|
|
It is happening in my 31.08 legacy version also. |
|
|
happens in 31.8 SDL |
|
|
As a workaround, try pressing 5 on the numpad after scrolling through the list; this recenters the view correctly for me. |
|
|
Confirmed in 0.31.08 on linux. |
|
|
You can see the target *after* you start assigning mechanisms, at that point you can cancel the operation if you picked the wrong one. |
|
|
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. ;) |
|
|
Happening to me with 0.31.10 SDL on Windows. Have only tried doors. |
|
|
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. |
|
|
(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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
It happens on Legacy, too. |
|
|
Confirmed for 0.31.12. Alas. Expecially annoying when targets are located on different z-levels. |
|
|
@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. |
|
|
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. |
|
|
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. |
|
|
Okay, this should be cleaned up for 0.31.13. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-05-16 22:16 | derigo | New Issue | |
| 2010-05-16 22:25 |
|
Note Added: 0006847 | |
| 2010-05-16 22:28 | derigo | Note Added: 0006848 | |
| 2010-05-18 10:15 | pipes | Note Added: 0006955 | |
| 2010-05-18 12:12 | Kanddak | Note Added: 0006966 | |
| 2010-05-18 13:06 | Kanddak | Note Edited: 0006966 | |
| 2010-05-18 14:50 | ItchyBeard | Note Added: 0006978 | |
| 2010-05-20 14:37 | Farmerbob | Note Added: 0007093 | |
| 2010-06-01 09:42 | kamichu22 | Note Added: 0007530 | |
| 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 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-20 00:27 | burlingk | Note Added: 0008746 | |
| 2010-06-20 00:27 | burlingk | Note Edited: 0008746 | |
| 2010-06-20 00:28 | burlingk | Note Edited: 0008746 | |
| 2010-06-20 01:02 |
|
Note Added: 0008747 | |
| 2010-06-21 12:27 |
|
Relationship added | has duplicate 0002048 |
| 2010-06-21 13:07 |
|
Sticky Issue | No => Yes |
| 2010-06-21 13:07 |
|
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-07-07 04:33 | bicker x 2 | Note Added: 0009712 | |
| 2010-07-07 07:35 |
|
Tag Detached: SDL-only | |
| 2010-07-07 09:33 |
|
Relationship added | has duplicate 0002583 |
| 2010-07-07 12:32 | prios | Note Added: 0009734 | |
| 2010-07-08 11:03 | novaalpha | Note Added: 0009796 | |
| 2010-07-09 21:39 | cephalo | Note Added: 0009859 | |
| 2010-07-11 08:04 | burlingk | Note Added: 0009933 | |
| 2010-07-13 23:51 | alexandertnt | Note Added: 0010219 | |
| 2010-07-19 04:48 | Netkev | Note Added: 0010621 | |
| 2010-07-25 14:05 |
|
Relationship added | has duplicate 0002833 |
| 2010-07-26 01:44 | DoctorZuber | Note Added: 0011062 | |
| 2010-07-26 01:45 | DoctorZuber | Note Edited: 0011062 | |
| 2010-07-26 05:56 | greycat | Note Added: 0011069 | |
| 2010-07-26 09:36 | DoctorZuber | Note Added: 0011083 | |
| 2010-07-26 09:38 | Rafal99 | Note Added: 0011084 | |
| 2010-07-28 14:09 | jwest23 | Note Added: 0011201 | |
| 2010-08-16 23:26 | kuketski | Note Added: 0011843 | |
| 2010-08-17 01:10 | kuketski | Note Edited: 0011843 | |
| 2010-08-17 04:55 | Shurhaian | Note Added: 0011848 | |
| 2010-08-18 07:30 | Quietust | Note Added: 0011890 | |
| 2010-08-18 07:53 |
|
Relationship added | related to 0001951 |
| 2010-08-23 07:08 |
|
Relationship added | has duplicate 0003093 |
| 2010-08-23 17:32 | kwieland | Note Added: 0012052 | |
| 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 08:22 |
|
Sticky Issue | Yes => No |
| 2010-09-10 05:10 | Logical2u | Relationship added | has duplicate 0003191 |
