Side specific layers (language choice!)

I think it would be very nice to have layers able to follow the value of a $…$ variable.

Right now if you have them follow Hits - where Hits is a gp or dp - it works. But it doesn’t work if you have the layer follow things like $Hits$ or $CurrentMap$_Hits or $CurrentSide$_Hits or $BasicName$_Hits etc etc. Most of these examples are possibly pointless but consider the possibility of having a layer follow:


I know this is even more difficult, because while BasicName or CurrentMap are the same on every side’s screen, playerSide and playerName are not… thus potentially affecting the synchronization process.

However, if that could be done, then I could have a layer on my cards showing to player BLUE the English version of the card (BLUE_language=0) or the Italian one (BLUE_language=1) etc while player RED will see the same card in English or Italian etc based on his/her own language choice!

In other words, an Italian and an English player could play the same game, each one seeing the Italian or English version of the same pieces/cards on their own screen, independent of each other.

Any idea how difficult this would be to get in a future release of Vassal?

Or any alternative idea on how to accomplish language customization of cards/pieces at side level (not just a generic default language all sides have to agree to)? I can only think of very convoluted methods using multiple masks etc, which would need the player clicking on the cards to see his/her preferred language translation (with un-clicked default being English, say).

The easiest way I can think of to do this now is with multiple releases of the module - just change the image files but leave the buildfile alone. The different releases will still be able to talk to each other online, and each player will have their own language on the cards.

As for the indirection in the Layer trait, this should now be possible in 3.2 using Calculated Properties and BeanShell. Unfortunately I bet it would update the other clients with the new level - but then, I don’t /know/ that it would off the top of my head. Play around with it some! For the Follow Property, do something like:
Then have a Calculated Property, CurrentMap_Hits, with value:
{ GetProperty(CurrentMap + “_Hits”) }


Do you mean the checksum will be the same, even if the gifs happen to have different sizes? No synchronization issues? If so that would be nice, thxs for the suggestion.

I didn’t think of testing with 3.2, my bad. I guess I could try calculating ps_lang as GetProperty(playerSide + “_language”) and see how it goes (but it will probably show the value for the playerSide invoking the command, as you say).

As far as I know a checksum is never produced. The buildfile just says, “Hey load the image named ‘HitTheStreets.jpg’ and display it here.” The synchronization process does not reference the images directly…ever, I don’t think. I would make the images the same dimensions, however, so that they’re appearing in the same /position/ for all players.

Almost certainly, but then, follow property might be special, as it isn’t initially invoked in the way that other property references usually are - that is, as a result of a button press. So playerSide really might give different values for each of the connected clients when they very first decide to draw the layer.

I must confess I failed miserably at using Calculated Properties. Either I do not understand how they work or they just don’t work with layers.

I tried the following on a new module:

  1. added an at-start-stack with a single piece in it, no default image

  2. added a trait CALCULATED PROPERTY to it with name “languague” (without quotes) and value GetProperty(playerSide+"_language") [NOTE: also tried with PlayerSide, with capital P]

  3. added a LAYER trait to it, which follows property “language” (without quotes) and shows different images if language is 0, 1 or 2

  4. added a SET CLOBAL PROPERTY which prompts the user to change $playerSide$_language (choices are: 0, 1 and 2)

  5. added global properties BLUE_language and RED_language with default 0, type numeric

However, when I start a game and join as side BLUE, say, it keeps complaining that “BLUE_language” is not a numeric value. In other words it substitutes BLUE_language (the string) for language instead of the value of BLUE_language (which should be 0, 1 or 2). And the layer remains stuck at level 0.

What am I doing wrong? Or is it just LAYER not liking calculated properties?

Dude, for some reason I can’t even get GetProperty() to work at all for me anymore. I don’t know if it’s because I’m now on linux, or because I’m on a newer svn build, but everything I’ve tried gives something like:
Bad Data in Module: Expression evaluation error {GetProperty(“BasicName”)}

I can’t think of a more straightforward application of GetProperty. Any other linux users able to substantiate my suspicion that this is a bug with BeanShell in linux?

Anyways, two things:

  1. If an expression fails once, it may not be tried again until you reopen the module. So, considering that you didn’t add the global properties until after trying to reference them, you may need to quit the module and reopen it.
  2. I would check the following in a Report Action:
    { GetProperty(“playerSide”) }
    { GetProperty(playerSide + “_language”) }
    { GetProperty(mySide + “_language”) }, where you have set mySide = RED, say, in a Marker


GetProperty had a bug that should be fixed in the next build.

In terms of the original issue, it is basically adding a translation facility for images. This is a request that has been around for a long time:-
Bug 1895 - Expand module translation mechanism to include images

It would be better to handle this as a translation issue than having every person roll their own. It is something I have been meaning to get back to.

Sounds like a reasonable suggestion. I have added

Bug 4717 - Change Layer Follow Property name to be an Expression.

Any other places you have noticed would benefit by allowing an in-line expression?

At the top of my head only one: text labels (in the “Text” prompt line). But now that I know you are on the case I will do some editing these days and report here if I find anything else.

P.S. I did introduce layers to change language in MH, but that’s a global change: everybody will still see German or Italian or English (no individual choice). Any new feature you might come up with to allow individual customization of language - barring having to download different versions of the module - will be great.

I tried with the latest 3.2.0 build (8313) and, thanks to the fixed GetProperty, I am happy to announce that something like $playerSide$_language works pretty well now!

In other words: different sides in a network game (e.g. RED and BLUE) can have images showing in their preferred language, independent of each other. The solution is simply the one mentioned in the OP, but I can write it down again and post a demo module if anybody is interested.