Progress Marker stalled ?

I think I saw this long-standing request mentioned again recently but can’t find the thread. +1 here in support. I wonder if the activity on 3.3+ might include this request? Meanwhile, I think the only way for a user to tell that an action is in progress is to try doing something else in the module. Clicking on the chat input box seems the safest.

A couple of things aggravate the requirement. Firstly, action button-clicking seems to be an inexact science - even when the action button has a been accurately defined (a challenge in itself), so often (I find) a button press does not get actioned until a second or even third click. Secondly, Vassal performs an entire operation end to end before any feedback is possible. So, for example, once a trigger is activated, everything in that trigger must complete before any output is produced. So there is no way for a module to provide even a starting message (it will appear, but only at the end). Except, of course, to break the automation down into chunks, each of which would require further user action to proceed.

One final possibility is to use Alert() in the trigger, but that will hold up the entire operation until the user acknowledges the Alert (which may be covered by other windows in the module).

I’d be happy to learn if I’ve misunderstood any of the above.

I believe the problem with action button-clicking is due to the bug in the click-and-drag behavior (if you move the mouse even a fraction between button-down and button-release, VASSAL thinks you’re starting a drag instead of a click), and I think the fix for that is due for 3.3.3…

I found a way to provide feedback that said action is in progress; the “Play Sound” trait. The sound will be played before the actions are completed.

I think one needs to play the sound early on in the action sequence and before anything time-consuming starts.

Presumably this is all to do with how Vassal implements its UnDo capability; whilst the overall set of actions is buffered up, the Sound is actioned immediately, as it is not required for the UnDo.

Side note: I have found it does not work to have a Play Sound trait associated to individual actions within the complex set - of actions. For example when dealing cards; the sound for each dealt card is heard long before the actual card dealing actions are seen or reported and, once the action-set has completed, any sounds still to be issued will be dramatically compressed. Perhaps this depends on how the set of actions are tied together - ie sequenced in a Trigger definition or independently using a common Key Command.