I am playing a couple of Axis and Allies type games with Areas that are set to change color by an action item, when control changes. During online play the opponents do not see the Highlights change to the new color. This used to work, within the last 3 updates. If you need the Module I can provide it.
Here is one of the Modules, where the Highlighting will not change color for the other players.
First off, the module reports the errors
- Bad Data in Module: Piece: FrenchDestroyer A2D2 (1) Trait: Send To Location - Sea 93 SF => FSF93MS Source: Region=SFDestroyer Error: Region not found.
- Bad Data in Module: Piece: FrenchCruiser A3D3 (1) Trait: Send To Location - Sea 93 SF => FSF93MS Source: Region=SFCruiser Error: Region not found.
- Bad Data in Module: Piece: Mongolian Infantry A1D2 (2) Trait: Action Button - Change # of Units - Ctrl+V Source: X position[$OldX$]=OldX Error: Numeric field contains a non-number.
- Bad Data in Module: Piece: Mongolian Infantry A1D2 (2) Trait: Action Button - Change # of Units - Ctrl+V Source: Y position[$OldY$]=OldY Error: Numeric field contains a non-number.
Also, the normal way to define a setup is not to make multiple boards, but rather embed a .vsav file as a Predefined Setup. This has the advantage that you do not need to maintain two - more or less identical boards, and that it is easier to add new set-ups.
The way you change control of a zone is somewhat convoluted. Your control markers could be
- Control marker
- Set Piece Property
- Name:
Current - Commands:
- Initialise
- Type:
Direct - Key:
initialise - Value:
{GetString("Highlight").substring(0,GetString("Highlight").length()-1)}
- Type:
- German
- Type:
Direct - Key:
setGerman - Value:
{"German"}
- Type:
- Japan
- Type:
Direct - Key:
setJapaneese - Value:
{"Japaneese"}
- Type:
- … and so on for the rest
- Name:
- Layer
- Images:
German.pngJapaneese.png- …
- Names:
GermanJapaneese- …
- Follow:
true - Expression:
{Control=="German" ? 1 Control=="Japaneede" ? 2 : ... }
- Images:
- Set Piece Property
- Name:
Previous - Commands:
- Store
- Type:
Direct - Key:
setPrevious - Value:
{Current}
- Type:
- Store
- Name:
- Set Global Property
- Name:
Highlight - Locate:
Named Zone - Zone Name:
{CurrentZone} - Commands
- Type:
Direct - Key:
setHighlight - Value:
{Current+"H"}
- Type:
- Name:
- Set Global Property
- Name:
{GetString("Current")+IPC}Note, an expression - Commands:
- Type:
Increment - Key:
incrementCurrentIPC - Value:
{ZoneIPC}
- Type:
- Name:
- Set Global Property
- Name:
{GetString("Previous")+IPC}Note, an expression - Commands:
- Type:
Increment - Key:
decrementPreviousIPC - Value:
{-ZoneIPC}
- Type:
- Name:
- Global Hotkey
- Key:
moveIPCs - Global key:
moveIPCsHotkey that asks IPC counters to move to their current value
- Key:
- Trigger Action
- Key:
takeControl - Action keys:
setHighlightincrementCurrentIPCdecrementCurrentIPCmoveIPCs
- Key:
- Trigger Action
- Key:
Ctrl+G - Command:
German - Action keys:
setPrevioussetGermantakeControl
- Property:
{Current != "German"}
- Key:
- Trigger Action
- Key:
Ctrl+J - Command:
Japaneese - Action keys:
setPrevioussetJapaneesetakeControl
- Property:
{Current != "Japaneese"}
- Key:
- … and so on for the rest
- Set Piece Property
In this way, you do not have to take care of all the possible combinations of previous owner and the future owner, and it may speed up the calculations quite a bit (currently, it is a bit slow). Also, you only need that one marker.
Now, whether that will solve your problem with other on-line players not seeing the change of control is a different matter, but it will certainly make it easier to track down the problem.
Note, if you right-click (Mouse-2) your opponents user name in the panel Current game room, and select Syncronize, then the zone will be highlighted correctly - after asking if you want to save the game, closing the map, and asking whether to start a log file. Perhaps this point to a deeper issue in Vassal. But first, I would simplify the logic to make sure that it’s not there things are going wrong.
Yours,
Christian
Thanks Christian for the info, that is helpful.
I am not a programmer (retired System Admin), even though I “try” to make Vassal Modules, for my friends.
I knew about the 4 errors and had fixed the errors prior to your response, in my next version. I sent the file we had been playing with when the Highlighted areas would not refresh for other players, online. And yes we were using sync, but if another player changed, I had to save and restart the game , as I was the Host. I think it was 3.7.24 or 23 that this worked correctly. We were playing a saved game.
I followed your guide to make changes and 2 parts did not work. The Country control markers no longer can be changed and the Previous owner always gives an error and does not find the variable previous owner. I have tried multiple ways around this with no luck.
As for the Multiple boards vs VSAV Predefined Setup, I have run into the problem multiple times, that Refreshing the VSAV file that is predefined, does not always update all fixes. So I was trying a different way around this problem, instead of always having to redo a VSAV file. 
Updated small setups is OK, but the bigger setups is a pain. Also, the advantage of having the Free setup vs 1940 setup, is if I change the Map, I do it in the 1940 setup and then I delete the Free setup and Copy the 1940 setup and rename and I am done. I now have two identical maps and the only difference is the pieces that are at Start, are tied to the 1940 map. And yes, I need to use more Prototypes on my setup pieces.
Thank you,
Tim
I had to put the Layer expression in to AI to get it to format right. Also, move the Previous variable to the top of the list. Now everything is working.
Thanks again Christian.
Just to be certain - do mean to say that the zone highlight also works now?
If so, I guess the problem was somewhere in the logic you used before. Interesting.
This is a bit of a problem, and recent discussion illustrate that.
Personally, I like to keep the set-up data outside of the module - for example in a spreadsheet or JSON, and then I use the Python script vsavsave.py (using my Python module pywargame) to write the .vsav file. In that way, the .vsav files are always in sync with the module (.vmod). Now, vsavsave.py is not omnipotent, but it can do a fair bit. See also this post.
Yours,
Christian
I just got someone to help to test the Highlight online. The Answer is the Highlighting does not change. Also, for some reason the control Markers no longer change, too. New pieces and movement of pieces works fine. As I said this worked with Vassal 3.7.23 or 24, but not now. And yes using the Sync does make the change, but this is a short term solution, IMHO.
Tim
Please check which of Vassal 3.7.23 or 3.7.24 was the last working version.
Could you share the updated module? Or is it at the place as before?
Yours,
Christian
Just tried the previously linked module with 3.7.23 on two different machines - connected to the same room - one Debian GNU/Linux “sid” and the other MacOS Tahoe.
When I change control of a zone, the control marker changes on the other client, but the zone highlight does not. There’s no message in either errorLog that would indicate a problem.
So I guess the problem was also there in earlier versions of Vassal, or if OP uses different OSs and the zone highlight work there, then it may point to a third-party (binary) library.
But @Wyldman68 (Tim), could you share your updated module? That may help pin down the problem.
Yours,
Christian
I went back and found a Module that still works, with Highlighting. Also, tried several different versions of Vassal going back to 3.7.20.
This version works:
and this version that does not work:
Looks like using the multi-board setup screws up Highlighting change during online play. Removed the multi Board setup from 4.5.0 and the Highlighting works again.
Tim
Is it true, then, that version 4.5.0 - which has the “multi-board” - does not work on any Vassal release you tried? Or did it work on some release? If so, which one then? That will help pin down the issue.
A possible explanation could be that the command to update the zone property does not properly scope the change to the right map/board/zone, but rather simply does map/zone, and so the change up on the wrong board. Perhaps a way to test that hypothesis will be to change the order of the boards to the opposite what it is now. Of course, it won’t solve the problem but it will help pin it down.
Another reason to not use different boards to set up a scenario 
Still, if you did a version along the lines I previously outlined, I’d like to see why that doesn’t work as expected, so if you can share that, it would be great.
Yours,
Christian
Christian,
Here is my update of the Original file.
Tim
Edited the file. Also, Christian just add another board and the Highlight no longer works online.
As for using the file with the Multi-board, it did not Change Highlighting with Vassal 3.7-20 to 26.
I thought we had played with a Multi board file before and it worked, but I could be wrong.
I will try changing the board order and see if that works. The Multi-board made fixing setup changes easier, but broke the Highlighting.
Thank you for the assistance.
Tim
Hi,
I made some edits to your 0.1.7 version - you can find them here. Please take this soon, as I will delete the file.
Some comments:
- You mix and match
$...$or BeanShell code. Generally, one should not use the$,,,$except in very special circumstances. - You got some of the logic wrong when you implemented my above suggestions. This is why it didn’t work for you. Take a look at the edits I did.
- I’ve added a bunch
Reporttraits so one can follow along as the commands progress. You can remove these when you are satisfied that things work as expected.
Also - and that’s a very common American thing - when referring to IPCs owned by Japan or France, it should be Japanese and French IPCs (Adjective form) - just like American or German IPCs (you’d probably never write America IPCs.) No idea why people can not seem to wrap their head around that
Yours,
Christian
Tried adding a board to my modified module. With the 1940 Setup board first, the highlight update works fine. If the 1940 Setup board is second, then the zone highlight does not work. I think this points some problem in Vassal that the highlight change is wrongly addressed on the second client. That is, the second client gets a message with an address like Map/Zone, but it should probably be Map/Board/Zone so that the right zone can be addressed.
If I save the game (in a .vsav) on both clients, then on the client I made the control change in, I see in the save file
GlobalProperty ;Highlight Newfoundland Labrador No Setup Map;BritishH;
GlobalProperty ;Highlight Newfoundland Labrador 1940 Setup Map;DutchH;
while on the other client (the one that did not update the highlight correctly), I see
GlobalProperty ;Highlight Newfoundland Labrador No Setup Map;DutchH;
GlobalProperty ;Highlight Newfoundland Labrador 1940 Setup Map;BritishH;
so the change does end up in the wrong board. On the other hand, it seems the message sent is correct in that it contains the board name (the message originated from 1940 Setup but ends up in No Setup board).
In some sense, this points to a much deeper problem - in that any GlobalProperty could end up in the wrong board - not just the zone highlight property.
Yours,
Christian
I run the modified module on two clients and connect to the same server. On one client, I run Vassal through a debugger, and I set up break-points in
VASSAL.build.module.properties.GlobalProperty.decode,VASSAL.build.module.properties.GlobalProperty.encode, andVASSAL.build.module.properties.ZoneProperty.getPropertyId
I change control of one zone on the client that is not running the debugger, and I expect to see a break in VASSAL.build.module.properties.GlobalProperty.decode when the client receives the message from the other client. However, no such break ever occurs (with the right kind of command, that is).
Then I change the control on the client that is running the debugger, and I expect to see a break in VASSAL.build.module.properties.GlobalProperty.encode when the client ships off a message to the other non-debugged client, but that break never occurs.
At no point do I see a break in VASSAL.build.module.properties.ZoneProperty.getPropertyId.
So something fishy is going on. When either client changes a global property, then that change should be propagated to the other clients, but that never seems to happen in this case. How can that be?
It is kinda clear why it works with a Syncronise action, because that means the client requests a full save state from the other client, which will include updates to global properties. But why are global property changes not propagated?
Very weird indeed.
Yours,
Christian
Update (and possible explanation and fix)
Debugging a bit further, I set a break point in VASSAL.build.module.properties.ChangePropertyCommandEncoder.encoder and execute a control change on the debugged client. What I then see is that method is called with a ChangePropertyCommand, that has the container id Map:Southeast Mexico - which also matches the container source id of Map:Southeast Mexico. I think we’re closing in on the culprit. The above container IDs should really be Map:1940 Setup:Southeast Mexico, so that the change goes to the right zone in the right board in the right map.
Doing
[] print container
container = "VASSAL.build.module.map.boardPicker.board.mapgrid.Zone@117e987c"
tells us the source container is a Zone - OK, no surprise. Then
[] print container.getMutablePropertiesContainerId()
container.getMutablePropertiesContainerId() = "Map:Southeast Mexico"
tells us that the method VASSAL.build.module.map.boardPicker.board.mapgrid.Zone.getMutablePropertiesContainerId is probably wrong. Indeed, if we look at the code, we see
@Override
public String getMutablePropertiesContainerId() {
return (getMap() == null ? "" : getMap().getMapName()) + ":" + getConfigureName();
}
which should probably be
@Override
public String getMutablePropertiesContainerId() {
return ((getMap() == null ? "" : getMap().getMapName()) + ":"
(getBoard() == null ? "" : getBoard().getName()) + ":"
+ getConfigureName());
}
With that, the property would be identified by the full path to the Zone, not skipping the board as is currently done.
However, the above change is, I fear, far from trivial. It will have vast consequences because Vassal with our without that fix will not really be compatible (unless other precautions are taken). On the other hand, this change will not affect saves or logs, because they use a different mechanism to encode and decode property values. I think I will leave it to someone with a better overview of the consequences - c.f. @uckelman - to decide if this fix should be made or not.
If the fix should be made, then it should probably be made now so that it is ready for the upcoming 3.8.0 release.
Incidentally, the above analysis points to a work-around for your problem - albeit a rather tedius one: In your second board, rename all zones so that they do not have the same names as those in your first map.
Yours,
Christian
Hi,
I had just made Sure the German and USA part worked on the Module. I was working on another project, that had more importance to me and had not finished testing
Like I said I am not a programmer and I do cobble together Modules and Beanshell, but will try to use your suggestion.. This was module came from someone else I just added the Highlighting, different Graphics and IPC tracking. I put several items on a single map due to one of my friends only playing on a Laptop. Also, there was no documentation for setting up Highlighting and I had to look through code in couple of modules and forum posts. I know what i had written was not efficient, but it worked for what I used it for.
As for Japan vs Japanese, I was shortening the variable, because I don’t care about Variable names vs grammar. (Math/History /Wargamer for 46 years, suck at grammar). If you had looked, I had actually edited my post with a newer File that I had fixed, Japan, ANZAC and BritishP Highlighting/Control.
Thank you for your assistance.
Tim
I’ve made a pull request with the above proposed change. You can find development builds with this change at
I suggest you give that build a try and see if that solves your problem. If it does, then your feedback will help get this change in.
Yours,
Christian
I took the one you posted above (0.1.7), and modified that. Wasn’t that the last one? It still had a lot of issues with mixing $...$, global and local properties, and so on. The highlight control wasn’t actually quite doing what you thought it did. In the modified version (of 0.1.7) I’ve fixed these things, and simplified your logic quite a bit.
As a Maths person, I should think that you would appreciate clarity over brevity You could of course abbreviate Japanese IPCs to simply Ij, but I’m not sure that would be very maintainable. Dirac’s formulation of General Relativity is famously compact, but not all the legible.
The other thing is, I hear a lot of Americans use phrases like “Italy girl”, or “Sudan car” - it kinda strikes me as extreme laziness at best, ignorance of the world at worse - neither is a good thing.
Please give the above development build a try and see if it solve the highlight issue when you have more than one board defined in the map.
Yours,
Christian