Several GPIWs that were previously working are now non-functional as of version 3.6.1. Same module that I just reported another issue.
GPIW in 3.6.1 or later
Same exact GPIW in 3.6.0 or prior
That’s actually due to a security bug that was fixed…the GPIW window should not be able to show other players pieces that are normally hidden from them (e.g., on a private window).
Yeah I saw that in the bug fixes for 3.6.1. That is indeed the reason it stopped working. Unfortunately, that bug fix completely breaks my module. I’ll need to figure out a way to assign ownership to every player yet hide that window from them.
Oh wow, that is an awful “fix”.
Inventory windows to give players information on private windows that they can’t interact with was the main use of GPIW for me.
1 Like
Agreed. It was the only workaround available to me because the features in 3.3 and 3.4 were so limited. I suspect some of the newer features obviate the need for all the tricks I devised, but I was unaware that aspect of the GPIW was considered a bug…
I suspect that change wasn’t thought through thoroughly. I suggest posting in Feature Requests and asking for an option to enable the old behavior, because I can’t think of an easy way to fix those GPIWs, otherwise.
I found a workaround. For the Private Window: check “Visible to all players” and “Include toolbar button to show/hide”, leave the Button text and Tooltip Text blank, then select a Button Icon and click “Cancel”, you’ll end up with an invisible menu button. It’s a tiny annoying little square (below) prior to the GPIW “fix”, but completely invisible from 3.6.1 onwards…
1 Like
So let me make sure I understand what people are asking for here:
If there’s an Inventory, and there are private windows / private hands, you’re saying your modules depend on the Inventory being able to show what those pieces are to players who don’t have access to the windows/hands? And so anybody can just pop a “default Inventory item” into any module and see everything that’s in everyone’s hand?
If your “private” windows aren’t actually intended to be private, then it seems to me the better way forward would be to at least allow visibility to them (as in m3tan’s workaround for example), and use the Mask trait or Invisible trait for pieces that are truly not supposed to be seen by others?
That is correct, yes.
The idea of trying to prevent cheating by modification of the module is absurd. You will never close all the avenues of attack there. It’s still trivial to add yourself to the list of allowed players for a private window, for example.
There are already at least a few, maybe a lot, of modules that make use of the known GPIW function, and there can’t be any that make use of the new GPIW “unknown piece” function.
So this is a “fix” that merely breaks modules.
To restate: a window that no players, or a limited subset of players, have access to, but can be “viewed” by a GPIW, is an effective way to prevent players from modifying the window contents and/or display the contents in a specific order or list. This is good, and useful.
I’m fine with the new behavior going forward - and it probably makes more sense. The problem is I’ve built a massive module based on architectural limitations of Vassal 3.4. At that time, GKCs and counting matching properties weren’t truly global and I had to come up with all sorts of shenanigans to make them work like they should. One workaround was creating a private window that was hidden to all players, but viewable by various GPIW filters. With GKCs now working as intended, I would never use private windows that way again, but since it is working as-is, I don’t want to rewrite the whole module. I found a workaround for 3.6 so this is all a non-issue for me now. But if Benkyo has a similar issue and there is no workaround, I understand why he would be frustrated…
Good to know. I’m not the team member for “balancing security with other things”, just gathering information–we’ll need to discuss among Joel and/or Brent
Ben can you articulate a specific use case that requires the insecure behavior (particularly one that cannot be worked around through other means)?
The one that I will have to fix using the workaround is viewing X cards from a deck. I have a trigger that sent the cards to X coords on a private window and opened a GPIW to view them, and another trigger to send them back. GPIW can’t view masked cards, so this is my clunky workaround. (I would actually prefer GPIW to be able to show masked pieces!)
The one I can’t see a workaround for is similar: a player’s hand is private to all but the player, because those players can’t touch those pieces or know how they are arranged in the hand, but they can view the pieces in a GPIW sorted list of images. In physical boardgame terms, this mostly applies to hidden trackable info - everyone has seen those pieces taken from a common market, but they don’t know how they are being used behind a screen.
Another is a mixed GPIW with all the pieces from a player’s “deck” (which is actually a face up private market) and private hand, when discards are public. The other players know what cards the player potentially has, but not actually what’s in hand among those.
I recall how this change got started (blame me); I reported that the introduction of GPIW zoom capability was allowing an existing module to display card details that the module assumed would not be visible because of the micro-magnification level specified in the GPIW. I wasn’t concerned at the time about the piece names themselves.
In fact, there are other ways for a flawed module to accidentally reveal hidden information (in reporting), so I think you can rely on module developers not to reveal that information in a GPIW. The images were a different matter, I felt.
On the other hand, creating a GPIW is trivial and displaying property values there requires minimal knowledge. From that viewpoint, it would be good, I think if properties could be kept private in a GPIW when the item is masked.
If arguments for a lax GPIW prevail, then I think at least the zoom ability should have to be explicitly enabled in Global Options to protect legacy modules.
I think it would be far easier for the module (singular?) that weirdly added images at 0.00001 zoom for no reason to uncheck the image display box than it would be for all the modules that rely on being able to use GPIWs for private windows without the GPIW announcing they are on private windows to work around that newly-introduced problem.
In order to make any further progress on this problem, I need a module from everyone that I can test and instructions for what you’re intending me to see when it works correctly.
I don’t have an ideal test module on me right now, but one would be very simple to set up if I had any spare time to do so:
private window
public map
pieces on both
GPIW listing all pieces by images + name
The GPIW should not declare which pieces are on the private window by calling them all “unknown piece” - it should be possible to have it unknown from the GPIW alone which map the pieces are on.
It doesn’t have to be a test module made specifically for this. I just need some module I can test. I assumed given your objection to the change that you would already have one.
My example demonstrates a legacy issue affecting image zooming. I was never concerned about revealing of property information and at the moment I don’t feel strongly either way.
I’m referring to Commands & Colors: Napoleonics, v3.42 and earlier versions. (I am not defending the configuration, just flagging up that it exists in a still popular legacy module).
The module has private hands; by default cards are face up in those hands.
The module allows users to check how many cards are in each hand, using an “In Hands” button on the toolbar 
.
Here is what the GPIW behind the button looks like in the current version of Vassal:
This old module draws piece images at an illegibly low zoom factor. The issue is that Vassal 3.6 has dropped in two additional zoom levels which the GPIW window will invite users to access from its new -/+ buttons. The current “fix” prevents abuse of this, at least for those players who don’t have access to the hand.
How the designer intended:
What unfixed Vassal v3.6 was allowing because of the defaults added into the module:
You can simulate this in Vassal v3.6.4 by starting a scenario as Solitaire and drawing cards to both Allies & French hands. Pull up the “In Hands” window, press the “+” button; this is what any player would see in unfixed v3.6. Then switch to French or Allies to see what the effect of the fix is as at v3.6.4.
In place of the current fix, I suggested above that a module editor-only Global Options setting might be used to curtail the zoom functionality (off by default). Perhaps a better way would be to simply not populate the closer and closest zoom factor fields when the editor or player reads in an existing module. In the player, the GPIW +/- buttons would be disabled if there was only one zoom option and otherwise ignore a blank zoom field. When the editor creates a GPIW afresh, then it could continue to pre-populate defaults as in v3.6.4.
Oath was affected by the update, but has various GPIW that are only accessible through right click menus on specific cards buried in decks that I assume you aren’t interested in hunting for.
(The affected cards I can remember are Scryer, Tavern Songs, and Oracular Pig)
The functionality I want to preserve is primarily for a future version of Mage Knight, and for future projects. Mage Knight currently uses “folder view only” so I don’t think it was affected by the update.
I’ve been trying to the the Oracular Pig card to work with no success. I don’t know what I’m supposed to be seeing.