Casualty selection auto continues without pressing space bar.

[tvleavitt]

How can the problem be recreated?

Start World War II v5 1942 Second Edition. Choose Germans and Japanese as Human, Allies as Hard AI. Russians invade West Russia. Germans take casualties You briefly see "Press Space Bar to Continue", but the game auto continues. Fine. Except that when the Russians win and you see "Russians Win: (Press Space To Close)", it doesn't, and the German "Produce" screen pops up in front of this final screen really quickly, and you can't exit that window unless you first close the "Produce" screen, which only presents you with a "Done" button and thus has no clear way to safely exit without prematurely ending your "Buy..." phase.

Side note: Maybe the "Produce" window should have two buttons: "Complete Buy", "Exit (press "Buy..." to resume)"?

Side note: suggest the "take casualties" button be highlighted as it is when you hover over it or have "(click here)" after "Germans Select X Casualties". It took me a moment to realize what I needed to do to take casualties, I was clicking on the unit icons at the top and didn't notice the relatively subtle highlighting at the bottom of the window. A "button" that spans the full window doesn't register as a "button" immediately, especially with so many other non-clickable window segments, and no separation between it and the "Casualties" display section above it. Also, "None" | "None" right above it is kind of confusing on the first view and serves no purpose; maybe don't display those boxes until casualties have occurred?

Side note: The button in the sidebar that says "Buy..." does not match the title bar "Produce" of the screen that pops up. This is a semantic inconsistency, in my view. The title bar should probably say "Buy..."

What is an expected fix?

Wait for the "Press Space to Close" button to be clicked before popping up the German "Produce" screen. Or use a non-modular window management mechanism that allows me to click on the "Russians attacks Germans in West Russia" window and press space bar (or the button in the window) while the German "Produce" window is visible.

Side note: the "Produce" window being visible also prevents you from accessing "File, View, Game..." etc., which is atypical behavior for an application.

I'm of two minds about defaulting the casualties screen to auto continue rather than waiting for the user to press the space bar. It speeds things up, but it is also counter-intuitive to be prompted to do something, then have no opportunity to do it. It's probably architecturally required by the UI to have this second stage of the casualty selection process display the results of your selection, but I don't see what purpose it actually serves here if it is going to be semi-instantly disappeared.

Which Engine Version are you using? 2.0.18904

Side note: suggest the instructions below be changed to say that the Engine Version can be found under "Help/About" as well as the launch screen.

(Optional) Additional information

[Cernelius]

Side note: The button in the sidebar that says "Buy..." does not match the title bar "Produce" of the screen that pops up. This is a semantic inconsistency, in my view. The title bar should probably say "Buy..."

TripleA is riddled with semantic inconsistencies, and "produce" is also inconsistent with "purchase", meaning the same thing. I actually suggested completely eliminating all title bars (they are redundant and mostly inconsistent with the phase names you can see right of the bottom bar), in here: https://github.com/triplea-game/triplea/issues/5475

[tvleavitt]

Do we have a list of these semantic inconsistencies? If not, we should develop one (and determine which terminology to use where); I presume these are essentially cosmetic changes (absent removal of title bars), and thus are low risk, and can be done in small chunks.

On Wed, Apr 22, 2020 at 2:07 PM Cernelius notifications@github.com wrote:

Side note: The button in the sidebar that says "Buy..." does not match the title bar "Produce" of the screen that pops up. This is a semantic inconsistency, in my view. The title bar should probably say "Buy..."

TripleA is riddled with semantic inconsistencies, and "produce" is also inconsistent with "purchase", meaning the same thing. I actually suggested completely eliminating all title bars (they are redundant and mostly inconsistent with the phase names you can see right of the bottom bar), in here:

5475 https://github.com/triplea-game/triplea/issues/5475

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6307#issuecomment-618040973, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HALTK3YP57DK2FU5BWLRN5MBLANCNFSM4MNYCKKQ .

-- Thomas Leavitt Internet enabled since 1990

[Cernelius]

Beside the one I made at the issue I linked (and that doesn't include any of the several inconsistencies in the buttons and windows), I'm not aware of any.

Also, I'm not sure if you are aware of the fact that this matter (off topic here) is intertwined with the issue that TripleA allows mapmakers to customize phases names, in the game file (xml), but does the job only partially (so, for example, if you want to rename the "Non Combat Move" phase as "Reposition Units" phase (or whatever), you can do it (which is great), but that just creates more inconsistencies, as some entries are hardcoded).

I think the issue I made and linked is a good place for talking about these matters.

[tvleavitt]

I'll post followups on this side note there. Thanks.

On Wed, Apr 22, 2020 at 2:35 PM Cernelius notifications@github.com wrote:

Beside the one I made at the issue I linked (and that doesn't include any of the several inconsistencies in the buttons and windows), I'm not aware of any.

Also, I'm not sure if you are aware of the fact that this matter (off topic here) is intertwined with the issue that TripleA allows mapmakers to customize phases names, in the game file (xml), but does the job only partially (so, for example, if you want to rename the "Non Combat Move" phase as "Reposition Units" phase (or whatever), you can do it (which is great), but that just creates more inconsistencies, as some entries are hardcoded).

I think the issue I made and linked is a good place for talking about these matters.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6307#issuecomment-618053301, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAK25GK4TLG7DRRORPTRN5PLBANCNFSM4MNYCKKQ .

-- Thomas Leavitt Internet enabled since 1990

[DanVanAtta]

@tvleavitt do you know if the auto-continue of 2.0 is different from the 1.9 latest? Asked in another way, is this a new usability problem to 2.0?

[tvleavitt]

Dan,

I happen to have 1.9 installed on a Mac laptop here, just tested. My lizard brain vaguely recalls mentioning this issue or something related previously.

The behavior is slightly different:

a) this is a much slower machine, but the "press space to continue" prompt, if it appears at all, disappears almost immediately, unlike on my Windows box, so the "autocontinue" behavior is definitely there in 1.9 b) the casualties window winds up hidden behind the main map window, rather than on top of it and under the "Produce" window, and thus I suspect I never noticed an issue, in that I'd do the production, initiate combat, and it would automatically be updated, then reappear at the front

On a Mac (I think I mentioned this a long time ago), the File, etc. options are greyed out by the pop up of the Produce window (probably the functional equivalent of not being able to access them in Windows).

I'd say this is an issue inherited from 1.9, perhaps aggravated by a change you made to how the "child" windows display relative to the parent so that it is more visible. I believe I saw that you've made some modifications to how this works in 2.0. I noticed, for example, that the "About" window wound up being left open when I closed the Map, then stayed behind the map when it was reopened while testing yesterday, so it seems to have a different functional relationship to the Map window.

Thomas

On Wed, Apr 22, 2020 at 4:44 PM Dan Van Atta notifications@github.com wrote:

@tvleavitt https://github.com/tvleavitt do you know if the auto-continue of 2.0 is different from the 1.9 latest? Asked in another way, is this a new usability problem to 2.0?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6307#issuecomment-618095288, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAOBD2ZLRNZKTBZPSOLRN56MJANCNFSM4MNYCKKQ .

-- Thomas Leavitt Internet enabled since 1990

[tvleavitt]

Note: this "auto continue" behavior is really confusing in the context of the Tutorial Map, where you have you have literally no idea what just happened (who rolled what, etc.). All you see is "Germans win: (Press space to close)" or a pop up asking whether the Germans should remain or not (which, in fact, appeared in front of the tutorial notification, which in turn was on top of the Battle window) and a single die roll in the background from the defender (not that this is clear with all the different windows popping up and moving around).

[Cernelius]

I personally like the current behaviour, and definitively like a lot not getting stuck with 1 dumb click while someone is afk. So, everything is fine as current, as far as I'm concerned.

However, I'll point out that this and the fact that the battle is autostarted, if it is the only one, are a major problem for the Tutorial, as that one assumes the user starting the battle after reading the notification and actually being able to see what's going on.

To reproduce what I'm saying, play the "round 3" of the Tutorial (Battle in Slovakia Hungary).

[tvleavitt]

I personally have only played against the AI, not against another human. Perhaps the behavior is better suited to the PvP scenario Cernelius mentions, but the "afk" issue is not a problem when you're facing the AI.

Thomas

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Apr 28, 2020 at 4:38 PM Cernelius notifications@github.com wrote:

I personally like the current behaviour, and definitively like a lot not getting stuck with 1 dumb click while someone is afk. So, everything is fine as current, as far as I'm concerned.

However, I'll point out that this and the fact that the battle is autostarted, if it is the only one, are a major problem for the Tutorial, as that one assumes the user starting the battle after reading the notification and actually being able to see what's going on.

To reproduce what I'm saying, play the "round 3" of the Tutorial (Battle in Slovakia Hungary).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6307#issuecomment-620909690, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAIQ6FAYETF2XVHPNF3RO5SH3ANCNFSM4MNYCKKQ .

-- Thomas Leavitt Internet enabled since 1990

[Cernelius]

Yeah, the current behaviour can hardly be justified if you are playing "solo". I suppose it would make sense that wherever only 1 "human" player is assigned, for the whole game, then nothing is skipped automatically. This would mostly fix the tutorial too, though there is still the part where the user is told to go clicking the battle button while the battle already pops up on its own (as this is what happens when there is only one battle to make, but I assume was not the case when the Tutorial was made).

However, I rarely play solo with the AI, so I'm not a good reference on usability, there.

[asvitkine]

I personally like the current behaviour, and definitively like a lot not getting stuck with 1 dumb click while someone is afk. So, everything is fine as current, as far as I'm concerned.

However, I'll point out that this and the fact that the battle is autostarted, if it is the only one, are a major problem for the Tutorial, as that one assumes the user starting the battle after reading the notification and actually being able to see what's going on.

To reproduce what I'm saying, play the "round 3" of the Tutorial (Battle in Slovakia Hungary).

Does anyone actually like the auto-start battle behavior for some battles? Should we just eliminate it?

[DanVanAtta]

The behavior is there to support multiplayer mostly. It's hard to know the breakdown of single player vs multiplayer games, though multiplayer games are a large driver for the community and suffer from slow game-play mechanics. I think the better fix would be to split this as an option for single player and another for multiplayer where we default to true-to-autoclick and false on single player.

[Cernelius]

@DanVanAtta I believe you are getting the two things mixed. Automatically starting a battle when it is the only one has nothing to do with any multiplayer limitations. It is just an unnecessary click for the player controlling the power assigned to the current turn.

I personally would never auto-start a battle.

However, if reintroducing this unnecessary click, please document clearly in the code that is intended, otherwise I can easily see some developer reintroducing the autostart behaviour yet again, at any point in the future.

[DanVanAtta]

@Cernelius the background/original intent perhaps would be interesting. IIRC the unnecessary click was primarily removed for the benefit of multiplayer game flow. We had a few iterations some time ago to remove unnecessary clicks as it was recognized that these can cause delays. The unnecessary click is not terribly consequential in single player.

[tvleavitt]

We could introduce a logging mechanism that logs anonymized usage data to a central collection point and let people opt in, that might let is see how many people use it for single vs. multi. Or a survey on install, or a survey that pops up after, say 10 games played, and asks how people use it, etc. In my view, the more usage data we have, the better.

Thomas Leavitt

On Sat, May 23, 2020, 12:52 PM Dan Van Atta notifications@github.com wrote:

The behavior is there to support multiplayer mostly. It's hard to know the breakdown of single player vs multiplayer games, though multiplayer games are a large driver for the community and suffer from slow game-play mechanics. I think the better fix would be to split this as an option for single player and another for multiplayer where we default to true-to-autoclick and false on single player.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6307#issuecomment-633127285, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAMBOHQ2U6DCGJPVELLRTASQTANCNFSM4MNYCKKQ .