Create account / Log in

GKC and location==$location$?

Talk about module design ideas and techniques.

Moderators: uckelman, Tim M

GKC and location==$location$?

Postby grouchysmurf » May 11th, 2014, 8:15 pm

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?
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Sebaestschjin » May 11th, 2014, 8:27 pm

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.
Sebaestschjin
 
Posts: 23
Joined: April 10th, 2014, 10:49 am

Re: GKC and location==$location$?

Postby grouchysmurf » May 11th, 2014, 8:31 pm

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.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Tim M » May 11th, 2014, 11:02 pm

tricky eh? :wink: it can be done
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1812
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: GKC and location==$location$?

Postby Brent Easton » May 12th, 2014, 1:35 am

In GKC condition, how do I limit its action to pieces belonging to the location of the piece which fired the GKC?


Specify a range of 0

My guess was to use "location==$location$" but it does not work (GKC triggers all the pieces, contrary to my expectations)


Did you try it with = instead of ==?
User avatar
Brent Easton
 
Posts: 3073
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: GKC and location==$location$?

Postby grouchysmurf » May 12th, 2014, 5:57 pm

@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?
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby grouchysmurf » May 12th, 2014, 5:58 pm

Tim M wrote:tricky eh? :wink: it can be done


Yeah.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Tim M » May 12th, 2014, 7:27 pm

grouchysmurf wrote: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.


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).

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.


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
http://www.vassalengine.org/wiki/Faq_mo ... ounters.3F
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1812
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: GKC and location==$location$?

Postby grouchysmurf » May 13th, 2014, 1:05 pm

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.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Tim M » May 13th, 2014, 2:48 pm

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 :)
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1812
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: GKC and location==$location$?

Postby grouchysmurf » May 13th, 2014, 4:32 pm

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.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Brent Easton » May 13th, 2014, 10:05 pm

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

Code: Select all
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

Code: Select all
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

Code: Select all
LocationName=$LocationName$


Regards,
Brent.
User avatar
Brent Easton
 
Posts: 3073
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: GKC and location==$location$?

Postby grouchysmurf » May 14th, 2014, 6:05 pm

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.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby grouchysmurf » May 15th, 2014, 5:09 pm

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.
User avatar
grouchysmurf
 
Posts: 138
Joined: August 9th, 2011, 7:48 pm

Re: GKC and location==$location$?

Postby Brent Easton » May 15th, 2014, 10:58 pm

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.
User avatar
Brent Easton
 
Posts: 3073
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Next

Return to Module Design

Who is online

Users browsing this forum: No registered users and 2 guests