# Property Match Expression

**URL:** <https://forum.vassalengine.org/t/property-match-expression/89926>\
**Category:** Module Design\
**Created:** [February 24, 2026, 1:45pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926 "2026-02-24T13:45:13Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 24, 2026, 1:45pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/1 "2026-02-24T13:45:13Z")

</div>

I have a game where there are leaders counters on the main map and leader mats on a private map.  
The mats contain the combat units.  
I’d like to sum the SPs of the combat units and show them on the leader.

I build a previous release of the game as few years ago with the old Sum function. It worked but was a bit sluggish. I ran the same module on a recent version of vassal and it worked much faster.

I am now rebuilding the module from scratch and would like to use the newer functions.

so I have a leader counter BasicName pd\_leader\_BELLGARDE

and a mat counter BasicName pd-mat-BELLGARDE

yes the - and \_ are what they are.

I figured this should do the match

```auto
  SumMap("MATSP","{BasicName==$BasicName$.replace(\"_leader_\",\"-mat-\")}")

```

If I just do SumMap(“MATSP”,“AutoAOD”)  
It sums just fine but for all the mats on that board.  
So I am confident that it is the property match expression that is incorrect.

If I put this expression in a text label the name looks correct.

```auto
`{$BasicName$.replace("_leader_","-mat-")}`

```

I tried to add .trim() but it caused an expression error.

cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 24, 2026, 6:51pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/2 "2026-02-24T18:51:27Z")

</div>

> [@gusi](#):
>
> I figured this should do the match
> 
> ```auto
> SumMap("MATSP","{BasicName==$BasicName$.replace(\"_leader_\",\"-mat-\")}")
> 
> ```

Check out [this recent reply to a similar question](https://forum.vassalengine.org/t/accessing-mat-trait-properties/89895/2). The technique outlines there should select based on current mat or current cargo.

If you want the leader counter on the privat window to know about properties of the leader counters on the main map, make those two counters [Attachment](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top)s one way or the other. I do something similar in [Littoral Commander: Indo-Pacific](https://vassalengine.org/library/projects/Littoral_Commander_Indo-Pacific): The unit counters on the main map are associated with a tracker card on another map. When the hit points on the tracker goes to zero, then both the counter on the main map and the tracker are eliminated. When the resource count of Long Range Strike (LRS) - for example - hits zero on the tracker card, it is no longer possible to declare LRS combat with the counter on the main map - and so on.

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 25, 2026, 11:32am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/3 "2026-02-25T11:32:41Z")

</div>

Thanks Christian,

I had a look at the module.

I hardcoded a property LNAME and managed to match to it as an attachment and a SumMap using LNAME=“$LNAME$”

In practise though the easiest mapping is through the leader name.  
And the leader name is part of the basicname. I am using nat-type-leadername for the basicnames.  
In the end I asked copilot to give it a go… and it got it right first time.

```auto
SumMap("MATSP","AutoAOD","{BasicName == \\\"$BasicName$\\\".replace(\\\"_leader_\\\", \\\"-mat-\\\")}")

```

if only I asked a couple days ago 🙂

Is there way to initialise markers or dynamic properties based on an expression?

I tried extracting the leadername to a calculated property but that creates an infinite loop and I then have to kill the JRE.

I have been really surprised how well copilot has worked and how VASSAL aware it was.

I didn’t know anything about graphics. It guided me through snipping the countersheet images, scaling the map, OCRing the counters to create a register and so on.

cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 25, 2026, 5:00pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/4 "2026-02-25T17:00:02Z")

</div>

> [@gusi](#):
>
> I hardcoded a property LNAME and managed to match to it as an attachment and a SumMap using
> 
> ```auto
> LNAME=“$LNAME$”
> 
> ```

The benefit of using an [Attachment](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) trait, is that Vassal does not have to query every single piece on the map. Indead, it only needs to query the attached or attached to piece(s).

> [@gusi](#):
>
> In the end I asked copilot to give it a go… and it got it right first time.
> 
> ```auto
> SumMap("MATSP","AutoAOD","{BasicName == \\\"$BasicName$\\\".replace(\\\"_leader_\\\", \\\"-mat-\\\")}")
> 
> ```

Actually not a very good suggestion. This will query _all_ pieces on the map, which potentially can be a great deal, and will be relatively slow.

If your leader counter is indeed a [Mat](https://vassalengine.org/doc/latest/ReferenceManual/Mat.html#top) - and the units are [Mat Cargo](https://vassalengine.org/doc/latest/ReferenceManual/MatCargo.html#top) - then addressing the carried units with selection criteria

```auto
{CurrentMatID == $MatID$}

```

will be more efficent. If the carried units need to address the carrier (the mat), then the selection would be

```auto
{MatID == $CurrentMatID$}

```

[Mat](https://vassalengine.org/doc/latest/ReferenceManual/Mat.html#top) and [Mat Cargo](https://vassalengine.org/doc/latest/ReferenceManual/MatCargo.html#top) traits are - however - really only useful if the leader counter does indeed carry around other counters, and these counters may change their leader - or mat. You should of course use [Mat based](https://vassalengine.org/doc/latest/ReferenceManual/ExpressionSumCount.html#MatBased) sum and count functions.

If carried counters are only ever associated with a single _specific_ leader counter, then the [Attachment](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) trait is more suitable. You should of course use [Attachment based](https://vassalengine.org/doc/latest/ReferenceManual/ExpressionSumCount.html#AttachmentBased) sum and count functions.

> [@gusi](#):
>
> I have been really surprised how well copilot has worked and how VASSAL aware it was.

“aware” is a funny adjective to use about a piece of mechanics that guesses most of the time 🙂

> [@gusi](#):
>
> Is there way to initialise markers or dynamic properties based on an expression?

Do you mean [Marker](https://vassalengine.org/doc/latest/ReferenceManual/PropertyMarker.html#top) and [Dynamic Property](https://vassalengine.org/doc/latest/ReferenceManual/DynamicProperty.html#top) - then no. The value stored by a [Marker](https://vassalengine.org/doc/latest/ReferenceManual/PropertyMarker.html#top) is by definition a constant. The same goes for the _initial value_ of [Dynamic Property](https://vassalengine.org/doc/latest/ReferenceManual/DynamicProperty.html#top).

What you _can_ do is provide a command for [Dynamic Property](https://vassalengine.org/doc/latest/ReferenceManual/DynamicProperty.html#top) - say `initLeader` - which will set the property to its initial calculated value. You can then trigger that command by a [Startup GKC](https://vassalengine.org/doc/latest/ReferenceManual/GlobalKeyCommands.html#startup).

> [@gusi](#):
>
> I didn’t know anything about graphics. It guided me through snipping the countersheet images, scaling the map, OCRing the counters to create a register and so on.

Take a look at [Tools for module developers](https://forum.vassalengine.org/t/tools-for-module-developers/84785) which has a bunch of links to tools that are useful for module developers - including [Script to make common operations on piece images](https://forum.vassalengine.org/t/script-to-make-common-operations-on-piece-images/84787)

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 26, 2026, 12:25pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/5 "2026-02-26T12:25:12Z")

</div>

> [@cholmcc](#):
>
> Actually not a very good suggestion. This will query _all_ pieces on the map, which potentially can be a great deal, and will be relatively slow.
> 
> If your leader counter is indeed a [Mat](https://vassalengine.org/doc/latest/ReferenceManual/Mat.html#top) - and the units are [Mat Cargo](https://vassalengine.org/doc/latest/ReferenceManual/MatCargo.html#top) - then addressing the carried units with selection criteria

There are two counters for each leader, a regular counter on the main map and a mat on the organisational chart. The mat holds all the units that a leader commands. The units are mat cargo.

Typically, each side has less than 20 leaders on the map and less than 40 counters on the org chart.

My previous version used the same number of counters. It has just older art and was hacked from another module.  
but it runs very fast with the deprecated sum function in the recent versions of vassal.

I would prefer, though, to use the plain leadername as an attachment. But I haven’t figured out a way on how to get the leader names into a marker or into the attachment name automatically.  
All up there are about 100 leaders and a100 mats to cover all the scenarios.

The only way I can think off is to export the leaders as an xml.Edit the names and the then delete and reimport.

At the moment I just have one prototype that covers all leaders from all sides.

> [@cholmcc](#):
>
> Take a look at [Tools for module developers](https://forum.vassalengine.org/t/tools-for-module-developers/84785) which has a bunch of links to tools that are useful for module developers - including [Script to make common operations on piece images](https://forum.vassalengine.org/t/script-to-make-common-operations-on-piece-images/84787)

I had a look at the shell script before but I don’t have a linux box at home.  
It didn’t take long to snip the counters with copilot/imagemagick. I got stuck on the bevelling. so I’ll have another look at those later.

vassal-python and pywargame might be what I am looking for. Are they up to date? And widely used?

The one thing that was easier than expected was scanning all the counters with easyocr in python. It extracted all the horizontal text with perhaps 2 corrections in 500+ counters.

Having a counter register in excel made it easy to generate the mat images using pillow in python. I would love to use it to initialise marker or dynamic property traits for each counter.

> [@cholmcc](#):
>
> > [@gusi](#):
> >
> > I have been really surprised how well copilot has worked and how VASSAL aware it was.
> 
> “aware” is a funny adjective to use about a piece of mechanics that guesses most of the time

True, I am still getting used to dealing with AI and how to describe it accurately. 🙃

cheers  
Gus

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 26, 2026, 1:50pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/6 "2026-02-26T13:50:38Z")

</div>

Ah I just saw that pywargame is yours. 😊

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 27, 2026, 12:30am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/7 "2026-02-27T00:30:16Z")

</div>

> [@gusi](#):
>
> There are two counters for each leader, a regular counter on the main map and a mat on the organisational chart. The mat holds all the units that a leader commands. The units are mat cargo.

I would make the two leader counters of each leader [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to each other so they can effectively communicate.

Some questions:

- Are there counters for the units on the main map? If so, I would also make them [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to their counter-parts on the org-map.
- Can units change between leaders?
  - If not, then you can fix the leader [Attachement](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) of each unit - or possibly prototype - explicitly mentioning the leader [Attachement](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) name
  - If they can, then you can use _Key Command to apply to all units ending movement on this map_ of the org-map (see [Map Window](https://vassalengine.org/doc/latest/ReferenceManual/Map.html#top)) to discover which leader ( [Mat](https://vassalengine.org/doc/latest/ReferenceManual/Mat.html#top)) a unit is currently sitting on.

> [@gusi](#):
>
> I would prefer, though, to use the plain leadername as an attachment. But I haven’t figured out a way on how to get the leader names into a marker or into the attachment name automatically.  
> All up there are about 100 leaders and a100 mats to cover all the scenarios.

The name of an [Attachement](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) trait is not an expression, so you can only give it a constant value.

But, I think that you want is that

- The pair of Leader counters are mutually [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to each other.
- If there are unit counters on the main map _and_ on the org-map, then those pairs are _also_ mutually [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to each other.
- The unit counters on the org-map are _not_ [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to the leaders on the org-map.
- Instead, they are [Mat Cargo](https://vassalengine.org/doc/latest/ReferenceManual/MatCargo.html#top), as the probably do not need to communicate with their leaders.

> [@gusi](#):
>
> vassal-python and pywargame might be what I am looking for. Are they up to date? And widely used?

- I don’t know what the status of `vassal-python` is.
- `pywargame` is actively maintained - by yours truly. I have no idea how much it is used by other people. Personally I use it all the time, and I know of a hand-full of other people who are or have used it.

> [@gusi](#):
>
> Having a counter register in excel made it easy to generate the mat images using pillow in python. I would love to use it to initialise marker or dynamic property traits for each counter.

If you use `pywargame` you can keep the counter stats, etc., externally in some sort of database (a spreadsheet, JSON files, SQLite, …) and then read it via Python and then use `pywargame` to build - or patch - your counters.

> [@gusi](#):
>
> I had a look at the shell script before but I don’t have a linux box at home.

If you have a MacOS machine, then you should be able to use the script too. If you are on Windows, you may have some luck with the so-called [“PowerShell”](https://learn.microsoft.com/en-us/powershell/scripting/install/install-powershell-on-windows?view=powershell-7.5). Alternatively, there’s [Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) - which will give you a almost full Linux installation.

> [@gusi](#):
>
> … AI and how to describe it accurately

The “Intelligence” part of AI is certainly a misnomer of epic proportions 🙂

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 28, 2026, 4:16am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/8 "2026-02-28T04:16:44Z")

</div>

> [@cholmcc](#):
>
> The name of an [Attachement](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) trait is not an expression, so you can only give it a constant value.

That is a shame that would mean that we to hardcode all the attachment names. I had hoped the prototypes would be more flexible.

Your python module looks great. I am getting f-string expression part cannot include a backslash errors even on an empty vmod.  
I am a bit of a python newby any idea what might be happening there?

cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 28, 2026, 8:23am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/9 "2026-02-28T08:23:08Z")

</div>

> [@gusi](#):
>
> That is a shame that would mean that we to hardcode all the attachment names. I had hoped the prototypes would be more flexible.

Prototypes are directly substituted in when piece are built, and unfortunately they can not be parameterised - which would be kinda nice.

> [@gusi](#):
>
> Your python module looks great.

Thanks. I hope you will find it useful. Please let me know if you have any troubles, complaints, suggestions, etc.

> [@gusi](#):
>
> I am getting f-string expression part cannot include a backslash errors even on an empty vmod.

Does the error come from `pywargame` or your code?

- If the error comes from `pywargame`, then please make a new Issue at [GitLab](https://gitlab.com/wargames_tex/pywargame/-/issues). There, just like here, you can use MarkDown to mark-up your text. Please provide the full error message and other relevant information and code. You may want to link to the issue from here so that others may easily find it.
- If the error comes from your code, it is probably because you have something like

```auto
 s = f'blah blah {blah}\n'

```

It should be

```auto
s = f'blah blah {blah}'+'\n'

```

Hope that helps you.

Yours  
_Christian_

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 28, 2026, 10:56am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/10 "2026-02-28T10:56:57Z")

</div>

> [@gusi](#):
>
> I am getting f-string expression part cannot include a backslash errors even on an empty vmod.

Are you using a pre-3.12 version of Python? From Python 3.12 and on, the limitation on [`\` in f-strings has been lifted](https://realpython.com/python-f-strings/#upgrading-f-strings-python-312-and-beyond).

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [February 28, 2026, 11:04am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/11 "2026-02-28T11:04:42Z")

</div>

Yes 3.11. I’ll bump it up.  
Cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [February 28, 2026, 11:52am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/12 "2026-02-28T11:52:40Z")

</div>

> [@gusi](#):
>
> Yes 3.11. I’ll bump it up.

OK. Great.

If the problem was `pywargame` I would still like to see the error in a [GitLab issue](https://gitlab.com/wargames_tex/pywargame/-/issues) - so that I can fix it for backward compatibility.

Thanks.

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [March 2, 2026, 11:00am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/13 "2026-03-02T11:00:06Z")

</div>

I’ll put something in GitLab.

It is supposed to look like this.  
Each leader has a mat. The mat contains the combat units and subordinate leaders by the leader.

The total SP are summed per mat just using the SumMat. (blue number on mat and green number on leader).

The strength are passed from the mats to the leader counters using SumMap.

Leaders on the map can also belong to a multihex force.

The leaders on the main map belong to Force Red and have the force strength calculated using SumMap.

This way I just have 3 prototypes, Leaders, Mats and Units.

The only specific marker is the leader initiative used in a hidden init roll. I briefly thought of embedding the init in the image name to make it available through BasicName. But that didn’t feel quite right either.

 ![game snip](https://forum.vassalengine.org/uploads/default/original/2X/b/b61a35c0b36cf23df3b649120ecb3eec71bb2e3b.jpeg)

I had a play with the attachment property but having to hard code all the names felt a bit painful.

It is such a shame that we can have expressions in Marker & Dynamic Property Initialisation & Attachment names. It would just be evaluated once on startup. But I am not familiar with the internal architecture and there is bound to be a good reason for it.

All the numbers are just text labels until I figure out how to do layered graphics like the GCACW counters.

Cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [March 2, 2026, 6:11pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/14 "2026-03-02T18:11:19Z")

</div>

> [@gusi](#):
>
> Each leader has a mat. The mat contains the combat units and subordinate leaders by the leader.

OK, so as far as I can tell, the individual units - say “Bajalich” are _never_ present on the board - only their commander - say “Quasdanovich” - are represented on the main map. Is that correct?

However, a commander may also be sub-ordinate to another commander - say “Bellegarde” to “Quasdanovich”. Can the sub-ordinate commander be present on the main map too? That would complicate matters a bit.

How does the Commander pieces on your organisational chart (AutoAOD map) look like? Are they, for example for “Quasdanovich”, a piece that spans several rows and columns - like the gray area indicates?

> [@gusi](#):
>
> The total SP are summed per mat just using the SumMat. (blue number on mat and green number on leader).

OK, so that seems straight forward.

> [@gusi](#):
>
> The strength are passed from the mats to the leader counters using SumMap.

That, I don’t quite get. If the large gray piece “Quasdanovich” on “AutoAOD” has the property - say - `TotalSP` with value `9` - calculated using `SumMat` - then why would you need to do another calculation to get the same value on the main map? If the commander piece on the map - say “Quasdanovich” is [Attached](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top) to the equivalent piece on the “AutoAOD”, it can simply get that value with [`GetAttachProperty`](https://vassalengine.org/doc/latest/ReferenceManual/ExpressionProperty.html#Attachment). This is by far the most efficient way to do that.

Everytime you use something like `SumMap` your performance will suffer.

> [@gusi](#):
>
> I had a play with the attachment property but having to hard code all the names felt a bit painful.

Note that there’s no reason to think that you couldn’t use a pieces name as its attachment name. E.g., the two pieces for the commander “Quasdanovich” - the map representation and the AutoAOD representation - could have the attachment “Quasdanovich”. Yes, you would need to add that trait to individual pieces and they cannot be in a prototype, but on the other hand, it is fairly straight-forward.

Of course, if you use `pywargame`, you can ensure proper reference in code 🙂

> [@gusi](#):
>
> Leaders on the map can also belong to a multihex force.

How does the module make that assignment? Is it a user choice, or built in to the module. Again, it may make sense to make this a kind of mutual a  
[Attachement](https://vassalengine.org/doc/latest/ReferenceManual/Attachment.html#top), depending on how long that assignment may last.

In most of the modules I’ve done, I have logic that allows the user to calculate combat odds. The user selects all belligerents of a combat, and then press a short-cut key, button, or select from the context menu. The module then sums up attacking and defending combat factors - possibly with modifiers due to terrain and features - and calculates the combat odds. An odds marker is then placed on one of the defending stacks and a combat marker placed on all belligerents. The user can then select the odds marker, press a short-cut key, button, or select a context menu item to resolve the combat. A combat result marker then replaces the combat odds marker. If this is something like what you want to do, you can check out one of the [modules I’ve done](https://vassalengine.org/library/search?owner=cholmcc).

> [@gusi](#):
>
> All the numbers are just text labels until I figure out how to do layered graphics like the GCACW counters.

How do you set the text labels? Be careful about setting them (directly or indirectly) by a calculation like `SumMap` - or similar. Every time the label has to be redrawn - which happens relatively often - the expression has to be reevaluated which can potentially be costly. That also applies to [Layer](https://vassalengine.org/doc/latest/ReferenceManual/Layer.html#top) trait with _Levels follow expression value_.

If you use a [Dynamic Property](https://vassalengine.org/doc/latest/ReferenceManual/DynamicProperty.html#top) - rather than a [Calculated Property](https://vassalengine.org/doc/latest/ReferenceManual/CalculatedProperty.html#top) - to store the calculation in, then a new value will only be calculated on a _specific_ request - for example when a piece is removed from or added to the “AutoAOD” commander piece mat, or when commanders are attached to or detached from a task force on the main map.

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [March 8, 2026, 9:04am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/15 "2026-03-08T09:04:42Z")

</div>

Thanks Christian.

The combat unit pieces like Bajalich are only on the Mats in the AOD map.  
The leaders (Commander is jargon in this game for a special type of leader) are either on the map or are subordinate on another leader’s mat. But never on both.

The top left counter image on the mats is just decoration and part of the mat image.

The middle rating of a leader is his command span and detrmines how many other leader the can carry on the mat. So there are large and small mats depending on the leaders command span.

Forces are determined by the user. A leader can join Force Red, Force Blue etc.

I tried the attachments. Using CountAttach() I could get see the right number of attached counters. But I tried numerous variations of attachmentname\_SP, $attachmentname\_SP$ etc.  
but no cigar.

I realise that vassal was designed to ripple through properties using key commands.  
But the Sum and Count functions seemed nice work arounds. Specially since they are supposed to be lightning fast in recent versions.  
I first tried Sum and Count in 2022 and was a bit sluggish.

The combat odds are pretty straight forward in this game. The attrition table is a different beast though. I’ll have a look at that after I get everything else functional.

regards  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [March 8, 2026, 9:35am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/16 "2026-03-08T09:35:23Z")

</div>

> [@gusi](#):
>
> The combat unit pieces like Bajalich are only on the Mats in the AOD map.  
> The leaders (Commander is jargon in this game for a special type of leader) are either on the map or are subordinate on another leader’s mat. But never on both.

OK, that makes things a little easier.

> [@gusi](#):
>
> The top left counter image on the mats is just decoration and part of the mat image.
> 
> The middle rating of a leader is his command span and detrmines how many other leader the can carry on the mat. So there are large and small mats depending on the leaders command span.

OK, I think I gather that from the graphics too. Enforcing the number of attached leaders on another leader mat may be a bit of challenge. In Vassal, in general, it can be a little tricky to prohibit specific moves.

> [@gusi](#):
>
> Forces are determined by the user. A leader can join Force Red, Force Blue etc.

OK. How do you see that implemented? And what is the impact of being part of a specific force?

One possible implementation could be to have pieces in the same force join in in the same attachment. Then your pieces would have an attachment trait for each possible force (`RedAttachment`, `BlueAttachment`, …). Visually, you can make force membership be a [Layer](https://vassalengine.org/doc/latest/ReferenceManual/Layer.html#top) or [Border Outline](https://vassalengine.org/doc/latest/ReferenceManual/BorderOutline.html#top) trait that adds the force colour to the piece - it seems like you have something like that now.

The real question, and whether it is needed to set up some sort of attachment or the like, between pieces of the same force, is whether there are certain actions that can be taken in or by the module, that depends on the force a piece belongs to, or if it is merely a convenience for the players.

Rather than attachments, you could also have separate windows (or hands) for each force. So that if a user places `Quasdanovich` in the `RedForce` window, it is considered to be part of the red force. Because the on-map piece is attached to its in-force piece, it can now about the force assignment and display the proper graphics to indicate that. It could be handled by `Command when piece ends movement on this map` option in the force windows, which sends a command to the `tracker` piece, which in turn sets a property in the on-map piece.

> [@gusi](#):
>
> I tried the attachments. Using CountAttach() I could get see the right number of attached counters. But I tried numerous variations of attachmentname\_SP, $attachmentname\_SP$ etc.  
> but no cigar.

If your attachment name is `acttachmentName`, and you want to sum the property `SP` of each attached piece, then use

```auto
{SumAttach("attachementName","SP")}

```

See also [Attachment based](https://vassalengine.org/doc/latest/ReferenceManual/ExpressionSumCount.html#AttachmentBased) sum and count functions. Note that if you for some reason need to exclude the piece calling the function from the sum, you may need to do something like

```auto
{SumAttach("attachmentName","SP","{BasicName!=\"$BasicName$\"}")}

```

Remember, `$...$` variables are expanded (replaced by their value in the calling piece) _before_ the expression is evaluated on the target pieces. Thus, if piece `Quasdanovich` calls the function, and it is sent to “Bellgarde”, then the expression evaluated in that last piece is

```auto
{SumAttach("attachmentName","SP","{BasicName!=\"Quasdanovich\"}")}

```

That’s why you need the escaped quotes `\"...\"`.

Yours,  
_Christian_

---

<div class="post-metadata">

**Author:** ![gusi](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/g/9fc29f/32.png) [@gusi](https://forum.vassalengine.org/u/gusi)\
**Post date:** [March 8, 2026, 10:38am UTC](https://forum.vassalengine.org/t/property-match-expression/89926/17 "2026-03-08T10:38:54Z")

</div>

> OK, I think I gather that from the graphics too. Enforcing the number of attached leaders on another leader mat may be a bit of challenge. In Vassal, in general, it can be a little tricky to prohibit specific moves.

I wasn’t planning to reinforce any of the rules. You can stack on more combat units than is allowed.

> OK. How do you see that implemented? And what is the impact of being part of a specific force?Blockquote

The multihex force allows you to move multiple units as one activation.  
The downside is that the attrition is calculated over the whole force.

Moving large stacks is quite expensive in attrition losses.  
I am not calculating attrition.

I am only automating a couple things.

- counting the SP of a force. The cardboard AODs are very elegant as a one to many database but there is a lot of counting.

In practise we all use yellow stickers with our leaders and SPs.

- Doing the secret initiative roll.  
The init roll determines if and how far you can move. Seeing the roll on an opponents hidden unit gives you a very big clue who it is.  
As a work around I instantiated another 1d6 that tells you how far the piece can move instead of the dr result. There is also a markup on the unit so you can distinguish between having a failed a init roll and not having rolled yet)

All the rest is pretty standard masking etc.

- I might make some mile post counters and depot markups so you can easily check the length of the line of communications.

> **Attachment Name:**  
> The name for this Attachment trait. This name can be used by the piece to read properties from attached pieces. For example if the Attachment name were _Sibling_, then the property _Sibling\_LocationName_ would contain the _LocationName_ property of the first currently attached piece.

I had hoped this syntax would work but I did end up going with the SumAttach version.

cheers  
Gus

---

<div class="post-metadata">

**Author:** ![cholmcc](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/cholmcc/32/8319_2.png) [@cholmcc](https://forum.vassalengine.org/u/cholmcc)\
**Post date:** [March 8, 2026, 12:23pm UTC](https://forum.vassalengine.org/t/property-match-expression/89926/18 "2026-03-08T12:23:07Z")

</div>

> [@gusi](#):
>
> I wasn’t planning to reinforce any of the rules.

Understandable. One way one could try to do it would be with a _command when ending movement on this map_ - or similar - that counts the number of already placed [Mat Cargo](https://vassalengine.org/doc/latest/ReferenceManual/MatCargo.html#top) pieces on the [Mat](https://vassalengine.org/doc/latest/ReferenceManual/Mat.html#top), and if that has already hit the limit, then an _Undo_ command is sent to the module.

> [@gusi](#):
>
> The multihex force allows you to move multiple units as one activation.  
> The downside is that the attrition is calculated over the whole force.
> 
> Moving large stacks is quite expensive in attrition losses.  
> I am not calculating attrition.

OK, so you basically only want some sort of graphical indication that a particular piece belongs to a particular force, right? Then a set of simple [Border Outline](https://vassalengine.org/doc/latest/ReferenceManual/BorderOutline.html#top) traits would work.

- Dynamic Property:
  - Name: `Force`
  - Commands:
    - Menu: `Join Red Force`, Expression: `{"Red"}`
    - Menu: `Join Blue Force`, Expression: `{"Blue"}`
    - …

- Calculated Property
  - Name: `IsRedForce`
  - Expression: `{Force=="Red"}`

- Calculated Property
  - Name: `IsBlue`
  - Expression: `{Force=="Blue"}`

- …
- Border Outline
  - Colour: `0xFF0000`
  - Property: `IsRed`

- Border Outline
  - Colour: `0x0000FF`
  - Property: `IsBlue`

- …

> [@gusi](#):
>
> - counting the SP of a force. The cardboard AODs are very elegant as a one to many database but there is a lot of counting.

Wait - do you want to sum up the strength points of a _force_ (multi-hex selection), or units (and possible leaders) attached to a single leader? If you want to sum up the strength points of a _force_, then perhaps they should be mutual attachments so as to make the summing effective and easy to manage.

BTW, what is the acronym _AOD_?

I think, if you want to sum of strength points of a _force_, it would make sense to have one _AOD_ per force as outlined before. If, for example, initiative rolls are done by _force_ rather than by _stack_ (leader), then that would facilitate some more automation. Of course, if the initiative roll is per _stack_, you do not really need that because you already have the stack mat on the AOD. BTW, I guess the AODs are [Player Hand](https://vassalengine.org/doc/latest/ReferenceManual/PlayerHand.html#top) or [Private Window](https://vassalengine.org/doc/latest/ReferenceManual/PrivateWindow.html#top).

> [@gusi](#):
>
> - …  
> As a work around I instantiated another 1d6 that tells you how far the piece can move instead of the dr result. There is also a markup on the unit so you can distinguish between having a failed a init roll and not having rolled yet)

You can always use the function `Random`

```auto
{Random(6)}

```

to get a random integer between 1 and 6, both inclusive. That is, you do not need a dice component to do this.

> [@gusi](#):
>
> - I might make some mile post counters and depot markups so you can easily check the length of the line of communications.

Perhaps the regular [Line of Sight Thread](https://vassalengine.org/doc/latest/ReferenceManual/Map.html#LOS) component will be enough.

> [@gusi](#):
>
> > if the Attachment name were _Sibling_, then the property _Sibling\_LocationName_ would contain the _LocationName_ property of the **first** currently attached piece.

(emphasis added)

The crucial point here, is that references like `<attachment name>_<property>` _only_ looks at the _first_ attached unit. Thus it will not work to sum up the property.

Yours,  
_Christian_