VASL Map Online Problem/Suggestion Form

[bprobst]

Seems to be an issue with the LOS tool for Bd 08 (v6.5, VASSAL 3.5.8, VASL 6.6.3):



There is no reason for Z5 to block the LOS from X4.

Never mind. I figured out what the issue was. The other end of the LOS string was at Level 2 in my head, but at Level 0 in the game, so obviously it claimed (correctly) that the LOS was blocked.

A separate minor issue with bd08, nothing to do with LOS: if you remove the land from one board edge, the white "shoreline" gets left behind:



Compare with the same transform on bd07, where all land info is removed:



Not really a problem as such, but it's strange to have a thing work one way on one board and differently on a different board.

 

[Michael R]

A separate minor issue with bd08, nothing to do with LOS: if you remove the land from one board edge, the white "shoreline" gets left behind

How does one remove the land from one board edge?

 

[bprobst]

It's an option in the board SSO for each board that has a river.

 

[EJ1]

Seems to be an issue with the LOS tool for Bd 08 (v6.5, VASSAL 3.5.8, VASL 6.6.3):

View attachment 20338

There is no reason for Z5 to block the LOS from X4.

Never mind. I figured out what the issue was. The other end of the LOS string was at Level 2 in my head, but at Level 0 in the game, so obviously it claimed (correctly) that the LOS was blocked.

A separate minor issue with bd08, nothing to do with LOS: if you remove the land from one board edge, the white "shoreline" gets left behind:

View attachment 20339

Compare with the same transform on bd07, where all land info is removed:

View attachment 20340

Not really a problem as such, but it's strange to have a thing work one way on one board and differently on a different board.

Kinda cool, in a way. Looks natural---like merging currents.

 

[Michael R]

I recently used the VASL tunnel counter for the first time. I notice that it is missing a property that mine counters have; the property that causes the mine counter to stay in the hex when counters stacked above it are dragged away. When I drag a stack of counters away from a hex containing a tunnel counter, the tunnel counter moves with them.

 

[andrea pagni]

would be possible to add a label to ? counters, so to make some "realistic" looking fake vehicles?

 

[von Marwitz]

would be possible to add a label to ? counters, so to make some "realistic" looking fake vehicles?

Counter-question:
Are labels (or their outlines) displayed to the opponent at all if the labelled counters are Concealed?

I think not.

Furthermore, you could use this workaround:

Use a Blank counter of the nationality's color, label it as you want and use a "?" or "Dummy" as the Label ON that counter for Line 2.



von Marwitz

 

[Psycho]

View attachment 20476

von Marwitz

 

[DougRim]

I recently used the VASL tunnel counter for the first time. I notice that it is missing a property that mine counters have; the property that causes the mine counter to stay in the hex when counters stacked above it are dragged away. When I drag a stack of counters away from a hex containing a tunnel counter, the tunnel counter moves with them.

This has been fixed and will be in 6.6.4

 

[ScottRomanowski]

VASL 6.6.3 reports a LOS blocked but the point indicated is Open Ground. Using board 03 (v6.4) LOS from W4h1 to Z1/Y2/Z2 is blocked in W4, but zooming in shows that the LOS does not touch the hill artwork. (Purple = good LOS, black = blocked LOS.)

 

[DougRim]

Blame it on the pixels. When you compare the line in your two images you can see that it shifts a bit in the highly zoomed in image. I am pretty sure this has to do with the fact that the geometry of the map and the geometry of pixels don't align 100%. Extreme distances and extreme zooming can produce these issues.

I am not sure that there is much that can be done about it.

I would also note that the width of the string is a factor here. You have zoomed the map but not the string so it is relatively much thinner than at no zoom. Given the extent of your zoom this probably makes a difference.

And of course, it is worth noting that VASL los does not check for obstacles on both sides of the thread. If it hits an obstacle, then boom the los is blocked. I think that is happening here.

 

[von Marwitz]

VASL 6.6.3 reports a LOS blocked but the point indicated is Open Ground. Using board 03 (v6.4) LOS from W4h1 to Z1/Y2/Z2 is blocked in W4, but zooming in shows that the LOS does not touch the hill artwork. (Purple = good LOS, black = blocked LOS.)
View attachment 20783


View attachment 20784

I have to remember that vicious LOS for my next FtF-playing of "Gavin Take"...

von Marwitz

 

[DougRim]

The white motorcycle counters and the white sidecar counters do not have the "motion" option in their menu, and CTRL+O does not add a Motion counter. I checked the white dozer counters; they have the Motion option in their menu.

Fix for this will be in 6.6.4. It will not be in the move submenu; it will be a top level item.

 

[Eagle4ty]

VASL 6.6.3 reports a LOS blocked but the point indicated is Open Ground. Using board 03 (v6.4) LOS from W4h1 to Z1/Y2/Z2 is blocked in W4, but zooming in shows that the LOS does not touch the hill artwork. (Purple = good LOS, black = blocked LOS.)
View attachment 20783


View attachment 20784

Not only does the LOS string have to touch the obstacle to block LOS but the obstacle must be visible on both sides of the LOS string (A6.1).

 

[DougRim]

Not only does the LOS string have to touch the obstacle to block LOS but the obstacle must be visible on both sides of the LOS string (A6.1).

I understand the ASL rules. But that is not how the VASL los string works. This is not new; it has been that way for a long time and disclosed as such.

 

[Ahriman667]

First of all a BIG thank you to the VASL team.

Using VASSAL 3.6.2 and VASL 6.6.3.1.

Not sure if this has been noted before, but the other day I noticed that the Overlay's have an issue where they plop themselves on top, and you can not select the unit(s) underneath them. So far I've tried this wi rubble, OBA, and Axis/Allied control markers. Is this a new bug? Is anyone else experiencing this?

 

[DougRim]

First of all a BIG thank you to the VASL team.

Using VASSAL 3.6.2 and VASL 6.6.3.1.

Not sure if this has been noted before, but the other day I noticed that the Overlay's have an issue where they plop themselves on top, and you can not select the unit(s) underneath them. So far I've tried this wi rubble, OBA, and Axis/Allied control markers. Is this a new bug? Is anyone else experiencing this?

By overlays, I assume you mean the draggable overlays that come from the Orchard Button on the toolbar and NOT those that come from (a) the Draggable Overlays extension (which any sane VASL user has installed) or (b) the BoardPicker Wizard Overlays button used when selecting boards.

The answer is in your statement of the problem. The overlays from the Orchard Button will literally sit on top of other counters (thereby preventing access to them as you describe). The solution is to move the overlay to the bottom: Select the overlay (a black border will show) if not still selected after being added. Shift-click should select it. Then tap the down arrow key. That will move the overlay to the bottom and the units will now be available for selection. Just tested it with 3.5.8/6.6.3.1 and it worked as described.

 

[ScottRomanowski]

I've noticed that too, and devised the same solution, @DougRim . A note to everyone else, if you've got an overlay that you've moved to the bottom, then you drag a control draggable overlay on to some units there, the control overlay will be on top of everything. If you then blindly move it to the bottom, it'll apparently disappear -- the other overlay will be on top of it. Position the control overlay below the counters and above the other overlay. When I first discovered this, I thought the control overlay was being deleted, and accumulated a small stack of them before I realized what was really happening.

 

[Ahriman667]

By overlays, I assume you mean the draggable overlays that come from the Orchard Button on the toolbar and NOT those that come from (a) the Draggable Overlays extension (which any sane VASL user has installed) or (b) the BoardPicker Wizard Overlays button used when selecting boards.

The answer is in your statement of the problem. The overlays from the Orchard Button will literally sit on top of other counters (thereby preventing access to them as you describe). The solution is to move the overlay to the bottom: Select the overlay (a black border will show) if not still selected after being added. Shift-click should select it. Then tap the down arrow key. That will move the overlay to the bottom and the units will now be available for selection. Just tested it with 3.5.8/6.6.3.1 and it worked as described.

I've noticed that too, and devised the same solution, @DougRim . A note to everyone else, if you've got an overlay that you've moved to the bottom, then you drag a control draggable overlay on to some units there, the control overlay will be on top of everything. If you then blindly move it to the bottom, it'll apparently disappear -- the other overlay will be on top of it. Position the control overlay below the counters and above the other overlay. When I first discovered this, I thought the control overlay was being deleted, and accumulated a small stack of them before I realized what was really happening.

Roger to all that. I realized how to work around the issue, but I don't remember this happening in previous versions of VASL. For EG the game I'm playing now was created in an earlier version, and the Orchard Button draggable overlays worked as intended. They dropped to the bottom of a stack. Not sure what happened between the version updates.

At any rate, I'm now using the hideable-control-markers-1.8 extension for control points.

 

[DougRim]

Roger to all that. I realized how to work around the issue, but I don't remember this happening in previous versions of VASL. For EG the game I'm playing now was created in an earlier version, and the Orchard Button draggable overlays worked as intended. They dropped to the bottom of a stack. Not sure what happened between the version updates.

At any rate, I'm now using the hideable-control-markers-1.8 extension for control points.

It may well be a VASSAL change as well. Since there is an easy counter management way of dealing with this, I am not inclined to try and "fix" the situation.

The hideable control markers is a neat little extension; good for CG!