Also interested, as try as I might, I cannot get chat log updates before the end of a composite action, no matter what the duration of a Sleep().
I’ll see what I can do.
I have applied the Sleep(0) in two different processes, and I see your point about perceived speed as opposed to actual speed of execution. But in one of the procedures, where I just move two counters (clock hands on a clock, nothing is written to the chat window, but the speed increase is so great that you hardly notice a delay when Speed(0) is present.
I have built further upon this early success, and lost a little bit of the speed increase, but I’ll see if I can revert the changes and measure the speed difference with and without the Speed(0) command.
The actual code is spread over GKCs and a hidden counter, so I don¨t know how to show it here.
I have a personal theory that the speed increase comes from GKC’s that look for a single counter, and that the Speed(0) command makes it stop after finding this counter, instead of uselessly search for more.
Try not putting it at the end, but rather in the middle.
The theory is busted, and Sleep(0) does not increase speed. Brent is right, it is a psychological effect of seeing progress happen, instead of waiting for it to end. And there was in fact a message in the chat window that I had forgotten about.
Removing all Sleep(0) did not increase execution speed when timed with a stopwatch.
@marktb1961: you can take a look at my code if that helps. The module with the cache refreshes is still unpublished, but I expect to be able to upload it in about a week’s time. Or you can get a beta directly from me.
I’ve been pressing on with this a little more recently. One the plus side, I find I can get visual feedback that an action is underway.
Some other aspects of my recent experience…
The technique needs care and is only effective if the display state alters to some sensible form early in the action.
By displaying an altered state early on, you might get an unwanted side effect on the user’s behaviour. The example that I encountered is in a case where a left-click (Action Button) displays a marker, the placement of which incurs a significant (~2 seconds) delay. A sleep removes the delay but the user (me) then naturally moves on to click on another piece. Of course, in reality Vassal is still processing that action and now - once it catches up - seems prone to interpret the user’s mouse action as a drag/drop. I think that I’ve been able to curtail this by adding a DeSelect trait into the action.
I’m also wondering about whether the sleep/refresh is a local effect or whether the display state gets synchronised out to other parties in an online game. I suspect it will be the former, which means that excessive use degrade performance with no perceived benefit. Perhaps @Brent_Easton can shed some light on this question.
My comments are in the other thread.