View Issue Details

IDProjectCategoryView StatusLast Update
0010010Dwarf FortressDwarf Mode -- Interface, Announcementspublic2017-07-18 09:29
ReporterSimons Mith Assigned ToLoci  
PrioritynormalSeverityminorReproducibilityrandom
Status resolvedResolutionno change required 
PlatformMacOSOS XOS Version10.9.5
Product Version0.43.05 
Summary0010010: Ill-considered message priorities
DescriptionThere 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.
TagsNo tags attached.

Activities

Loci

2016-09-16 21:54

viewer   ~0035878

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.

Simons Mith

2016-09-17 07:38

reporter   ~0035880

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.

Loci

2016-09-17 08:37

viewer   ~0035881

"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.

Simons Mith

2016-09-17 10:29

reporter   ~0035883

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.

Loci

2016-09-27 08:06

viewer   ~0035917

"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.

lethosor

2017-01-20 18:26

manager   ~0036186

I understand that this is annoying, but UI complaints have gone on the suggestions forum in the past and been addressed there.

Issue History

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