Added body count to initiative panel title.

[bubblobill]

Identify the Bug or Feature request

resolves #5985

Description of the Change

Status bar displays a summary of the initiative panel.
e.g.

Summary is only displayed for GMs when the initiative panel is active.

Possible Drawbacks

none

Documentation Notes

Initiative summary status message.

---

This change is 

[kwvanderlinde]

I think it would be better to leave the status bar out of this as it's already full of instructions and whatnot. Especially since the Initiative window needs to be open anyways for this feature, it might as well be in there with the rest of the initiative info.

[bubblobill]

@kwvanderlinde
I considered a few variations.

• the frame title (not long enough)
• the frame status bar (does not exist)
• another display element (i.e. create a status bar or similar. Seems unnecessarily over-achievery)
• a tooltip (would require repeated hover actions by the GM)
• the status bar (consistent with UI as it is supposed to be updated contextually)

[FullBleed]

I use a "RolledInit" state (just a shaded green state at 20%) so I can see who has rolled init (then when I "sort" it removes the state). I agree that knowing everyone has rolled init is important, but I don't think just seeing the number of PCs or NPCs that have rolled init is good enough... I need to know who has (or, more importantly, who hasn't) rolled.

A highlight behind the init window token line for tokens that have rolled init would be more obvious and useful, imo.

[kwvanderlinde]

I really like your suggestion of highlighting entries @FullBleed. It doesn't quite do everything that the original FR needs, so I think also having some textual summary is also important.

@bubblobill

• the frame status bar (does not exist)
• another display element (i.e. create a status bar or similar. Seems unnecessarily over-achievery)

There is already the round label for showing the current round number, so there is a status bar of sorts. Not that I would receommend cramming information in there as the might not be much room depending on the user's layout. But a label just under the toolbar should have plenty of of space. And with it being in the init window, we wouldn't need to show the current token's name, we could just show the counts and sorted status. In the future, we could even represent the sorted-ness of a list as an icon or something.

Not the prettiest mock-up, but this is what I'm picturing:

[kwvanderlinde]

If the goal is to know whether all the PCs or NPCs have rolled initiative, I think we should also include the total number of them that are on the map. E.g.,

PC: 1/4, NPC: 2/5, ...

[kwvanderlinde]

I should have said totals in the initiative, not on the map.

[bubblobill]

No. This is what the status bar is for.

You should try gaming on a 13" screen with larger fonts. You might stop thinking additional fru-fru panels are a good idea.

[FullBleed]

I like the idea of keeping it in the init window if it can scroll like the status bar. ;)

Anyway, can we get something more than just a number? If we don't get a highlight of rolled players/npcs at least give me their names in the list: PC: Conan, Sonja, Elric -- NPC: Derp, Twerp, Herp

[kwvanderlinde]

No. This is what the status bar is for.

Well, no. It's really not designed for competing, persistent statuses. The problem here is that, unlike tools, the initiative window is not an exclusive state. Instead, this new initative status competes with other statuses like tool instructions.

I should point out that a similar issue already exists for "notification" messages, e.g., for auto-save. Other important details in the status bar are hidden indefinitely for what is an event of temporary importance. It just doesn't work well to mix these types of things together. Adding initiative status in there makes it worse.

You should try gaming on a 13" screen with larger fonts. You might stop thinking additional fru-fru panels are a good idea.

I did actually check this case out (granted my laptop screen is slightly larger than your screen, but not by much). The thing is, my proposed label takes up less horizontal space than the existing initiative toolbar, and the extra vertical space it takes is not appreciable. What I did find is that the status bar can start getting crowded out by the other elements at the bottom of the window.

---

There are a number of reasons I am pushing back on the use of the status bar for this. Some are technical, some are UX:

1. UX: All the other initiative info is in the initiative window. If I want to know anything about initiative, that's where I'll look. Especially since the initiative window needs to be open for this feature to work, I would not think about opening that window and then looking elsewhere for this information.
2. UX: If we are going to use the status bar, it's not clear to me as a user why I need the initiative window to be activated. If I populate an initiative list, shouldn't the initiative status message be shown regardless? And if not, shouldn't it be enough for the initiative window to be open and visible rather than activated (focused).
3. UX & Technical: Status is not consistent with application state (already a problem with "notification" statuses as mentioned above). If the user picks a tool, they see the tool instructions. When they start initiative and activate the initiative window, now they see the initiative status. If they do things in the other order, they get the opposite despite the application otherwise being in the same state.
4. Technical: When do we show or hide initiative status? Every way a user can end up with an active initiative window and a populated initiative list needs to result in the status being shown. On the flip side, if either of these conditions isn't met, the status must be hidden. I don't know all possible triggers for these cases, but there are a couple cases that have been missed already:
   • If the initiative window is already active, then tokens are added to initiative.
   • If the initiative list is cleared when the initiative window is active.
5. Technical: It is not enough to restore the previous status message when hiding the initiative status message. If the user switches to a new tool while the initiative window is open, we would end up showing them the wrong instructions. Or in another case, we would be telling them that the campaign auto-saved again when it did not. We need to switch to a message that is actually pertinent to the user at the present time. One particular case to keep in mind here is that the initative details can get "stuck" being shown since the initiative window can be activated while initiative details are already being displayed in the status bar. Closing the initiative window then shows the same message rather than showing the actual previous message.

[bubblobill]

Anyway, can we get something more than just a number? If we don't get a highlight of rolled players/npcs at least give me their names in the list: PC: Conan, Sonja, Elric -- NPC: Derp, Twerp, Herp

No. With your row highlighting and a full list of who has and who hasn't, you are leaving behind a brief summary and going into new features for the initiative window which is out of scope for this.

Bearing in mind that initiative has been begging for a rework for in excess of a decade.

[bubblobill]

No. This is what the status bar is for.
Well, no. It's really not designed for competing, persistent statuses. The problem here is that, unlike tools, the initiative window is not an exclusive state. Instead, this new initative status competes with other statuses like tool instructions.

The summary only shows for the GM, when the initiative window is active. You are not interacting with the map with the initiative window active. It ceases to be active the moment you go somewhere else, like the map. At which point the previous message is restored or replaced with the appropriate helpful contextual information.

I should point out that a similar issue already exists for "notification" messages, e.g., for auto-save. Other important details in the status bar are hidden indefinitely for what is an event of temporary importance. It just doesn't work well to mix these types of things together. Adding initiative status in there makes it worse.

Then make them temporary and replace them with the previous message after a given time.
Fix them, don't pooh-pooh this.

I did actually check this case out (granted my laptop screen is slightly larger than your screen, but not by much). The thing is, my proposed label takes up less horizontal space than the existing initiative toolbar, and the extra vertical space it takes is not appreciable. What I did find is that the status bar can start getting crowded out by the other elements at the bottom of the window.

Which is why it scrolls the hidden parts into view as a marquee. An improvement I made btw to accommodate some of your ridiculously long status messages :)

There are a number of reasons I am pushing back on the use of the status bar for this. Some are technical, some are UX:

1. UX: All the other initiative info is in the initiative window. If I want to know anything about initiative, that's where I'll look. Especially since the initiative window needs to be open for this feature to work, I would not think about opening that window and then looking elsewhere for this information.

If you want all the nitty gritty, then yes, go to the initiative window and delve. When your initiative window is not large enough to show the entire contents, you can either go scrolling, or just look at the status bar to see you are missing a PC.

2. UX: If we are going to use the status bar, it's not clear to me as a user why I need the initiative window to be activated. If I populate an initiative list, shouldn't the initiative status message be shown regardless? And if not, shouldn't it be enough for the initiative window to be open and visible rather than activated (focused).

Dude, nobody (sorry FullBleed), and I mean nobody, populates the initiative list with all the PCs/NPCs and then sets the initiative. This is why we have macros.

One button makes everyone happy.

[h: addToInitiative(true, 1d20, currentToken())]
[h: sortInitiative()]
[h: broadcast(blah)]

And I set it to only when active because the use case is built around my GM wanting to be able to know how many PCs are in the list after he told everyone to roll initiative. Whilst everyone is being added, having the value set, and the list being sorted, the list is jumping around all over the place.

3. UX & Technical: Status is not consistent with application state (already a problem with "notification" statuses as mentioned above). If the user picks a tool, they see the tool instructions. When they start initiative and activate the initiative window, now they see the initiative status. If they do things in the other order, they get the opposite despite the application otherwise being in the same state.

Nobody gives a toss about the application state. They care about the useful tips telling them which accelerator key to hold down or which mouse button to press.

4. Technical: When do we show or hide initiative status? Every way a user can end up with an active initiative window and a populated initiative list needs to result in the status being shown. On the flip side, if either of these conditions isn't met, the status must be hidden. I don't know all possible triggers for these cases, but there are a couple cases that have been missed already:

Pretty sure I got all the initiative list change events; added, removed, changed, etc.
Only updates if you are the GM with the window active, i.e. you are doing initiative things or want to see the summary.

5. Technical: It is not enough to restore the previous status message when hiding the initiative status message. If the user switches to a new tool while the initiative window is open, we would end up showing them the wrong instructions. Or in another case, we would be telling them that the campaign auto-saved again when it did not. We need to switch to a message that is actually pertinent to the user at the present time. One particular case to keep in mind here is that the initative details can get "stuck" being shown since the initiative window can be activated while initiative details are already being displayed in the status bar. Closing the initiative window then shows the same message rather than showing the actual previous message.

The important thing: Switching to a new tool just flat overrides the initiative summary status.

My being responsible and restoring the previous message may well leave inappropriate notifications on display. That is an issue with persistent pointless messages.
This and all the other things require that you to rewrite the status bar messaging code to be more sensible.
While you are at it, kill some of the pointless things like the volume free space, traffic arrows and the players zone loaded count.

[FullBleed]

Dude, nobody (sorry FullBleed), and I mean nobody, populates the initiative list with all the PCs/NPCs and then sets the initiative. This is why we have macros.

Why "sorry"? I don't even know what point you're making here or why you're intimating that I'm doing something unusual. I solve the "problem" this PR addresses with macros in my framework, but it seemed like the PR was actually trying to help people avoid having to do that (but then you quip, "This is why we have macros.")

The problem this PR is supposed to address is to "know when all my players have rolled initiative." And while I guess it sort of does that provided the number matches the number of PC tokens in the init window, I think it's flawed because it's borderline useless information if I'm still having to query, "Who hasn't rolled initiative?" when it doesn't.

Also, in static init games init is really only "rolled" in the first round or maybe when a token is added to the panel. But games with init every round (what I primarily use) it would need to reset the rolled count each round. And I'm not sure how this will respond to segmented inits where tokens can be in the init panel more than once. How is the count processed in this?

[FullBleed]

No. With your row highlighting and a full list of who has and who hasn't, you are leaving behind a brief summary and going into new features for the initiative window which is out of scope for this.

Are we getting row highlighting? You didn't indicate an interest in it. I was just asking for one or the other option to indicate who actually rolled init. Lots of ways to skin that cat... and I figured in-line would be easier. An option to use a name instead of a number can't possibly be a heavy lift.

Bearing in mind that initiative has been begging for a rework for in excess of a decade.

Agreed.

I keep seeing frameworks that are using pretty overlay initiative displays and it makes me want to switch over to something like that...

[Baaaaaz]

Given different maps each have their own initiative list and share the initiative panel, does this change handle changing maps when the initiative panel is active?

Writing to the status bar is of no use to those GMs using full screen mode though as the status bar is absent in full screen mode (please don't add it! ;). In full screen mode the initiative panel can be toggled on or off so having the summary on there would be better IMO.

Writing a summary to the status bar would prevent future use of it for initiative window tips (in the manner of the tool tips). Which is good for new users of MapTool.

I'm on the side of this summary being in the initiative panel rather than on the status bar. But even then the getInitiativeList() macro could be tweaked to include a new "summary" key and then would accessible via simple macro call and users can have in a frame, overlay, etc.

[Baaaaaz]

For out of scope initiative improvement ideas, there is this place: https://discord.com/channels/296230822262865920/1328886476381098054

[bubblobill]

Given different maps each have their own initiative list and share the initiative panel, does this change handle changing maps when the initiative panel is active?

yes

I'm on the side of this summary being in the initiative panel rather than on the status bar. But even then the getInitiativeList() macro could be tweaked to include a new "summary" key and then would accessible via simple macro call and users can have in a frame, overlay, etc.

no good for this FR use case as it will not provide live updates.

[bubblobill]

Why "sorry"?
Because your brain works differently to mine - and when I make massively over-generalised comments like I did - I know that you will have a different viewpoint (which I acknowledge is perfectly valid). So I apologised, knowing that you are in the discussion and will likely disagree with my childish standpoint.

The problem this PR is supposed to address is to "know when all my players have rolled initiative."

My bad description. In our group, rolling initiative is synonymous with being added to initiative.

[bubblobill]

@kwvanderlinde
Rather than dispute points, I have opted to cave-in and just go with a bare minimum on the title bar that satisfies the FR.
Less useful, but it meets what my GM wanted.

Info in title:

Info in title with tooltip:

[FullBleed]

I have opted to cave-in and just go with a bare minimum on the title bar that satisfies the FR. Less useful, but it meets what my GM wanted.

This might sound a bit more dismissive than I actually intend... but I still don't find this to be useful information. Which is fine. Every PR isn't for everyone. But I'd really prefer not to have random "useless" information in the UI when possible. MT's ui is programmatic enough. Can you add an option in the Initiative panel hamburger menu to not display this?

[bubblobill]

I have opted to cave-in and just go with a bare minimum on the title bar that satisfies the FR. Less useful, but it meets what my GM wanted.

This might sound a bit more dismissive than I actually intend... but I still don't find this to be useful information. Which is fine. Every PR isn't for everyone. But I'd really prefer not to have random "useless" information in the UI when possible. MT's ui is programmatic enough. Can you add an option in the Initiative panel hamburger menu to not display this?

Good idea. On it.