When counting pieces populating a Zone {(CountZone(“Retreated”,“French Losses”))/(5)} I encountered a strange behavior.
Moving a piece by key command to a different map is NOT recognized by the counting function.
Moving a piece by key command to a different zone on the same map Is recognized by the counting function.
Dragging a piece to a different map also IS recognized by the counting function.
Bug or wrong syntax?
Thx
Matthias
It’s difficult to advise as you haven’t outlined which piece has the countZone() function,. how the result is being displayed or whether the moving piece is a counted piece or the displaying piece.
Regardless, first thing to check is if this is a delayed refresh issue. After moving the piece, click on the piece that is displaying the count and force it to refresh. i.e. A piece that displays a label that is computed doesn’t automatically ‘know’ that the underlying conditions have changed and that it needs to re-display it’s label. I suspect this is your issue and is actually something we are discussing in another thread.
If this is not the case, then please supply more information so we can look into it.
Many thanks for the quick reply, Brent.
You find the prototype of the piece (as xml) here:
The refresh is as of now done is by hand (Global Hotkey). No label so far involved.
This hotkey is changing the value of the global property, which works fine in other parts of the module. I made two change property buttons for this GP for this purpose, one to look (prompt user), one to change (set value directly):
{(CountZone(“Eliminated_Fr”,“French Losses”))+(CountZone(“Recovered_Fr”,“French Losses”))+(CountZone(“Unrecovered_Fr”,“French Losses”))}
Need the module or screenshots?
Yes please, need the module, plus a log file that shows the issue happening. Regards.
Here the link:
Sorry, I don’t know your module and I can’t follow what is going on, I have no idea where the pieces are going or where you are getting the information from you are relating in the log.
Rather than inferring the the correctness (or not) of the CountZone function based on whether or not some GHK does something or not, can you instead create some dummy counters with a text label that displays the text {"French Losses=" + CountZone(“Retreated”,“French Losses”)} and sprinkle these around so we can see what is happening directly as you manipulate the counters. Always go to the source.
Sometimes, it’s actually an issue in some other part of the automation that is the cause.
Regards.
Don’t worry.
It should take me 10 minutes to make up a tiny test module, which I will send, should it show the same problem.
Thx.
Matthias
Here is a link to a 50 KB testmod sporting four counters plus a log file showing evidence for the strange behavior:
if sent → location 1, then → location 2, only location 1 is properly counted.
Thx.
Matthias
Your approach here looks overly complicated. You don’t need to store values in Global Properties and update them with Global Hotkeys and all that stuff. The pieces showing the counts can do the counting directly in the label text as noted above. Or at worst in a Dynamic Property that gets updated every time the relevant pieces move, then display that DP.
I won’t have time until tonight to go into details but you could streamline what you’re doing significantly and have it work fine.
Yes, trying to catch every single Key Command that moves pieces into and out of a zone to maintain a separate count is bound to end in tears.
I just changed the label display in your click-to-count pieces from $PiecesInZoneAB$ to {CountZone("ZoneA","Main Map")+CountZone("ZoneB","Main Map")} (and equivalent for the other one) and the counts work fine, showing CountZone is working correctly.
The issue is in your complex mechanism for trying to track the totals not firing off at the appropriate times.I 'm not saying there isn’t a bug in some other aspect of Vassal, but the problem is not in CountZone.
Regards.
One reason for using GPs is that the displaying pieces are not meant to move ever. For another, calculated GPs are necessary.
Thx anyway
Matthias
Whether they are meant to move or not isn’t relevant to the soundness of your approach. You don’t need Global Properties at all to accomplish what you seek to do!