VASL Map Online Problem/Suggestion Form

[ibncalb]

Which scenarios require a mix of olive groves and orchards? The only ones I can think of are AF and they have custom maps.

 

[von Marwitz]

Are we talking about the one-hex draggable overlays found under the Draggable Overlays button (Orchard) on the toolbar?

That was my idea.

Probably easy to accomplish as it would mean adding only one sample of the "Olive Grove" existing artwork which is already used by the Terrain Alterations change all Orchard to Olive Groves.




I don't think that the overlay extension needs to be worked on, because most changes will be covered by the "Change all Orchards to Olive Groves" Terrain Alteration.

What the latter cannot cover cases, in which at the same time Orchard Overlays would be in use. I reckon, that in such cases, the Transformation would not extend to the overlays (such as O5 for example). The easiest fix for this would be likely to manually cover an untransformed O5 with 5 individual single hex draggable overlays with Olive Grove artwork.

von Marwitz

 

[DougRim]

Probably easy to accomplish as it would mean adding only one sample of the "Olive Grove" existing artwork which is already used by the Terrain Alterations change all Orchard to Olive Groves.

View attachment 28246

I am having trouble finding that transformation. Could you point it out exactly? Thanks.

 

[von Marwitz]

I am having trouble finding that transformation. Could you point it out exactly? Thanks.

Hmm, I could have sworn that such a transformation exists. But going through the menues, I could not find one either.

I wonder where @Commissar Piotr got that artwork for his screenshot from. It proves that it must exist somewhere in VASL.

Thinking about it, I seem to recall a dim memory of what this artwork in the screenshot might be supposed to depict:

Didn't have BFP some geo boards with Terrain designated as "Light Orchards"?
I checked - yes! Board BFP N for example.

I think, this is it. Which would mean that at this point no artwork at all for Olive Groves exists. And this would also solve the riddle, why it has so far not been covered by VASL.

In turn, this means that there is no Olive Grove artwork in the "official MMP canon".

This gives rise to the more basic question, if one wanted to introduce a new artwork for Olive Grove for VASL purposes. Hmm. Might probably create more confusion that benefit. I don't know.

von Marwitz

 

[apbills]

I was looking at the Biazza Ridge map and see it has 3 different depictions for orchards. 2 are the normal 4 blotch orchard, only with slightly different colors and the third has 5 blotches. I do not own the module so I do not know if this is representing Olive Groves.

 

[von Marwitz]

I was looking at the Biazza Ridge map and see it has 3 different depictions for orchards. 2 are the normal 4 blotch orchard, only with slightly different colors and the third has 5 blotches. I do not own the module so I do not know if this is representing Olive Groves.
View attachment 28258

As BFP, this is also a TPP.

But I think we don't have any Olive Grove artwork at all in the "official" MMP canon.

von Marwitz

 

[apbills]

There would be no official artwork from MMP unless they actually made a module and provided the new artwork within that module, or updated the Chapter B rule to indicate what exactly that would be. As it stands, all that is there is B14.8 stating that an SSR may modify all orchard hexes to be Olive Groves. They do have Olive Groves in Primosole Bridge, but they use the original Orchard artwork. Perhaps that is getting updated as part of the module I have heard about that includes a revision to that historical study.

With that said, it may be useful to look at TPP products to see what others have done, if indeed they have, in depicting Olive Groves within their products. It may not be official, but it is worth looking at to get some ideas. There is a reason for VASL extensions when you would like something in VASL that is unofficial.

 

[von Marwitz]

With that said, it may be useful to look at TPP products to see what others have done, if indeed they have, in depicting Olive Groves within their products. It may not be official, but it is worth looking at to get some ideas. There is a reason for VASL extensions when you would like something in VASL that is unofficial.

Fair enough.

What I believed to be "Olive Grove" artwork turned out to be "Light Orchard" artwork to reflect a terrain type introduced by BFP as a TPP.

So, as we have established that there is no specific MMP artwork for "Olive Groves", is there any artwork by TPPs? If yes, does it differ between various TPPublishers? If yes, would one of these be prefereable over the other? Or would one need to have several types of "Olive Grove" artwork?

Suggestion to the Mods:
Maybe it is a good idea to cut out the discussion about Olive Grove artwork beginning with this post from this thread and create a separate one for it?

von Marwitz

 

[DougRim]

Or would could simply leave it to @Commissar Piotr to produce some artwork. Until it exists, there will be no transformation available.

 

[DougRim]

I am dabbling with J212 which features Pine Woods (B13.8).

It appears, that VASL has no Terrain Transformation that changes Woods to Pine Woods, while it does support Light Woods and the Jungle variants. The missing support for Pine Woods affects LOS, i.e. the LOS-tool cannot factor in the added height of Pine Woods as a LOS Obstacle.

I admit that Pine Woods come up rarely, but maybe support for this can be implemented rather easily for VASL v6.6.7 as the code probably does not need much more (what do I know...?) than something like:

If Woods = Pine Woods, then LOS Obstacle (not 1 but) 2 Levels.

von Marwitz

The new Pine Woods transformation will be in VASL-6.6.8-beta9 (soon to be released but not yet) and subsequent versions. As per the previous discussions on this thread, it was quite simple to implement. It makes no visual change to the map; the only change is that the los engine will register Pine Woods hexes as having a height of 2 which will affect los results in the way that it should.

 

[GeorgeBates]

The new Pine Woods transformation will be in VASL-6.6.8-beta9 (soon to be released but not yet) and subsequent versions. As per the previous discussions on this thread, it was quite simple to implement. It makes no visual change to the map; the only change is that the los engine will register Pine Woods hexes as having a height of 2 which will affect los results in the way that it should.

Now you've sold me.

 

[Vic Provost]

Hi guys, I just want to thank the guys who do all the hard work to update VASL and get new boards into the system so we actually can play on-line opponents in new products. I love VASL but, my only complaint with VASL is there seems to be no cooperation between MMP and VASL when they publish a new ASL Module or AP with physical boards, it takes MONTHS for them to get the boards into the VASL system so we can use them. Why can't someone from MMP send them the boards they playtested the module with? I assume MMP has some cooperation with VASL to get the playtest going in the first place so why make us all wait in the digital age? I have way more friends and opponents online than I have here in my town, I'm sure most will be in similar circumstances. Please find a way to get this done in a more timely manner. VASL helps promote MMPs games as many more people can play them and have a real opponent. Enough with solo play when I have dozens of opponents who want to play me. Can't wait to play TotR and WO#15 sometime this Spring, been 2 months since they came out. Sorry for the rant, it just seems we can find a better way, I hope someone does...

 

[PresterJohn]

"seems"????
I think it is because of a few things. Firstly play-test boards are hardly good enough for final release. I have looked at the amount of work that goes into the release versions of the boards and I have nothing but respect for the time it takes to do all the transformation options. Also volunteers are a precious commodity and I can only imagine they take to timelines just like cats. I also expect that MMP consider VASL and VASSAL a resource that does a good job of looking after itself.

 

[Vic Provost]

"seems"????
I think it is because of a few things. Firstly play-test boards are hardly good enough for final release. I have looked at the amount of work that goes into the release versions of the boards and I have nothing but respect for the time it takes to do all the transformation options. Also volunteers are a precious commodity and I can only imagine they take to timelines just like cats. I also expect that MMP consider VASL and VASSAL a resource that does a good job of looking after itself.

I hear you on volunteers, it is harder and harder to get good platesters to work with you. I know VASL tries very hard to deal with everything they have to do to keep the system upgrading into the future, I just have to be patient but you don't have as much when you get older, so it goes.

 

[von Marwitz]

Preparing for BFP67 Coke Hill.

Issue found:
SSR require PTO Terrain (Light Jungle) with Roads and Bridges existing normally.
Even if Woods-Roads are selected to be "normal", VASL (v667, VASSAL v377, board 50 v7.0) transforms them to Paths.

View attachment 28043


von Marwitz

Preparing DB083 Block to Bataan.

Encountering the same/similar problem:

By SSR there is PTO Light Jungle in effect. I selected Roads and Woods Roads as "Normal". Nevertheless, the Roads disappear and Woods Roads are turned into Paths. Board version 37(v6.5).

von Marwitz

 

[Vic Provost]

Preparing DB083 Block to Bataan.

Encountering the same/similar problem:

By SSR there is PTO Light Jungle in effect. I selected Roads and Woods Roads as "Normal". Nevertheless, the Roads disappear and Woods Roads are turned into Paths. Board version 37(v6.5).

von Marwitz

Hello and sorry about this, I am looking at SSR #1 and it clearly states the Roads should still exist. Tom told me when you switch to PTO as the theater sometimes it voids stuff, not sure if what he was referring to was like insisting the road is a path. Maybe try putting together the scenario from scratch and don't change to PTO, this should still show the road and you should be OK. I'm not a VASL expert to be sure, just trying to help from my limited knowledge. I hope it works out and have fun.

 

[von Marwitz]

Hello and sorry about this, I am looking at SSR #1 and it clearly states the Roads should still exist. Tom told me when you switch to PTO as the theater sometimes it voids stuff, not sure if what he was referring to was like insisting the road is a path. Maybe try putting together the scenario from scratch and don't change to PTO, this should still show the road and you should be OK. I'm not a VASL expert to be sure, just trying to help from my limited knowledge. I hope it works out and have fun.

No need to be sorry as the scenario design has nothing to do with VASL and its troubles.
My intention was merely to point out VASL issues before the new v668 will be released soon, so that possibly the matter can be addressed for that version.

I made the necessary adjustments for my VASL file manually including the (one) road which exists - you can have a look at the ASL Scenario Archive website for a map picture and a VASL file (leaving out VC/SSR to honor your copyright).

von Marwitz

 

[von Marwitz]

Precise offboard placement of counters, labels, etc. with VASL v6.6.8 is A LOT more difficult up to nigh impossible compared to previous versions (with or without the Board Zoomer extension).

See here for more details.

von Marwitz

 

[von Marwitz]

Taking this over here from the Board Zoomer extension thread as this seems to be more an issue of VASL v6.6.8:

There is a bit of proportionality error, meaning if you move something by a lot then placement will be off by a lot. So I was sometimes able to "nudge" things a bit more accurately by clicking, dragging just a little, and dropping so the placement error wouldn't be as large for a smaller movement. But even then there seemed to be odd jumps/offsets that would appear even in these small movements

Yes, this mirrors my observations.

Before v6.6.8, I had to nudge - sticking to the example - Perimeter Lines to the desired position. After a handful of attempts, this worked. With v6.6.8, I began "closing in" towards the correct position by nudging, when at some point the Perimeter Lines suddenly "jumped" off position for the length of several hexes.

Now to the - more general - issue of snapping to grid offboard:

It was proposed to add extra boards (for example plain DTO boards) to serve as "offboard" areas to tackle the snapping issue.

I believe this can only serve as a temporary workaround. This is why - please have a look at the illustration below:




The offboard margin has been increased years ago (which was definitively necessary). Yet still, for larger scenarios the available default space might get thight - if you needed space for another "row" of counters, it is not there.

If the "standard" onboard grid would be extended to offboard, even more offboard space would be required to place the same number of counters, because then the offboard placement "options" would be limited to the available "hex-grid snapping options".

In the illustration, you can see, which method I have used to align the offboard counters and labels in the past, which allowed for mor density. Step 1 was to place Perimeter Lines as a temporary aid to alingn the counters. Step 2 was to pull the counters to place them along those Perimeter Lines. The spacing reference between two counters was handled by the width of a Movement Flag of that counter. "Nudging" counters, labels etc. into the correct and prcise position was necessary but possible in the past.

But even the "snapping" routine in pre v6.6.8 versions has never been perfect. This is evidenced, if you try the following: Align a row of counters as per the above described method. Then mark the entire row of counters. Next move the marked row of counters as a group. When released at the new position, some of the counters will be "out of line".


This brings me to propose the following improvements:

The precision/reliability to snap correctly would need to be improved.
This was no issue onboard pre v6.6.8 and seems to be somewhat of an issue onboard in v6.6.8, which I have not yet used in actual gaming practive.
This was an issue offboard pre v6.6.8 since times immemorial but a bearable nuisance and has turned into a serious issue offboard in v6.6.8 going so far that precise counter placement offboard is a real PITA to nigh impossible.

The first priority is to restore the snapping akin to the standard of v6.6.7 while maintaining the basically new excellent feature of v6.6.8's improved zooming & snapping options.

Secondly, onboard and offboard areas should not have identical grids (while I am not sure of the nature of the pre v6.6.8 offboard grid. There has so be some form of grid, because otherwise after having moved a row of marked counters as a group offboard, none of them should be out of line).

Thirdly, one could think of implementing the possibility to define a "custom margin" as the offboard area, which needs to somehow be part of the VASL file. In ye olde days, this has been a completely insufficient 200px, currently, it is 400px which is ok for setups of small scenarios but can be insufficient for large ones. I dimly recall that there is the theoretical option to adjust that offboard margin manually somewhere in the Preferences. The problem with this is, that changes would only apply to your own setting but not to those of your opponent(s) or spectators. They would not be able to see/scroll "beyond" the standard margin of currently 400px. I believe the only way they could "see" counters "beyond" the margin would be to zoom out the general view setting (say to 67% or 44% currently offered in the dropdown menu). For that reason, the data for a custom margin would need to be part of the VASL file and not be handled by the Preferences. More precisely, the margin value of the preferences should be set by the data in the VASL file.

von Marwitz

 

[Pacman Ghost]

This was an issue offboard pre v6.6.8 since times immemorial but a bearable nuisance and has turned into a serious issue offboard in v6.6.8 going so far that precise counter placement offboard is a real PITA to nigh impossible.

I'm seeing the same thing. There should be no snapping off-board.

one could think of implementing the possibility to define a "custom margin" as the offboard area, which needs to somehow be part of the VASL file.

This would be the best way.