View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010010 | Dwarf Fortress | Dwarf Mode -- Interface, Announcements | public | 2016-09-16 20:52 | 2017-07-18 09:29 |
| Reporter | Simons Mith | Assigned To | Loci | ||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | resolved | Resolution | no change required | ||
| Platform | Mac | OS | OS X | OS Version | 10.9.5 |
| Product Version | 0.43.05 | ||||
| Summary | 0010010: Ill-considered message priorities | ||||
| Description | There is (apparently) a message coming up, important enough to be worth pausing the game over. But because there's a queue of other [lower-priority] messages, by golly every last one of those is going to be displayed first, even if it takes literally an hour. I've been timing it to see how long a large message flurry actually takes to pass, if you don't stop it. But I don't think this one is exceptionally long; it's about typical for the circumstances - a siege in this case. This completely defeats the point of pausing the game; if I press space, all the messages, including the supposedly important one (a childbirth, it turns out), will be skipped. Don't do that; it's daft. Just jump straight to the important message, and maybe give an indicator of how many messages were skipped past. That's what you would expect to happen for an important message. | ||||
| Tags | No tags attached. | ||||
|
|
You can "jump to the important message" and "cancel all pending messages" by simply opening the announcements screen. You can also edit announcements.txt to disable announcements that you personally aren't interested in seeing. Unfortunately there are a number of bugs/features which spam announcements at a rate that can clog up the queue; however automatically "skipping" messages isn't a very user-friendly approach. Regardless, suggestions to improve the announcement system should be posted in the suggestions forum. |
|
|
No, just because there is a workaround for a bug does not mean it is not a bug. If that were true you should also close 0009998 and its siblings, because there's multiple workarounds for dwarves trapped in hospital - e.g. remove bed/traction bench/hospital zone or reinjure them. There are no conceivable circumstances under which pausing the game and then taking half an hour to tell the player why it paused is a sensible piece of UI design. A good sanity check for these kinds of bugs is to ask yourself if the game skipped to the error by default, and there was a config option to turn on the current behaviour, would ANYONE turn on the current behaviour?? The fact that you can configure which messages count as pausable, and suppress unwanted messages merely alters the circumstances (mitigating them, presumably) under which this bug shows up. And skipping to the log is quite a close equivalent to reinjuring a dwarf stuck in hospital; you're making the problem go away by 'blanking it out'. But the underlying behaviour is still a bug, and insisting on displaying hundreds of lower-priority messages one by one is NOT user-friendly behaviour, quite the reverse. I'm sure a lot of established players have just become blind to these kinds of issues. You've long since customised your games, or grown used to the behaviour, and they no longer register with you. But I write user guides and I still notice this stuff. And I'm intentionally playing under the vanilla user interface, without customisation, without Dwarf therapist, and so on, so that I hit these problems as a new player would. |
|
|
"A good sanity check for these kinds of bugs is to ask yourself if the game skipped to the error by default, and there was a config option to turn on the current behaviour, would ANYONE turn on the current behaviour??" I would. I don't have dozens of pending announcements because I avoid the bugs/features which cause excessive announcements. Consequently, any announcements that are pending are important enough that I want the game to display them, not skip over them. Dwarf stuck in a hospital -> bug. Game behaving differently than you prefer -> not bug. |
|
|
What I am trying to report is that /event ZZ occurs, and is deemed important enough to pause the game over/, but then the game /doesn't actually display event ZZ/. That's a bug! Instead the game displays events A, B, C, D, E, F, G,... which are all by definition less important and keeps going for some indefinite period of time before event ZZ eventually bubbles up to the top of the event queue. Which it would have done anyway, given time. This behaviour means pausing the game is moot! That's not a matter of preference, it's a textbook example of incorrect user interface behaviour. It doesn't matter whether there's 2 events queued up before it or 200; they are by definition lower priority. If they were equal priority, the game would already have paused on them. And they're stored in the event log anyway, so they're not lost. Event ZZ is the important event, event ZZ should be the one displayed. |
|
|
"Priority" is a trait you've ascribed to announcements; the game simply uses a FIFO queue. While adding a way to prioritize announcements is a fair suggestion, the proper venue for that is the suggestions forum. In my opinion the current behavior is "working as intended" and not nearly as onerous as you claim. |
|
|
I understand that this is annoying, but UI complaints have gone on the suggestions forum in the past and been addressed there. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-16 20:52 | Simons Mith | New Issue | |
| 2016-09-16 21:54 | Loci | Note Added: 0035878 | |
| 2016-09-16 21:54 | Loci | Status | new => resolved |
| 2016-09-16 21:54 | Loci | Resolution | open => no change required |
| 2016-09-16 21:54 | Loci | Assigned To | => Loci |
| 2016-09-17 07:38 | Simons Mith | Note Added: 0035880 | |
| 2016-09-17 07:38 | Simons Mith | Status | resolved => feedback |
| 2016-09-17 07:38 | Simons Mith | Resolution | no change required => reopened |
| 2016-09-17 08:37 | Loci | Note Added: 0035881 | |
| 2016-09-17 08:37 | Loci | Status | feedback => resolved |
| 2016-09-17 08:37 | Loci | Resolution | reopened => no change required |
| 2016-09-17 10:29 | Simons Mith | Note Added: 0035883 | |
| 2016-09-17 10:29 | Simons Mith | Status | resolved => feedback |
| 2016-09-17 10:29 | Simons Mith | Resolution | no change required => reopened |
| 2016-09-27 08:06 | Loci | Note Added: 0035917 | |
| 2017-01-20 18:26 | lethosor | Note Added: 0036186 | |
| 2017-01-20 18:26 | lethosor | Status | feedback => resolved |
| 2017-01-20 18:26 | lethosor | Resolution | reopened => fixed |
| 2017-07-18 09:29 | lethosor | Resolution | fixed => no change required |
