If I set a counter to invisible before dragging it onto the board, my “Report Action” will never report so long as the piece is invisible. If I remove invisibility once the piece is on the board, reporting works again…even after setting it back to invisible again.
If I drag the piece onto the board before setting to invisible “Report Action” works fine and continues to work even after set to invisible.
Does this happen with 3.7.4?
Yes, unfortunately, it does. Apologies for not seeing the update prior to posting.
What is the newest version where the problem does not occur?
The behavior is still present as far back as 3.6.19, which is as far back as I can go.
I can confirm the same issue is present on Vassal 3.5.3.
Thanks for checking. The problem is likely quite old in this case.
No problem, and thank you for your attention on this. Please let me know if there is something I can do to facilitate.
Could be somewhat tricky to fix without breaking things
There is code in ReportState(143:171) that claims to the following:
// Only make a report if:
// 1. It's not part of a global command with Single Reporting on
// 2. The piece is visible to all players either before or after the trait
// command was executed.```
It is aimed at the execution of trait by KeyComanns or menu selection, but it is inconsistent if it is just a ReportState being fired off by a Map end movement KeyCommand as the PieceMover does not update the piece in the same way as the execution of a trait does,
If the code was working the way it was intended, Invisible pieces would NOT fire a Report Action on movement ever.
Have to think about this.
Thank you for the detailed explanation. I’d like to share my use-case to illuminate the situation.
Games without hidden movement enforce rules by allowing players to audit the actions taken by the other player by simply witnessing play. Hidden movement games add the problem that this audit function is absent and cheating or errors are un-mitigated.
I am working on a game with hidden movement. Such games tend to either require a high degree of trust between players, which is often not achievable, or the addition of a referee, making game initiation and execution much more difficult and unlikely. (Also, the game would have to be designed from the ground-up to support the role of “ref”.)
I need a reliable report trigger to mitigate the risk of errors or cheating, by allowing a chat message alerting an opponent of a potentially illegal move. Without this mechanism, I am forced to either have zero mitigation or go to extreme lengths to try to mitigate illegal moves in other ways like triggering swapping out of immobilized pieces by phase trigger, etc. This is a much “harder” approach that the VASSAL documentation advises against (correctly in my opinion).
I would much rather have this softer mitigation of a trigger that I can attach chat messages with.
Help me Obi-wan, you’re my only hope.
Incidentally, it would still work for me if you made it so that the trigger fires when “outside” of the invisibility trait but not when under the Invisibility trait in the trait ordering…like most things.
This would allow the designer to choose to hide the report from the opponent when invisible if desired or not hide the report when invisible if desired.
In my mind this would be win-win.
Just getting back to the initial problem, can you state simply, exactly which aspect of the current behaviour is causing you problems and how you need it to perform? I might have a work around for you, but I want to make sure we are talking about the same thing.
Sure thing…
In my project I have items which one side can hide from the opponent. Once the initial setup is done, those items should not move…except in certain specific ways and only specific types can do so.
So to protect the player who can’t see the hidden pieces from cheating/errors I trigger a message when these hidden pieces move to alert the player who can’t see them that they are being messed with. This is a significant mitigation to cheating/errors.
Unfortunately, if the hidden piece is made invisible in the counter palette, before dragging it onto the board, then the “Report Action” trait NEVER fires…regardless of if the trait is “outside” of invisibility or not. Whereas it always does fire if the piece is dragged onto the board before being made invisible and will continue to fire after being made invisible no matter where it is in the trait-order relative to invisibility.
The mechanism for firing the trait is the auto-application of a command after any piece is moved on this board in the board properties.
The player will often make pieces invisible before dragging them onto the board so that the opponent doesn’t get a glimpse of the piece when it is created…subverting the mechanism that I am trying to use to mitigate cheating/errors.
Just a quick update on this…I’ve been trying to engineer a workaround for this. I tried changing the way the pieces operate to allow all of the pieces to be put on the board so that none of them needed to be dragged by the player onto the board. This would avoid the circumstance where the player would make the piece invisible before dragging. So, after doing all that, it turns out that changing any other trait that affects the image of the piece after it has been made invisible, essentially “turns off” all “Report Actions”.
Finally, the mechanism for triggering the “Report Action” trait that fails is not limited to the auto-application of a command on the map properties, it also affects any keystrokes/commands applied directly to the piece.
Did this make it onto the agenda for the next update? I don’t see it on the issues list on GitHub.
It’s on the agenda, it’s just a really difficult problem that has always existed and has no obvious solution that won’t cause more problems for other unrelated modules.
The current design of Report Action is to NOT make a report for fully invisible pieces unless the are going invisible or becoming visible.
The fact that moving invisible pieces currently generates a report is actually a bug in the current design.
I suspect we will need a compatibility option to turn on new behavior, I’m not sure yet what that new behavior should look like
Thanks very much for the additional detail and for your attention on this.