Sometime late in 3.4.x I noticed that windows were not refreshing when an automated action changed the state of that window - typically when a card was moved to or from that window using “Send to Location”. The window updates only when that window is clicked on. Even closing and re-opening the window makes no difference if the window is not clicked in.
At first I thought it was something to do with the module I was working on but recently another user mentioned this issue in one of the Vassal forums. Then I was playing a well-established module - Churchill v.1.13 - and all 3 of the players were noticing the issue.
I re-tested under v3.5.0 and still see the issue.
Is this something normal that I just haven’t noticed before or a bug that crept in during v3.4.x development ?
I don’t have a specific example, because, as far as I can tell, it always happens for me. Running any version of VASSAL since 3.3 (never tried older versions) on Kubuntu 20.10 (with the latest Java 11 from the default repositories), if a card window is already open and an STL moves a card to or from that window, it won’t refresh until I click on it. My friends running Windows do not have the same problem, so it seems to be something specific to Linux, in my case.
I can easily reproduce it in the Terraforming Mars module by having the Research window open and starting a new Generation with automatic dealing enabled–the Research window will receive 4 new cards, but will remain blank until I click on it.
Minor correction: if the STL was triggered by an action I initiated on that card (from its right-click menu), the window it leaves and the window it moves to do get refreshed properly. It’s only when the STL was triggered by another piece (from a GKC) that the windows don’t refresh.
I tried in a solo session using Churchill and failed to reproduce it, so I am not encouraged. I wonder if it is something to do with online play but it happens in response to one’s own actions… i.e. I have the hand window on screen, I do the action to move a card to that hand and don’t see the hand window update, I click on the hand window and it then shows the card.
I can now reproduce this error without being connected to an online game. As may have been said, the error seems to be annulled during logfile replay, so I need to provide step by step instructions. The example that I have is a simple case of moving a card from a hand window (manual or send to location) and using a “Send to Location” trait to return a card back to the hand window that it came from. Note - this is a fresh STL trait, not the return function within the original STL trait). I am still working through this example because the error seems to depend on something else in my module (original move-to location dependent).
Observations / suspicions so far :-
Is it Hand Window related only? I’ve only seen this occur in hand windows (not sure about the Churchill example, would need to check the type of window that is using. I suspect it is hand window).
Open the hand window after performing the move into hand action, the hand window is always up to date
Does it depend on whether or not there is some form of processing down once the piece moves to the hand window? I am trying to find an explanation as to why I see the error when the card is STL’d back to hand from one location in my module and yet not from the other.
A blank map is displayed with one piece at the bottom (ignore this for now, it has control logic on board)
A window should also display with two piles of counters - if not, press the “test window” button on the main toolbar.
Now for the fun… move some counters from the piles to the main window. leave at least one counter in each pile (for now).
press the “refill piles” button that is in the toolbar for the test window. do not move the cursor anywhere.
observe that nothing happens
click on the main screen - still nothing ?
click on the test window inside area… the stacks refill now shows up?
now try again but this time completely empty one stack… hey presto, the empty stack immediately fills up.
This last point is relevant. I think it explains why not everyone will see this issue…if it only affects automated landings on stacks with counters already present. Whereas people that use Player Hands to manage cards will see the issue for any automated draw-to-hand operations into an existing “row” of cards (which is really a stack).
This module is maybe not as cut down as it could be; it comprises
GKC “refill piles” button
sends to “Turn Counter” which does a Place Marker for up to 6 counters per pile in the French Hand.
Each counter, on being created, then does a Send to Location to arrive on the correct pile in the French Hand.
@Cattlesquat
PS When you do the move of counters and press the refill piles button - try an UnDo. That doesn’t seem too healthy either - counters disappear rather than action being properly undo.
UPDATE: The UnDo is causing the main window to shift. The counters are still present after all. A different issue, I guess.
Works for me in the test case and also in a real module where a card is actioned to “Send to Location” from its current window to another active window.