scope of numPieces

Can I access the value of numPieces from another window?

according to: … ounters.3F
_numPieces is a map-level property, but if I use the “expression builder” (I mean the “insert” button next to the green checkmark/red cross) I can find it in:

Property->Global property->Map Window Decks->Deck myDeck->myDeck_numPieces

But it seems I cannot access it from any other place than the map the deck is located in.

Yes numPieces is a map level property. Only pieces on that map can see it. It does not exist for any piece not on that map. I have no idea why someone would decide to do it that way, but they did so we’re stuck with it. You need it to be a true Global Property, as do many if not most applications for numPieces. I only know of two workarounds:

  1. Create a “dummy” piece (I suppose you could also use a “real” piece if it never leaves that map) that has no image and cannot be selected. Use it as a container to store the numPieces value as a Calculated Property. Then either update a Global Property each time that Calculdated Property changes or send all your GKCs that require numPieces through that piece.

  2. Create your own Global Property that counts numPieces manually. Basically, increment 1 or -1 every time a card enters or exits that deck’s location. You can do this with property matches for LocationName and Markers that trigger every time you have map movement.

I opted for #2 because #1 really seemed like a kluge.

thanks for the quick reply.

With a quick search I found this post:

but I cannot make head or tails of it.

Edit: Also, can I see the module where you did that? it sure would help me if i can see a working example.

That thread is ancient and no longer relevant to Vassal 3.2.x or 3.3.x.

Maybe this thread will help from when I was a Vassal newb, all of two months ago ;-)

As with so much of Vassal, it wasn’t a decision that was made at a specific point in time by someone. Vassal has grown organically over years, with features being added with little idea of how creative users would end up using them. The different levels of Global Variables where added at different times without an over-arching design philosophy.

No, we are not stuck with it. What can we do? It is too late to impose some sort of hierarchical naming convention to access remote properties, but we can add more Beanshell functions to access them.

I will address your concerns about the GetProperty function in another thread, but I would propose we add the following:

getZoneProperty(propertyName, zoneName) - Get the value of Zone level property propertyName in zone zoneName on the current map
getZoneProperty(propertyName, zoneName, mapName) - Get the value of Zone level property propertyName in zone zoneName on the map mapName.
getMapProperty(propertyName, mapName) - Get the value of the Map level property propertyName from the map mapName.

Thanks a lot! I’m on the right track.

I have created a GP “DrawnCards”, and placed a ‘endMove’ KC to send to units ending movement on every map and player hand.

The prototype for cards includes a Set Global Property that triggers with ‘endMove’ and increments numeric value of DrawnCards with {oldZone==DeckZone?1:0}

DeckZone is a Zone defined just around the Draw Deck.

The decks window includes DrawDeck and DiscardDeck. This map has a different KC for units moving here, ‘endInDecksMap’. This KC works a little differently, and sets value of GP directly to {100-DrawDeck_numPieces}, 100 is the number of cards in the game.

This works mostly.

But I have trouble when shuffling the discard deck. Apparently, ‘send entire deck to other deck’ doesn’t trigger the ‘endMove’ KC.

I have disabled shuffling through RB-menu and placed a button that sends a GKC to all cards in the discard pile. That GKC sends them to the Draw Deck and I’m using it also to trigger the SGP trait of those cards, so the global property is always updated.

Even if this works, I wonder if there’s another solution. I don’t like forcing ways to do things, and would like to be able to shuffle using the contextual menu.

Thanks again.