GKC and location==$location$?

In GKC condition, how do I limit its action to pieces belonging to the location of the piece which fired the GKC? My guess was to use “location==$location$” but it does not work (GKC triggers all the pieces, contrary to my expectations). Any hints?

The problem with the condition is that it will be evaluated in the context of the game piece that receives the command, not in the context of the triggering game piece. This means that the value of $location$ is always the location of the receiving game piece, so your condition is always true.
To do what you intend, you would have to use a GlobalProperty (lets call it GKCLocation). When your GKC fires first set the value of this GP to the location of the piece that trigger the GKC. Then change your condition to “location=$GKCLocation$” and it should work as intended.

Yeah, I thought this might be the case BUT check the out the documentation for GKC piece trait (piece trait, not that from the map):

A leader counter and infantry counters both have Marker traits to specify their nationality and type. A Layer trait represents the rallied state of an infantry counter, uses CTRL A to activate the layer, and uses Rally as the name. A Global Key Command on the leader counter can select and rally all infantry counters within two hexes of the same nationality that are not rallied by specifying Range=2 and matching properties type=Infantry && nation=$nation$ && Rally_Active=false.

As I read it, $nation$ originates from the piece triggering the GKC – as in my case. It is then passed to the target piece and the condition is evaluated.

Which implies that either documentation is screwed up or generic traits are not properly processed by the GKC – contrary to the custom (i.e. nation) ones.

tricky eh? :wink: it can be done

Specify a range of 0

Did you try it with = instead of ==?

@Brent:

  1. this is an irregular grid that I have and it seems that range does not work in such scenario – it would be a nice feature to add, thought, that in case of every type of grid, Vassal would interpret Range==0 as that the condition pertains to the very hex/region/area.

  2. = doesn’t work, either.

Any further tips?

Yeah.

No, Sebaestschjin explained it correctly. And his how to was 1 correct way of solving your problem.

Citing the example - How can only one property (in this case the value of “nation” be resolved on the originating piece and passed on to other pieces and yet the other properties in the expression are not passed on? Why do you think this happens and what in the example lead you to believe this?

Either the values of infantry/nation/Rally_Active evaluate from the values on the original piece and all are passed on to other pieces or they are evaluated on all the pieces individually in the context of those pieces. (I’ll take the latter for $1000 Alex).

I don’t know what this means but the documentation is correct in its example. By generic traits do you mean the system properties Vassal is providing as in (again from the example) “Range” and “Rally_Active”? Does the documentation need more clarity if you felt it was incorrect?

There is no difference between a system property and an added custom property (via marker trait for instance) as far as processing goes though.

Which leads me to ask were you originally thinking that “location” is a system property and thus why you thought it was not working properly? “location” is not a system property.

A list of all the system properties you can access is here
vassalengine.org/wiki/Faq_mo … ounters.3F

Tim, are you pulling my leg? Like, that I am stupid or something and it’s just a good opportunity to make fun of someone?

You wrote:

Citing the example - How can only one property (in this case the value of “nation” be resolved on the originating piece and passed on to other pieces and yet the other properties in the expression are not passed on? Why do you think this happens and what in the example lead you to believe this?

And back to what I had quoted:

type=Infantry && nation=$nation$ && Rally_Active=false

All other properties in the expression are constants i.e. no need to resolve them on any level, in any context.

Also, let’s take a closer look at the $nation$ property and the description from the documentation, which says A Global Key Command on the leader counter can select and rally all infantry counters within two hexes of the same nationality that are not rallied by specifying

What do the words “same nationality” refer to? My guess is that they refer to the nationality of the leader counter – is this wrong assumption? If, however, they refer to the nationality of the “target” counters i.e. these which are to be rallied, what do you need the condition “nation=$nation$” for as, no matter what, in context of the target counter it is always true? And additionally: in they refer to the targe counters, what is then a difference between GKC defined in context of a counter and one defined on a map level – if it is just the range, which can be defined on the former, then its use is pretty limited.

No, either I am misunderstanding you or you were misunderstanding me. I never thought you were stupid and not trying to make fun.

It seemed to me that you were saying that the documentation was confusing and/or wrong in some way and I wanted to know why / what made you think that because I thought it was clear (but now even I am wondering when at first I was certain because your recent explanation is much clearer to me what you are thinking).

I was also unclear if you had thought that “location” was a system property or you had set it up because you did not originally explain in your first post where you were getting “location” from

confusion abounds!

sorry for the misunderstanding :slight_smile:

Tim,

it is of no importance whether I referred to location or to nation – what matters is that documentation seems to suggest something what is not possible to achieve in Vassal. According to documentation one may draw conclusion that $nation$ is retrieved from originating piece. According to what you say, it is not the case – i.e. it pertains to the target piece, which in turn, leads to conclusion that this condition is always met.

Either of those is wrong.

In my module, I do exactly the same thing you do. Here is the Property Match from my Formation chits:

CurrentZone=~Map.*|Artillery Park.*&&Formation=$Formation$&&Active_Level=1&&MayNotActivate_Active!=true

Formation is a marker in my Activation chit and on each of the units in the matching formation. When the chit fires off this GKC, all units with the same Formation Marker, which are on a Map or Artillery Park, and are not already activated and are allowed to activate are activated.

So it works as you originally thought.

Any property match expression is pre-processed and any $xxxxx$ variables are replaced with values from the calling counter. Then the resulting property match expression is compared to each target counter.

back to your initial problem

location==$location$

not working, you will need to debug this further. Add a Text label to the source and target counters and display location=$location$ to see what your counters actually have as a value for $location$. I suspect it will be nothing because location is not a valid property of counters, it can only be used in Report Formats which are an entirely different beast. I suspect what you want is

LocationName=$LocationName$

Regards,
Brent.

Brent, that’s been very helpful but I am very sorry to say that LocationName doesn’t work, either! Your guessed it correctly – location was null but LocationName is not – I have it displayed above the counters. GKC affects all the pieces on the board, however, irrespectively of their location.

I am very very confused.

Well, all in all, I needed to implement it as Sebaestschjin – it is not very elegant but it works.

This might be a bug, I mean if custom fields are passed over to target pieces, it is most curious why native traits (LocationName!) are not.

There should be no difference. This procedure definitely works, I have a swag of modules that do exactly this. There may be some strange interaction with the irregular grid. I will build a small test module and try and see what is happening.

I have just created a small test module and this works perfectly. I created a map with 4 regions, a unit and a leader. The Leader unit has a GKC to activate units in the same region as him. Here is a link to the module I created, have a look and see if you can see anything different to what you have implemented.

http://home.exetel.com.au/swampwallaby/GKCtest.vmod

Thanks a lot! Wow, that’s an odd beast – it looks as if the condition, when defined, is not properly evaluated if constructed with a Expression Builder (at least in my module). I.e. $ and == are a big no-no. When I changed == to a single =, got rid of () – it worked.

Brent, thanks a lot for guiding me through that.