[interface] Solve the "accidental confirm" problem

[gnombat]

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-dialog.png (8.95 KiB) Viewed 4034 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?

[Iris]

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

[tr0ll]

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?

[Iris]

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]).

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

[tr0ll]

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

[Boldek]

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?

[gnombat]

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

[Iris]

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.

[PeterPorty]

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

[MiSu2410]

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

[Sapient]

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.

[gnombat]

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

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.