[interface] Solve the "accidental confirm" problem

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderators: Forum Moderators, Developers

Forum rules
Before posting a new idea, you must read the following:
Post Reply
gnombat
Posts: 239
Joined: June 10th, 2010, 8:49 pm
Contact:

[interface] Solve the "accidental confirm" problem

Post by gnombat » January 31st, 2012, 7:15 am

This may have been brought up before, but I could not figure out what search terms to enter into the Inter-nets. The closest thing I could find to a canonical name for the issue is "accidental confirm".

It's difficult to describe the problem exactly; probably the best way to do it is to give an example:
  • A user starts the campaign Under the Burning Suns, scenario 1, turn 1.
  • The user decides to move Nym east, and then move Kaleh east also.
  • The user clicks on Nym, then clicks on a spot to the east 6 hexes away. The animation of Nym moving east starts.
  • The user moves the mouse pointer towards Kaleh, then when Nym has finished moving the user clicks on Kaleh to move him.
  • Depending on the timing, that mouse click may end up closing the dialog that pops up, before the user has a chance to read it.
I'm not sure what would be the best way to solve this problem. I can think of some ideas:
  1. Don't close the dialog when the user clicks on the main part of the screen. Require the user to click somewhere else; e.g. the "End Turn" button could change to "Close Dialog" when there is a dialog up. (The problem with this is that it is a lot more convenient to just click anywhere; people are already complaining about clicking on the "End Turn" button, and this would just make it worse because it would be necessary to click that button much more often.)
  2. In Firefox, when a user tries to install an add-on, a dialog box is displayed with an "Install" button which is disabled for 3 seconds (which count down 3 ... 2 ... 1 ...).
    Firefox add-on dialog box
    Firefox add-on dialog box
    firefox-dialog.png (8.95 KiB) Viewed 2162 times
  3. If there were a way to go back to the dialog after closing it, then accidentally closing it would not be a problem. Version 1.10 of Wesnoth added a "back" button for the story screens; could the same thing be done for the dialog boxes?

User avatar
shadowm
Site Administrator
Posts: 6575
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by shadowm » January 31st, 2012, 7:29 am

gnombat wrote:In Firefox, when a user tries to install an add-on, a dialog box is displayed with an "Install" button which is disabled for 3 seconds (which count down 3 ... 2 ... 1 ...).
I believe there originally was a restriction set in the implementation of the message action to not let the user dismiss the pop-up dialog before a few milliseconds passed, or there were intentions to implement this. If it isn’t the latter, it might have been lost when the dialog code was replaced during the 1.5.x development cycle.

This seems like the most reasonable solution to me. A limit of 100 or 250 milliseconds would make sense. (Also note FR #18483 [Gna.org].)

Option 1 is pretty much ruled out for the reasons you provided. Option 3 would be much more difficult to implement, in principle, since it would require keeping a history of previous messages around along with all their information (caption, image, etc.); it’s not feasible to go back in the WML command queue if there are actions with side-effects that could affect message display (units dying or transforming, for example).
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

User avatar
tr0ll
Posts: 522
Joined: June 11th, 2006, 8:13 pm
Location: canada

Re: [interface] Solve the "accidental confirm" problem

Post by tr0ll » January 31st, 2012, 4:48 pm

1) An option could be added so that anytime a player makes a choice in a dialogue the game is auto-saved just before.
This would also make it easier to try different paths without restarting scenarios, especially where the encounters are not at fixed turn numbers but dependent on game conditions.

2) Is the keyboard and mouse event queue cleared when a dialogue pops up?

User avatar
shadowm
Site Administrator
Posts: 6575
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by shadowm » January 31st, 2012, 7:39 pm

tr0ll wrote:1) An option could be added so that anytime a player makes a choice in a dialogue the game is auto-saved just before.
This doesn’t seem like a good idea either, because the dialog could trigger at any moment in the middle or at the end of an event handler, or during the execution of multiple event handlers for potentially different events.

You could “read ahead” and determine whether the event could possibly trigger a message action with one or more .option or .text_input children, but that would involve running code in if-then-else paths which could depend on previous actions in the same event altering the state of the game. The possibilities are endless. Then there’s dynamic WML (think [insert_tag]).
tr0ll wrote:2) Is the keyboard and mouse event queue cleared when a dialogue pops up?
I think this is the case for any dialog call; however, as far as I understand, the problem the OP wants to address is the user accidentally clicking immediately after the WML message dialog has appeared before he or she has time to notice it (something that happens to me rather often, too).
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

User avatar
tr0ll
Posts: 522
Joined: June 11th, 2006, 8:13 pm
Location: canada

Re: [interface] Solve the "accidental confirm" problem

Post by tr0ll » January 31st, 2012, 9:00 pm

in that case i like the 250ms activation delay too, but if possible dont hardcode the number because people have different reaction times and may need to customize

User avatar
Boldek
Posts: 576
Joined: April 14th, 2011, 6:37 pm

Re: [interface] Solve the "accidental confirm" problem

Post by Boldek » February 3rd, 2012, 2:08 am

Well, the delay might irk some people like me who skip dialogue occaisionally, so how about an option saying 'delay message' or something on the preferences? That way the hasty kids(me) can burn through the chat, and the others who haven't played a campagin before can activate this?
Guys I never thought I'd come back to this forum after 8 years this is wild

gnombat
Posts: 239
Joined: June 10th, 2010, 8:49 pm
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by gnombat » February 3rd, 2012, 3:35 pm

Boldek wrote:Well, the delay might irk some people like me who skip dialogue occaisionally, so how about an option saying 'delay message' or something on the preferences? That way the hasty kids(me) can burn through the chat, and the others who haven't played a campagin before can activate this?
It seems to me the delay is really needed only when a dialog pops up while the user is moving his units. The optimal behavior might be to have a delay in that situation, but not have a delay when a dialog pops up immediately after another dialog. (So that in a long conversation, only the first dialog box would have the delay; the second and remaining dialogs would not.)

User avatar
shadowm
Site Administrator
Posts: 6575
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by shadowm » February 3rd, 2012, 6:46 pm

Boldek wrote:Well, the delay might irk some people like me who skip dialogue occaisionally, so how about an option saying 'delay message' or something on the preferences?
You can currently press Escape to skip all input-less [message] actions during an event handler sequence.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

User avatar
PeterPorty
Translator
Posts: 310
Joined: January 12th, 2010, 2:25 am
Location: Chair, In-Front-Of-Computer

Re: [interface] Solve the "accidental confirm" problem

Post by PeterPorty » February 3rd, 2012, 8:49 pm

I would *love* there to be a delay on messages.... hell, even a 1 second delay; that way, it doesn't close if it appears while you're mouse-wheel-scrolling and stuff....
"The real world is for people who can't imagine anything better."

MiSu2410
Posts: 5
Joined: January 2nd, 2012, 9:12 pm
Location: Leipzig, Germany

Re: [interface] Solve the "accidental confirm" problem

Post by MiSu2410 » February 4th, 2012, 1:23 pm

I second the idea of having a delay in there. As I am playing a lot of campaigns still, mostly for the story, I hate it when I miss part of it due to me clicking too fast...

User avatar
Sapient
Inactive Developer
Posts: 4453
Joined: November 26th, 2005, 7:41 am
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by Sapient » February 8th, 2012, 4:16 am

shadowmaster wrote: I believe there originally was a restriction set in the implementation of the message action to not let the user dismiss the pop-up dialog before a few milliseconds passed, or there were intentions to implement this.
Yes, I coded the original feature and added a duration= attribute to [message] so that it could be customized as the campaign author saw fit. Or, assuming the feature hasn't been removed (it's still documented in the WML reference) one could override the duration= of all [message] tags by modifying the handler in wml-tags.lua

Ideally what we need though is a history of recent messages and a way to get at them. It is quite conceivable that such a thing could be done, and I can think of a number of ways of doing it (some easier than others). If I get back into the code anytime soon I may take up such a project, assuming no one else has done it by then. And yes this feature has been requested many times; it is BWH.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."

gnombat
Posts: 239
Joined: June 10th, 2010, 8:49 pm
Contact:

Re: [interface] Solve the "accidental confirm" problem

Post by gnombat » February 8th, 2012, 4:25 pm

Sapient wrote:Yes, I coded the original feature and added a duration= attribute to [message] so that it could be customized as the campaign author saw fit. Or, assuming the feature hasn't been removed (it's still documented in the WML reference) one could override the duration= of all [message] tags by modifying the handler in wml-tags.lua
This is what it says in the wiki:
duration: (default: 10) the minimum number of frames for this message to be displayed. (A frame lasts about 30 milliseconds.) During this time any dialog decisions will be disregarded.
To clarify: according to the report in the bug tracker that shadowmaster pointed out (#18483 [Gna.org]), this WML attribute doesn't currently work. (Note also that it says "default: 10" but as far as I can tell that isn't working either. :cry: )
Sapient wrote:Ideally what we need though is a history of recent messages and a way to get at them. It is quite conceivable that such a thing could be done, and I can think of a number of ways of doing it (some easier than others). If I get back into the code anytime soon I may take up such a project, assuming no one else has done it by then.
:D

Post Reply