I was just editing a sample module for building decks automatically and stumbled onto an odd behavior. It seems GKC’s don’t work on pieces that are in a deck that doesn’t contain any pieces when the module starts. The GKC works fine on those pieces any other time. Move them out of the empty deck and it works fine.
Bug or designed that way?
I’m going to try a work around of putting a dummy piece in the empty decks and deleting the piece when deck building is activated.
The GKC will not work on deck contents that are face down. If you set the deck as face up, then it will work.
I’ve attached the small mod I was working with. I added a test deck to the main board that’s below the the initial decks. It’s got an outline when empty. If you click the draw 6 button, it will put 6 cards from a deck on the cards map into the play deck. The discard button is a GKC and every card is prototyped to return to the discard pile on the same keystroke, no property match. The decks on the cards map go to the discard pile, any face down in the play deck don’t. If you use the other test deck, you can flip cards face up with a right click. If those cards started face up, they’ll respond to the GKC, otherwise they won’t even if flipped face up after being face down.
Is an instance where a deck GKC is needed? If so there is a problem with that as there is no way to tie the deck GKC in with a key stroke. It can only be activated via rightclick menu. The documentation mentions a key command along with the global command, but there is no field to enter it in the dialog.
The GKC is firing at the pieces though. It shouldn’t make any difference which deck the are currently in or even if they are in a deck. In my particular case, I was toying around with a discard GKC that put all cards into a single discard pile, including ones that hadn’t been drawn from the draw pile. It works except for the ones in the draw pile which are face down. It stemmed from working earlier on a way to have a stack shuffle and then ignore further shuffles by setting a DP on the cards that are shuffled.
I can get around the last part okay with another interim deck that is always face up when the shuffle takes place and then move the deck to the draw pile. It just looked like it might be a bug as I expected a GKC to affect all pieces in a deck whether they are face up or down.
I presume when you fire the GKC at the cards in the deck it executes a STL
or RTD trait or somesuch.
Thing of importance - where are these traits that get executed - above or
below the Mask in the trait stack?
If they are above it will not work when the cards are face down, the trait
must be after the mask to work on face down cards. That may be why you see
it working only when they are face up
Try moving your Dynamic Property ‘status’ down below the Mask trait. When cards are face-down in a deck, they are Masked to everyone and the Mask trait ‘hides’ properties within Decorators inside (i.e. above it in the list).
Alternatively, change the way you determine which cards are ‘ready’. In general, I find manipulating Dynamic Properties tends to be clumsy and difficuly to debug (though certainly possible). I like to use Zone or Deck names, so if card are only drawn from the ‘Play’ deck, then use ‘DeckName=Play’ as the Property Expression.
After I saw your response, I had one of those ‘well duh’ moments. I just completely forgot about the mask property and the ordering of traits. I usually catch those, but I was throwing this together kind of quick as an example for another thread.
Interesting about the DeckName property, I had tried to use that before but with no success. I note that you capatilize the ‘D’ whereas the documentation and indeed the message format use the lower case ‘d’. I’ll give that a try sometime.
Property Match Expressions and Report Formats are two completely different animals.
Property Match Expressions work on the property names as defined in the Properties page of the latest Reference Manual. DeckName is the property that every counter has that has the name of the Current Deck (or blank) it is in.
The variables available for inclusion in Report Formats in the Drop-down lists are not counter properties, they only have existence within the Report Format, such as deckName is the Deck Report Formats. You will not find any reference to ‘deckName’ anywhere else in Vassal, and it is not valid to use it anywhere else except for these specific Report Formats.
It is unfortunate that in some cases the two use similiar, but different names (e.g. DeckName vs. deckName). This is a historical artifact and I plan to sort out the discrepancies in a future release (3.2 perhaps). It is covered by RFE 1912215.
Wow! That posting solves a problem I’ve had from the beginning. The documentation on the main page for Vassal Engine FAQs - Creating Vassal Modules, under the topic of “What ‘system’ properties are returned by counters?”, it states the system name to use to call a Deck is
I’ve never gotten this to work …but I thought it was my own ignorance of how things worked that was the problem. So, I’ve been putting decks in Zones and just pointing towards the zones.