Hideable control and perimeter markers

[ibncalb]

Thanks guys, I was not aware of the cursor key to move the overlay in stack position functionality.

This has enabled us to continue to use overlays (which is perfect as we're so used to them we must have moved through FFEs unwittingly more than 10 times in the opening VOTG CG date).

It's clunky, I would prefer if the draggable overlays defaulted to "just above any real overlays position" which would obviate the rearrangement, but at least we can use the overlays now.

Thanks again.

 

[jyoung]

Thanks @apbills and all - I'm working on a new version, revamped the interface with counters dragged off drop-down menus instead of having to find them in the counter trays, plus expandable 1-6 hex area control markers (e.g. for CGs that set perimeters as 2 hexes within controlled strategic locations). It's not quite ready (not documented) but you can have a look here, and will think about what I can do to fix/avoid the problem above. If you click the Select button followed by the Update button it should update all the counters to their latest versions in the extension (it it works properly, you would see no change). Just remove the .zip extension from the module file below.

 

[PresterJohn]

I like the hideable control markers for use in normal scenarios to show possession of locations which is easily turned on and off. The dragable overlay nation markers are very large, not very opaque and obscure the terrain and can get caught up on top of counters. Perhaps it would be nice if the default dragable markers were about a third of their current size.

 

[ibncalb]

Update to using hideable control markers.

We did not update to the latest undocumented version detailed above, as we were on the last turn of our VOTG day 1 date.

So using the old version, knowing we could place overlays at the bottom of the stack we did so.

However, we found that as soon as one player placed a draggable overlay (smoke and rubble in our game) then that player could not accurately place counters in a hex.

To complicate the issue we are using deluxe sized hexes and a new beta extension (Doug knows).

To detail - after a player had placeda draggable overlay it was necessry to aim off centre when moving a counter/stack to be able to place the stack in the desired position.

for example to place a stack on the centre dot it was necessary to aim down and right, like shooting a poorly zero'd rifle.

This condition persisted across saved games and across resynchronisation.

Then, for no obvious reason at all, it resolved itself. Until the next player placed an overlay and then that problem reappeared for the placing player. It did not reoccur for the non overlay placing player. Then, ten minutes of play later, for no discernible reason, the "aim off centre" again disappeared.

 

[apbills]

I am not sure if that has anything to do with that extension.

I am running 668b9 and have loaded the v2.5 Hideable Control marker extension.

On board 00 I have placed a Smoke and a Rubble draggable overlay. I then placed two counters, one on each of them. I did not see any displacement of the counters, either when placing or after placing those counters. This may (although I have no idea) be something associated with Doug's ongoing work on the new deluxe sized hex code. Not sure. I can verify I do not see the behavior with the above listed versions. Can you replicate the issue with a different version of VASL (beta9)?

 

[apbills]

I will add that it sounds like you have multiple variables going on, between beta code versions and the new extension. It may be both are just not working together.

 

[PresterJohn]

It will be the deluxe size hexes.

 

[jyoung]

Update to using hideable control markers.
...
Then, for no obvious reason at all, it resolved itself. Until the next player placed an overlay and then that problem reappeared for the placing player. It did not reoccur for the non overlay placing player. Then, ten minutes of play later, for no discernible reason, the "aim off centre" again disappeared.

Ughh, gotta love those types of intermittent problems... the old perimeter counters will definitely not play nicely with deluxe (or other sized) hexes, that should have been fixed in V2.5 but this overlay stacking issue is not something I've encountered (but I don't use overlays that much).

To help chase it down, and assuming you can get it to happen again, is it any counters won't stack properly on draggable overlays, or just the hideable control and perimeter counters?
Does it occur in 6.6.8Beta9, or just the new beta you are using?
Does it occur without the hideable control extension installed?

 

[ibncalb]

@jyoung I can verify that removing the hideable control extensions solves our problem.

@apbills I can state that this is occurring over normal sized hex maps also when hideable control markers is installed. I am using a new extension that we are testing for Doug, this may explain why you and I are getting different results

The behaviour was also triggered by using the turn track overlays, although I did not think of them as "overlays".

 

[apbills]

@ibncalb that is an interesting find - the turn tracks only use one counter trait, which is the 'Does Not Stack' trait that all overlays use. I use it extensively in some of my extensions as well. It may be nothing, but thanks for researching more. You are correct in that the standard beta9 is probably not the same as yours since @DougRim is still working the zoom capability stuff and I have not been a part to that. I tend to stay on the counter side of things.

Edit: I have not used those turn tracks in a while, I use the excellent scenario information overlay designed/built by Kai Glanz and Neal Ulen that I got from Scenario Creator. Excellent work from those guys.

 

[DougRim]

We seem to have several things going on here, involving about 3-4 different VASL components.

1. The Hideable Control and Perimeter Markers (HCPM) extension that @jyoung has created
2. The BoardZoomer extensions that @jyoung has created, that @ibncalb has been playtesting and that I will officially release on VASL.info next week soon after I release 668 (BoardZoomer.vmdx requires some VASL code that has been added to 668).
3. The Draggable Overlays built into VASL
4. VASL Turn Tracks

First thing to underline is that, whatever we call them, (1), (3) and (4) are all counters of one variation or another. And BoardZoomer works to change how counters appear on the map.

So, no surprise that we are getting some interaction.

One issue is that it can be difficult to access counters when we have any or all of (1), (3), and regular unit counters all present in one hex. My understanding is that while it can be difficult it is not impossible. That is to say that while we can perhaps improve useability, there is no bug actually preventing counter movement/actions taking place. Am I right? Or left?

A second issue seems to be that the HCPM extension appears to have an (intermittent) effect on the positioning of counters when dragged-and-dropped. @ibncalb has noted that the draggable overlays and turn tracks seem to have the same effect. I always have the HCPM extension loaded and have not seen this impact before but was able to replicate it today (when I also had the BoardZoomer.vmdx loaded). The presence of an HCPM counter on the map or a draggable overlay was not required to trigger the offset bug but I would say their presence made the bug appear more frequently. My testing has not been as extensive as @ibncalb's but seems very consistent.

Has anyone had instances of the offset bug when neither the HCPM nor BoardZoomer were loaded? Has the presence of a draggable overlay or a Turn Track counter been enough to trigger the problem? I would be very surprised if it had as both of these components have been in VASL for ages.

@jyoung is the author of both of the HCPM and BoardZoomer extensions and I assume he will continue to work on these issues as and when he can.

The plan for VASL669 calls for us to redo the Turn Track and Phase Wheel components (and all their related markers and parts) to streamline them. This would be a good opportunity to explore the issues above as well to see if anything in these counters is causing/contributing to the problems.

We are hoping that BoardZoomer.vmdx will eliminate the need for the Use Deluxe-Size Hexes functionality currently available on Boardpicker. This functionality does not seem to persist well from session to session. Both will be in place for VASL668. If BoardZoomer.vmdx performs well, then I should be able to turn off Use Deluxe-Size Hexes in 669. Use Deluxe-Size Hexes is different from the zoom in/zoom out buttons beside the LOS buttons on the VASL toolbar.

Let me know if I have missed anything or confused you!

 

[ibncalb]

In partial response to Doug's post.

I sent this to John today. I have been perhaps overly assiduous in keeping the existence of zoomer confidential...

**
Overlay Bug Report 25 3 24
Software Used
VASSAL 3.7.9
VASL 6.6.8beta9zoom
With attached sav file and ONLY hideable control extension makers installed

Recreate problem by dropping a deluxe sized overlay onto the map, (I used a green FFE1)
Two problems occur

• The overlay sits atop the counter underneath, this is fixable by using the cursor down arrow.
• The second more major problem is that after one has placed the overlay it is impossible to place stacks on centre dots. One must compensate (like with a bad rifle) counter placement to get it to place accurately.

I tried to recreate the same problem on a normal board (i.e. without the deluxe sized hex option) I could recreate problem 1, but not problem 2.
I tried to recreate the problems on an Advancing Fire PT map that we are using, I could create problem 1 but not two.

With ONLY hideable control makers and boardzoomer installed I get the above results with the three maps I tested. (Deluxe sized hexes, board 10 and the PT map).

I put all of my extensions back and repeated the above test. Same results. The problem appears in two circumstances – when using deluxe sized hexes option, OR when still in the same VASL session, using an overlay in a deluxe sized hex map and the loading a normal size hex map.

Finally, I removed ALL extensions and tested the deluxe sized hex option map (attached save file) neither problem 1 or 2 occurred.

So, my conclusion is that this problem occurs only when using an overlay (any kind including turn tracks) on a map with “deluxe sized hex” options ticked and hideable overlays installed. This problem will then continue on any other scenarios opened during the same VASL session (i.e. fixed by closing VASL/VASSAL entirely).

Secondly, this problem only occurs when the hideable control markers extension is installed.

Deluxe sized hexes+hideable control markers+using any overlay = bad.

 

[ibncalb]

However, after writing the bug report my regular opponent and I met again to discuss my report and, we could not get these bugs to replicate, even though it was the two of us, under the same circumstances, that had uncovered/experienced them. Wack.

But, I will reiterate my comments of a few posts above. This problem does not occur on true deluxe maps. So with that in mind, John's zoomer extension (which should be released as "OK Zoomer") completely obviates the need to use the DSH option, and in my learned opinion is as important to VASL as the larger sized hexes in RB were to ASL as a whole.

I cannot wait for an official release of OK Zoomer, I have nothing but superlatives for this extension.

 

[jyoung]

Thanks @ibncalb and @DougRim, I will indeed keep working on issues that crop up - as work, life and ASL playing commitments (least to most important?) permit of course .