Hideable control and perimeter markers
- Thread starter jyoung
- Start date
jyoung
Senior Member
- Joined
- Feb 19, 2020
- Messages
- 382
- Reaction score
- 453
- Country
-
I've added a few (hopefully helpful) changes to the extension, using custom code, to create version 2.0. The button layout is a bit different, it's explained in the pdf help file in the .vmdx file (or via Help/Hideable Control and Perimeters from the main window once it's installed). I had to make some changes to the counters (in particular the perimeters) to get the new 'select' feature to work, meaning that it's not 100% backwards compatible with previous versions of the extension - it would be best to start afresh using only counters from this latest version.
I would really appreciate a few gracious souls testing this before I post it on the official download site, to make sure my code additions don't interact with other VASL elements in unexpected ways. Dropbox link is here: https://www.dropbox.com/s/nv4tmcsgqdviiat/hideable-control-markers-2.0.vmdx?dl=0
I would really appreciate a few gracious souls testing this before I post it on the official download site, to make sure my code additions don't interact with other VASL elements in unexpected ways. Dropbox link is here: https://www.dropbox.com/s/nv4tmcsgqdviiat/hideable-control-markers-2.0.vmdx?dl=0
punchdrunk
Recruit
- Joined
- Jul 30, 2022
- Messages
- 9
- Reaction score
- 4
- Country
-
I just came across this extension yesterday and found it really useful. I used the white flippable control markers for hex/location control with the nation-specific ones for overall building control. I used the perimeter markers to outline setup areas. I did The Guards Counterattack yesterday where units have to setup in specific building. "These guys go in the red building" is a lot easier than "which building is N2 again?"
Love the ease of manipulation of the counters combined with the ability to turn them off and on instantly.The only weirdness was that in the Counter window for the perimeter markers everything looks blank, with a partial black hex outline when selecting. I have to drag them out to the map to tell which color they are. Is that expected behavior?
Update: Working fine now. It was something wrong on my end.
Anyway, just wanted to say great idea and thank you for making it!
Love the ease of manipulation of the counters combined with the ability to turn them off and on instantly.
Update: Working fine now. It was something wrong on my end.
Anyway, just wanted to say great idea and thank you for making it!
Last edited:
jyoung
Senior Member
- Joined
- Feb 19, 2020
- Messages
- 382
- Reaction score
- 453
- Country
-
Thanks @punchdrunk, I'm glad you're finding it useful. What you've described is not expected, here's what I see in the perimeter counter window. The images in the window are just the counters themselves, so it's odd that they would be blank.
I'm using VASSAL 3.6.6 and VASL 6.6.4, I don't know if any version differences would affect it but I don't think so. Are you using version 1.9 of this extension (from the VASL download webpage) or the version 2.0 beta (dropbox link in post #22 above)? If the former, try 2.0 beta and see if it changes anything. In that I've added a more convenient dropdown menu to drag the counters from, and again I can see the perimeter colours there. If the colours also don't show up in this menu, it gives me a starting point to chase down the problem.
I have a few more changes in mind before I release version 2.0, including 0-5 hex radius markers like in the draggable overlays, but working just like the perimeter markers (i.e. hideable and can change the colour by flipping).
apbills
Elder Member
I was on vacation and just came across the updates in this thread. I had been using v1.8 and downloaded beta 2.0. Everything seems to work. I do have a question, does the hide/show toggle work for each player separately or for all? It would be nice to have that control work independently for each player.
And something else as a suggestion. I have been working on a campaign game extension, and one of the things I have created is a reduced size control marker, which does not snap to the grid, is non-stackable, and which requires the player to use "Shift+click" to select. This does several things, a) it reduces the size so that you can see more of the hex, b) it makes it normally unselectable so that you don't accidentally select and move it, and c) it leaves it on the bottom of any stack so that it does not interfere with normal units. This is a snapshot of some German control markers where I used the size-ratio to reduce their size to a quarter of normal size, along with a couple of normal sized control markers. I see that yours do not normally stack (i.e., they go to the bottom of the stack, do not appear to get selected when you grab a stack, although you can select them normally with just a click, so much of the behavior I wanted is already part of your counters). The part not included appears to be the reduced size with non-snap to grid and the 'Shift+Click". I used the "Shift+Click" so that when you grab a larger selection (like at the end of a CG scenario) to move a bunch of stuff in multiple hexes you don't select the control counters.
And something else as a suggestion. I have been working on a campaign game extension, and one of the things I have created is a reduced size control marker, which does not snap to the grid, is non-stackable, and which requires the player to use "Shift+click" to select. This does several things, a) it reduces the size so that you can see more of the hex, b) it makes it normally unselectable so that you don't accidentally select and move it, and c) it leaves it on the bottom of any stack so that it does not interfere with normal units. This is a snapshot of some German control markers where I used the size-ratio to reduce their size to a quarter of normal size, along with a couple of normal sized control markers. I see that yours do not normally stack (i.e., they go to the bottom of the stack, do not appear to get selected when you grab a stack, although you can select them normally with just a click, so much of the behavior I wanted is already part of your counters). The part not included appears to be the reduced size with non-snap to grid and the 'Shift+Click". I used the "Shift+Click" so that when you grab a larger selection (like at the end of a CG scenario) to move a bunch of stuff in multiple hexes you don't select the control counters.
ScottRomanowski
Forum Guru
I've been using v1.9 and as far as I can tell, with both live and PBEM play the hide/show works for each player independently. That is, if I hide the markers, you still see them when we're playing on the server.
jyoung
Senior Member
- Joined
- Feb 19, 2020
- Messages
- 382
- Reaction score
- 453
- Country
-
Yes, the show/hide works for each player independently (like zoom, not something I had to design in luckily as it came for free with the VASSAL implementation of map layers). Another very nice idea @apbills, would you mind sending me a copy of your extension so I can see how you've done it? Let me play with the shift-click selection idea a bit, I would have achieved what you wanted (not getting all the control counters when you select units) by toggling the hide button before selecting, do you think it would be useful to have both?
apbills
Elder Member
I did not think about that option (i.e., hiding the counters first). That will work just fine. Given I did not have the hide capability with my reduced size counters, I can see how I was thinking just about my counters. I suspect it will work better with just the normal click method since it can get confusing when you need to select with a "Shift+click", something normally used for draggable overlays. i sent a note to you with my e-mail address. Note that I trimmed the normal size counter down a bit to get rid of some of the white space around the normal size counter before I reduced the size. When I get your e-mail I will send you what i have for those counters.
punchdrunk
Recruit
- Joined
- Jul 30, 2022
- Messages
- 9
- Reaction score
- 4
- Country
-
After a restart I see everything properly now, so it was just something strange on my end.
apbills
Elder Member
John,
I sent you my extension and another e-mail with some steps I did with your extension to try out. Below is a snapshot of the results of what I did. The small German control in O3 is based on the 16x16 white counter and the 0.5 scaled nationality image. You can compare to what I had done previously. The foxhole has a layer on it to show control since its +2 TEM makes it a strategic location, and by making control a layer it keeps another counter from being added to the stack. it uses the same concept of scaling, and that counter is part of the extension I sent you as well. Note that I had only worked up these small control/foxhole counters with German, Russian, and American nationalities.
I sent you my extension and another e-mail with some steps I did with your extension to try out. Below is a snapshot of the results of what I did. The small German control in O3 is based on the 16x16 white counter and the 0.5 scaled nationality image. You can compare to what I had done previously. The foxhole has a layer on it to show control since its +2 TEM makes it a strategic location, and by making control a layer it keeps another counter from being added to the stack. it uses the same concept of scaling, and that counter is part of the extension I sent you as well. Note that I had only worked up these small control/foxhole counters with German, Russian, and American nationalities.
I really like this extension and the way it is developing. Keep throwing those versions out there John.
My thought is that this should stay as an extension. It adds quite a bit to the toolbar and there are those who might not care to have this imposed on them as part of core VASL. As an extension, it's easy to download and add. Just MHO.
My thought is that this should stay as an extension. It adds quite a bit to the toolbar and there are those who might not care to have this imposed on them as part of core VASL. As an extension, it's easy to download and add. Just MHO.
jyoung
Senior Member
- Joined
- Feb 19, 2020
- Messages
- 382
- Reaction score
- 453
- Country
-
Thanks Doug and I agree, definitely see it staying as an extension rather than moving to the core. I am trying to minimise the real estate it takes up button-wise, which has led to some interesting challenges such as working out how to drag counters out of a menu across the rest of the menu structure in either direction, but as an exercise in
...which leads me to say that trawling through various VASL and VASSAL forums to see "how do I do x?" has given me an even greater appreciation for just how much you are doing to support VASL. Huge thumbs up!
DVexile
Senior Member
Doing our first CG and trying this out. Wow, can't imagine doing things without this functionality! Thanks so much for your work.
Using version 2.0 of the extension on VASL 6.6.5 with VASSAL 3.6.7 and haven't had any immediate issues, though only played with it for a bit. I'll report if anything comes up with more play.
One thing I do notice is that using the white counters whenever flipped (ctrl-F) the nationality always reverts to German or Russian. Doesn't appear to retain the nationality state of the reverse side. For example if I have an American white counter and flip it to German when I flip it back again it will be Russian. So for instance if playing the Japanese against the Marines every time you flip you'd have to ctrl-N a bunch to get back to the correct nationality. Not a huge deal, but wanted to point it out if that wasn't the intended behavior. It would of course be nice and would make the ctrl-F function more useful if each side's nationality state was preserved. Even easier would be for end users to be less pedantic
Again thanks for your efforts!
Using version 2.0 of the extension on VASL 6.6.5 with VASSAL 3.6.7 and haven't had any immediate issues, though only played with it for a bit. I'll report if anything comes up with more play.
One thing I do notice is that using the white counters whenever flipped (ctrl-F) the nationality always reverts to German or Russian. Doesn't appear to retain the nationality state of the reverse side. For example if I have an American white counter and flip it to German when I flip it back again it will be Russian. So for instance if playing the Japanese against the Marines every time you flip you'd have to ctrl-N a bunch to get back to the correct nationality. Not a huge deal, but wanted to point it out if that wasn't the intended behavior. It would of course be nice and would make the ctrl-F function more useful if each side's nationality state was preserved. Even easier would be for end users to be less pedantic
Again thanks for your efforts!
apbills
Elder Member
I will second that praise. I have been using version 2.0 for some time and would not even start a CG without it. Currently using VASSAL 3.6.10 and VASL 6.6.6beta4 with no problems seen to date. (which includes transitioning from 3.6.7 -> 3.6.8 -> 3.6.9 -> 3.6.10 and from 6.6.4 -> 6.6.5 - 6.6.6 on the same CG).
ibncalb
Senior Member
Strange problem with this extension.
I'm currently using newest VASSAL and the new beta VASL version, however I also experienced the below problem a few months ago with an older version.
We use the draggable overlays extensively. FFE are the most common. with hideable markers installed if I use a draggable overlay it sits over the unit counters so I cannot select or even clearly see the counters under the overlay.
The only way I can get the overlay to not sit atop the counters is to move the counters place the overlay and then put back the counters ontop of the overlay. I believe this is not WAI.
We thought it might possibly be due to our penchant for using "deluxe sized hexes" option but thehe problem occurs on normal sized hex boards also.
One very strange occurrence - whilst in a VASL room we were experimenting this issue on the VOTG map, I opened a new scenario to test on a normal sized hex map, when I closed the map and resynchonised with my buddy on his VOTG map,the counters and overlays that I had used on my board 10 test were super imposed onto the VOTG map - my opponent could see them and interact with them also.
TLDR - hideable control markers seems to be creating a layer issue with overlays which hides counters from manipulation
I'm currently using newest VASSAL and the new beta VASL version, however I also experienced the below problem a few months ago with an older version.
We use the draggable overlays extensively. FFE are the most common. with hideable markers installed if I use a draggable overlay it sits over the unit counters so I cannot select or even clearly see the counters under the overlay.
The only way I can get the overlay to not sit atop the counters is to move the counters place the overlay and then put back the counters ontop of the overlay. I believe this is not WAI.
We thought it might possibly be due to our penchant for using "deluxe sized hexes" option but thehe problem occurs on normal sized hex boards also.
One very strange occurrence - whilst in a VASL room we were experimenting this issue on the VOTG map, I opened a new scenario to test on a normal sized hex map, when I closed the map and resynchonised with my buddy on his VOTG map,the counters and overlays that I had used on my board 10 test were super imposed onto the VOTG map - my opponent could see them and interact with them also.
TLDR - hideable control markers seems to be creating a layer issue with overlays which hides counters from manipulation
Last edited:
PresterJohn
Senior Member
I have seen the issues you report, but not while using the hideable control markers. I believe there is an underlying issue with the memory usage of VASL when you change maps. There is also the issue with dragable overlays sitting on top of counters and needing to be selected and moved to the bottom of the "stack" via the down arrow.
DVexile
Senior Member
Yes, this! Sometimes on a crowded board I've had some trouble successfully selecting the overlay and moving it to the bottom as well, but I suspect that is just user error. I've always gotten it sorted in the end without having to move markers around though. Shift click the overlay to select it and then use the keyboard to move it to the bottom.
I suppose it is possible that the various display options provided by the hideable control markers extension could unintentionally float the overlay to the top and perhaps that is creating an issue for @ibncalb. I think he should still be able to select the overlay and move it to the bottom as you mention if that is what is happening.
You are quite right, Down Arrow is the normal solution. In this case, when the control marker is a hideable control marker the Down Arrow solution is NOT working. It doesn't work if you select the Draggable Overlay (I tried with FFE and with Orchards), nor does it work if you select the Hideable Control Marker. If you use a regular control marker from the nationality panel then it does work.
So, I think the issue is with the Hideable Control Marker extension. @jyoung fyi.
apbills
Elder Member
My assessment of this issue follows. Beware it is only informed by me looking at the extension components and it involves discussion of the internals of the module.
The extension adds a "Game Piece Layers" component to the module. This defines a layer property named "Layer" that it uses to order the display. Any piece that does not have this "Layer" property defined is normally displayed on top. The only pieces with this layer defined are the control and perimeter markers in the extension, so all other pieces are displayed on top unless the order is changed. The extension has 2 layer controls, the first button toggles the 'Control' and 'Perimeter' layers to be active or inactive (hides them). The second button adds a display layer control that cycles through the order in which the pieces are displayed, effectively cycling through "Control", "Perimeter", and "No value". Note that everything other than the extension provided counters has "No value" for its layer.
This VASSAL map component takes precedence over the VASL overlay display order in that the overlays use their own method (within VASL) to display on top of the map but under the other counters. They use the "Overlay" property (marking it 'true' if it is an overlay) so that the overlay is placed under the counters. Note that this VASL method does not create a new map layer within the main map component as far as VASSAL is concerned.
This conflict between the two display methods and ordering is what you see occurring when you use the extension. If you do not have the extension loaded, there is no "Game Piece Layers" component defined. If you have the extension, there is this additional component. Because all non-extension pieces are in the "No value" layer, the extension only has 3 defined layers it can manipulate, and both the overlays and the normal counters are in one layer. Within that one "No value" layer, VASL takes over and orders the overlays underneath the counters (at times) but occasionally it places them on top and you must SHIFT+Select the overlay and put it underneath the normal counters. This does not change the VASSAL display order, it only affects the "No value" layer. I do not see a function within the Layers control that allows you to always keep a specified layer on the bottom (i.e., overlays) so that it will not be manipulated. I suspect this is why VASL coded in their own Overlay property so that overlays would not get messed up. So technically the extension is the cause of some of these problems, however, it is the interaction between the VASSAL layers and the VASL overlays that is the real issue.
I have some initial thoughts on this and will be investigating more.
Bottom line is you can manipulate the control/perimeter counters by hitting the stacking order button and place them on top, allowing you to select them and move/delete at will. You can always hit the hide button to toggle their display at any time, which makes them unselectable as well. You will also always see them in the hover display if they are turned on, even if they are under the overlay.
I use this extension religiously for my campaign games. Control markers everywhere, perimeter markers everywhere. I always hide them when I am doing anything other than assessing my situation as far as control and what I am trying to do in the game. It is too easy to in advertently select a perimeter or control counter and move it by mistake.
The extension adds a "Game Piece Layers" component to the module. This defines a layer property named "Layer" that it uses to order the display. Any piece that does not have this "Layer" property defined is normally displayed on top. The only pieces with this layer defined are the control and perimeter markers in the extension, so all other pieces are displayed on top unless the order is changed. The extension has 2 layer controls, the first button toggles the 'Control' and 'Perimeter' layers to be active or inactive (hides them). The second button adds a display layer control that cycles through the order in which the pieces are displayed, effectively cycling through "Control", "Perimeter", and "No value". Note that everything other than the extension provided counters has "No value" for its layer.
This VASSAL map component takes precedence over the VASL overlay display order in that the overlays use their own method (within VASL) to display on top of the map but under the other counters. They use the "Overlay" property (marking it 'true' if it is an overlay) so that the overlay is placed under the counters. Note that this VASL method does not create a new map layer within the main map component as far as VASSAL is concerned.
This conflict between the two display methods and ordering is what you see occurring when you use the extension. If you do not have the extension loaded, there is no "Game Piece Layers" component defined. If you have the extension, there is this additional component. Because all non-extension pieces are in the "No value" layer, the extension only has 3 defined layers it can manipulate, and both the overlays and the normal counters are in one layer. Within that one "No value" layer, VASL takes over and orders the overlays underneath the counters (at times) but occasionally it places them on top and you must SHIFT+Select the overlay and put it underneath the normal counters. This does not change the VASSAL display order, it only affects the "No value" layer. I do not see a function within the Layers control that allows you to always keep a specified layer on the bottom (i.e., overlays) so that it will not be manipulated. I suspect this is why VASL coded in their own Overlay property so that overlays would not get messed up. So technically the extension is the cause of some of these problems, however, it is the interaction between the VASSAL layers and the VASL overlays that is the real issue.
I have some initial thoughts on this and will be investigating more.
Bottom line is you can manipulate the control/perimeter counters by hitting the stacking order button and place them on top, allowing you to select them and move/delete at will. You can always hit the hide button to toggle their display at any time, which makes them unselectable as well. You will also always see them in the hover display if they are turned on, even if they are under the overlay.
I use this extension religiously for my campaign games. Control markers everywhere, perimeter markers everywhere. I always hide them when I am doing anything other than assessing my situation as far as control and what I am trying to do in the game. It is too easy to in advertently select a perimeter or control counter and move it by mistake.
DVexile
Senior Member
Great detective work @apbills !
Last year was using FFE and hideable control markers and mostly it worked fine. Every once in a while the overlay would mysteriously end up at the top of the stack and need to be selected and moved back to the bottom.
At the time I thought perhaps one of us was accidentally selecting and raising it somehow.
Now based on your post I suspect that on the occasion I selected to display the markers or changed the layer ordering in the extension during play that may have provoked the overlay to end up on top.
Really didn’t happen but a few times and the fix was easy once we figured it out (shift click and down arrow), but it was perplexing the first time it happened!
Last year was using FFE and hideable control markers and mostly it worked fine. Every once in a while the overlay would mysteriously end up at the top of the stack and need to be selected and moved back to the bottom.
At the time I thought perhaps one of us was accidentally selecting and raising it somehow.
Now based on your post I suspect that on the occasion I selected to display the markers or changed the layer ordering in the extension during play that may have provoked the overlay to end up on top.
Really didn’t happen but a few times and the fix was easy once we figured it out (shift click and down arrow), but it was perplexing the first time it happened!