Perceived Problems with Set Global Property, VASSAL 3.4.12

It seems to me that in VASSAL 3.4.12 the Set Global Property trait doesn’t interpret expressions as explained in the documentation. It could be that I am not properly understanding the documentation.

Every time I have tried using an expression for the Global Property Name rather than the exact name letter for letter, I get an error message that the Global Property was not found. Also, whenever I have tried to use an expression such as, {mapName}, {previousMap}, or $previousMap$ rather than either the actual typed out name of a valid map with the Global Property or the Current Zone/Current Map/Module preset choice for the place to Locate Property starting in the: field, I get the same error message that the Global Property was not found.

I’m working on a module for an economic game for up to 8 players and 20 companies, each with their own map to hold their assets. The players buy and sell stock in these companies as well as the player having the most shares in the company runs it. I’m trying to adapt the trick of keeping count of the sum of a value assigned to various pieces in a zone: (referred to later as “the trick”) to doing a similar kind of thing with the stock certificates. Since my module will have lots of maps, I am trying to use the $previousMap$ and $mapName$ properties rather than explicitly name the map in the Set Global Property trait. I am also using a map level Global Property like BSCShares for a company that might be named Big Shoe Company.

I set up a prototype for one of the companies (I would do the others after having success with one) with a Marker named Company for the company abbreviation used as the first few characters of the Global Property to keep track of how many shares of that company was on that map. I also set up a prototype for the stock certificates that had a Trigger Action trait similar to the trick and Set Global Property traits also similar to the trick, and a marker indicating how many shares were represented by the certificate. I then set up another prototype for a particular company’s stock certificates which had prototype traits of the previously mentioned two prototypes with the one having the Company marker last.

As stated above, when the Set Global Property had an expression, {Company}Shares, for the Global Property to set, it didn’t work. I don’t recall whether or not I got an error message. After changing the expression to the actual name of the Global Property and moving the Trigger Action and Set Global Property traits to the company prototype and switching the order of the prototypes in the company’s stock certificates prototype, I got partial success for incrementing the count of shares in the map to which I moved the certificate as I had used the Current Zone/Current Map/Module preset choice for the place to Locate Property starting in the: field rather than Named Map with the expression {mapName}, but I still got an error message that the Global Property for the share count was not found in the {previousMap} nor the $previousMap$ when I tried that. When I changed the expression for the previous map to the actual name of the map from which I was dragging the certificate, I didn’t get any error message. Unfortunately I had not set up a label text to report the remaining number of shares in that map.

Also, in the Trigger Action when I used either {previousMap!=mapName} or {previousMap}!={mapName} in the Trigger when properties match: field, the action wouldn’t trigger, or I got an error message, expression evaluation error, and the action didn’t trigger. However, when I used $previousMap$!=$mapName$ the action triggered.

I still got undesired results from moving a stock certificate from one place to another on the same map. Apparently, $previousMap$ isn’t changed until the piece ends its movement somewhere other than the map it was on before moving. I was going to use a Dynamic Property, I named formerMap, defined in the prototype with the Trigger Action and Set Global Property traits to act like the counted Dynamic Property described in the trick. The final action to be triggered in the Trigger Action trait was to set this formerMap to the current map so subsequent moves on the same map would not trigger an adjustment in share count. However, I reasoned that the errors I was getting with not finding the Global Properties that I was trying to set prevented the remaining actions from being triggered.

I think I may have been misunderstanding the required syntax for the expressions.

I had a success with the expression {$Company$+“Shares”} for the Global Property to set with Set Global Property.

I’ll keep trying with expression for the maps. It’s close to my bed time so it may be a day or two, depending on other life demands before I get this figured out.

My problem was syntax. As posted earlier {$Company$+“Shares”} worked for specifying which Global Property to set.

{$CurrentMap$} worked for referring to the current named map.

Apparently the property previousMap only changes with a change in the current map. So a piece moved from MapA to MapB would have MapA as the previousMap property until it left MapB. So I created a Dynamic Property named formerMap, and had it set to the current map after doing the all counting tasks. Thus when the stock certificate changed maps formerMap and CurrentMap would be different until the Global Properties keeping count of how many of these certificates on these maps were adjusted for the move. Then formerMap would be set to CurrentMap so subsequent moves within the current map would not affect the count of stocks.

The syntax that worked with reference to a Named Map was {$CurrentMap$} and {$formerMap$}.

Just an FYI, those $ signs are redundant (and technically incorrect, although, as you’ve discovered, it still works). {Company+“Shares”}, {CurrentMap}, {formerMap} are the “correct” forms to use. The only time you should be using $ within {} is for the condition on a Global Key Command; anything within $ signs will be substituted with the value on the piece issuing the GKC (and will probably need to enclosed in double quotes, as well), while other properties will use the value on the piece being checked.


Thank you. I’ll give {Company+“Shares”}, {CurrentMap}, and {formerMap} a try.

I saw some warnings against using OldMap, or Old of anything. So I was trying to find a form of mapName that would work as it seemed to be the newer property name for the current map for a piece, but as noted above I was having a hard time. Which leads me to the question: which is the preferred name for the property containing the name of the current map?

Not sure I understand the question. CurrentMap is the property containing the name of the current map, but you already knew that?

I’ve seen in the documentation that CurrentMap has the name of the current map. I have also seen mapName used in the documentation as a reference to the current map. My question is: Which is preferred: CurrentMap, mapName, or something else?


The only place I see a reference to “mapName” in the docs is in the instructions for the Report Action trait. I’m not sure it actually works anywhere else (I’ve never actually used it myself).

Ah! I had just finished getting a report of an action into the game log using the Report Action trait before I started working on tracking how many shares of a stock were in a player’s map window. When I saw the warning against using OldMap, I thought there might be a gradual changing of references to the OldMap and CurrentMap properties since the documentation of the Report Action trait used previousMap and mapName instead.

I imagine it is quite the challenge to continue the development of features and adaptations needed to use newer hardware and infrastructure while maintaining compatibility for older modules.

I want to learn the newer ways of module development as much as possible. So modules I write can delay for as long as possible getting stuck on the OldMap.


Vassal 3.2 had significant bugs in the setting of the Oldxxxx properties which may have been where that warning originated. This was one of the many bugs fixed in version 3.4. There should be no problem using Oldxxxxx properties in your module, they are definitely ‘current’ usage. The 3.4 in-app Help doco has been substantially updated and any properties listed on the Properties page are good to go.

As jrwatts mentioned, you have to be wary of the $variable$s defined for use in Report Actions and Movement reports. These are NOT Vassal properties and only exist for very limited use in that context (These are a very old part of Vassal). See the Properties Help page for the list of ‘real’ property names.


Thank you, Brent

I greatly appreciate your help in pointing out these little exceptions like variables used for the reports.