help needed for VASL 5.9beta under VASSAL 3.1.13

hi guys,

the latest beta-versions of VASL have some problems, presumably because several VASL-specific classfiles aren’t compatible with VASSAL 3.1.x.

I’m not a coder, so i’d like to request help from qualified folks! The latest VASL 5.9beta2 is available here: … L5.9beta2/
as a multi-part .rar or .zip file.

I have identified 7 problem areas, and can give more info on request:

  1. tank-turret images specified by Turreted.class display incorrectly when savedgame file is re-opened. Turrets display during the session when they’re dragged to the map, but display incorrectly when .sav or .log file is re-opened in 5.9/3.1.13 - they display correctly when the file is opened in VASL v5.8.1/3.0.18.

  2. map dialog shows 2 ‘Mark moved’ buttons, only one is specified in the buildFile. Both buttons function correctly. On ocaision, there will also be 2 ‘Choose boards’ buttons.

  3. verbose-mode LOS-string doesn’t report the correct # of Hindrance ctrs/map-hexes.

  4. in ‘deluxe’ mode, with ‘Night’ map-shading turned on, Area-of-Effect trait is not centered on the hex occupied by its Gamepiece. In VASL, the AoE trait is used to ‘un-shade’ a portion of the map, its effect is correctly sized (to the 300% magnification of ‘deluxe’ mode), but is centered 2.33 hexes left/2 hexes above its gamepiece. This offset is consistent, regardless of the specified hex-radius or its distance from the map’s top-left origin. In ‘deluxe’ mode, the AoE trait should center on the hex occupied by its gamepiece, which is not neccessarily the same as the stacking-point occupied by the gamepiece.

  5. Gamepiece w/ Invisible to Others (HIP) trait enabled reports in chat as

  • ? moves ? → ? *
    when moved. Does not occur when an ItO gamepiece is moved as part of a stack.
  1. Choose Boards > Terrain SSR > Transformations does not function.

  2. Map image capture tool grabs only the portion of the map currently visible in the map dlog, capture does not show entire map.

best regards,
Jeffrey Malter

Thus spake “jmalter”:

This one is not VASL-specific, and will be fixed in VASSAL 3.2.


Messages mailing list …

Post generated using Mail2Forum (

thanks Joel, #7 should’ve been a separate post to another section of this forum. But when 3.2 is released, VASL will fall further behind & possibly have add’l probs 'cos VASL-specific classfiles aren’t improved concurrently.

I hesitate to suggest this, ‘cos it can only increase the developers’ work-load, but from my POV the best solution would be to promote VASL-specific code such as ‘Turreted’ & ‘ASLBoardPicker’ into VASSAL, so that it would no longer live in VASL.mod - what is your opinion?

Thus spake “jmalter”:

The release of 3.2 should have pretty minimal impact on VASL, but you have
a valid concern here. Maybe we VASSAL devs need to communicate better about
what the changes are from version to version.

Specifically: At some point I’m going to overhaul VASSAL’s BoardPicker
(because it’s broken w/r/t resizing) and that would be a good time to look
into ASLBoardPicker also.

Regarding the general point, I’m open to moving classes into VASSAL which
might be of general interest to module designers; for classes which are VASL-
specific, however, we don’t want to bring those on board. I think you really
need a VASL maintainer who is paying attention to VASSAL releases, someone
who is not one of the current VASSAL developers, as we don’t have a lot of
spare bandwidth to devote to maintaining VASL right now.

On the other hand, I think that keeping VASL up-to-date with VASSAL isn’t
that big of a job. If someone who has the know-how stepped up as maintainer,
it wouldn’t involve a huge time obligation. There has to be somebody who
knows Java among the thousands of VASL users out there.


Messages mailing list …

Post generated using Mail2Forum (

I will try to take a look at those VASL issues and update the mod sources.

BTW, by debugging some of those problems, I have the feeling that they are not always related to VASSAL core changes, and could be fixed using only mod designing.
Anyway, being able to debug with the source code helps to understand where’s the issue.

Joel, I sent a request to be granted a submit access to VASL svn branches, I guess you should have received it by now.

Do we know if Rodney is still mergind changes in trunk/building mod ?

About the mod publishing, do we know someone who can update the main vasl web site ? (along with tuomo’s SK style maps)


Thus spake “wlk”:

You’re added. Welcome.

The only person I know who can do that presently is Rodney. I’m working,
slowly, on getting VASSAL to a new site; probalby when that happens we
should haul VASL along with us.


Messages mailing list …

Post generated using Mail2Forum (

I’ve added your correct SF account this time. (Note that when I sent mail to, it bounced.)

Yep, seems fine now, thanks !
Last thing, do I need to use that sf account/passwd for my svn branches ?

Thus spake “wlk”:



Messages mailing list …

Post generated using Mail2Forum (

Isn’t that an expected behavior ?

Yes, that was the intent. To notify you that your opponent is moving their Hidden units around (which is illegal in many games) without giving the actual location away.


Messages mailing list …

Post generated using Mail2Forum (

"it’s not a bug, it’s a feature " it caught me by surprise, though, 'cause it’s new in 3.1.

but there is one case in VASL where Invisible units must move ‘unreported’ - when an (Invisible) Armor Leader is stacked w/ a Vehicle, the presence of the HIP Armor Leader must not be betrayed when his Vehicle moves!

since the HIP units don’t report when they’re moved as members of a stack, i think we’re ok here.

Nice, bug autofixed ;)

I had a quick look at the shade issue, not sure if this is Vasl related since AreaOfEffect is part of VASSAL.
Maybe the zoom on hexes is causing the issue, but this is odd since it raises no obvious problems but that one.

  • EDIT * Issue identified, and is indeed in VASSAL AreaOfEffect classes.

somewhere in ASLBoardPicker there’s section on ‘Magnification’ that invokes enlarging the maps by 300% (deluxe size) & does something to correct the hexID reporting. I think it’s in this latter part that Area of Effect gets confused - AoE works fine when Magnification is not turned on.

I found the bug and fixed it, but I need to submit the changes to VASSAL branch, and ask for merge in trunk.
BTW, bug submitted under ID#2944858 on sourceforge.

It seems invisible units are now reported whether or not the piece is stacked with another. We’d like to turn off reporting of invisible pieces altogether in VASL. Is there a way to do that?