problem with draggable overlays extension

[jrv]

I installed the v1.2 draggable overlays extension. I am seeing odd behavior with certain draggable overlays, here shown on board 1. In the upper left starting at about hex C2 I dragged overlay 3 onto the map. It has not scaled itself properly. In E7 I dragged RP5, which seems to work just fine. I see this problem with many overlays, in particular the number overlays and the beach overlays. No errors are reported when the overlay is dragged into the map.

On the right is overlay 3 added the old way on R8-R9 (I believe; I don't remember). It has alignment problems (perhaps due to it being added to an unexpected board at an unexpected location; see the bottom edge of the overlay), but is at least the right scale.



$ inxi -S -c4
System: Host: euterpe Kernel: 4.16.0-1-amd64 x86_64 bits: 64 Desktop: Xfce 4.12.4
Distro: Debian GNU/Linux buster/sid

$ java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-2-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

VASSAL version 3.2.17
- VASL version 6.4.2
- Extension OBA_CVP_Aids v1.0 loaded
- Extension oba-flowchart v0.1 loaded
- Extension StateCounterExt-0.05.00-all v0.0 loaded
- Extension VASLOverlays_v102 v1.02 loaded
- Extension BFP_v403 v4.03 loaded
- Extension testExtension v0.0 loaded
- Extension cloaking-display v0.0 loaded
- Using board(s): 01(v6.1)

JR

 

[BigAl737]

The bigger overlays are reduced in size to provide a reduced scale overview of the overlay in the pieces window. After dragging the overlay to the map, right click on it to make it full size.

 

[jrv]

The bigger overlays are reduced in size to provide a reduced scale overview of the overlay in the pieces window. After dragging the overlay to the map, right click on it to make it full size.

That is a bit of a UI surprise. Is there any reason becoming full size is not automatic?

Also, is there any way to re-select an overlay once it has lost selection? I have tried control-click, shift-click, and alt-click without success.

JR

 

[zgrose]

Help...Overlay Extension...

Instructions for Use

• Overlays are simply dragged from the overlay window and dropped on the map.
• It is recommended that you position a placeholder board (bd00 for example) to help "hold" large overlays that extend off the playing map. This also allows counters to snap to hex center as they move on the off map portion of the overlay.
• Overlays are designed to rotate and snap to the hexgrid around their center point. You may need to make slight drag and drop adjustments to a placed overlay to force it to snap in alignment with the map hex grid.
• Once dropped, right click on the overlay to open the right click menu. Use this menu to rotate, clone or delete the overlay.
• Overlays may also have common terrain transformation options accessed via the right click menu. Overlays with these options will be a little limited during the early stages of release but are planned to become more inclusive. If you have a request, please submit it to me using one of the the feedback links below.
• Some overlays are so large that the overlay picture in the overlay window is reduced in size to aid in reference. Once placed on the map, use the right click menu to replace the small version with the full size version.
• Once placed and deselected, an overlay can be re-selected with ALT+left click. You'll know you have the overlay selected when you see the black bounding box around the overlay.
• I'll repeat that again as it's important, use ALT+left click to reselect a placed overlay.

 

[jrv]

I get no joy on alt left click.

I am seeing very strange behavior. If I use alt *right* click heavily, about one in five times I get the context menu, but the overlay is not selected. Clicking on the context menu in this state does nothing. However if while the context menu is up I move the mouse and alt *right* click again, the overlay is selected and the context menu is now active. I have been experimenting with overlay 3.

On further experimentation, the alt-*shift* left-click reliably selects the overlay. The alt *right* click method works eventually, but alt-shift left-click is 100% reliable.

JR

 

[zgrose]

Just gave it another whirl on OSX+6.4.1+3.2.17 and I can select/deselect overlay 3 at-will with just the "alt" click (option click for me).

 

[jrv]

Just gave it another whirl on OSX+6.4.1+3.2.17 and I can select/deselect overlay 3 at-will with just the "alt" click (option click for me).

I am running 6.4.2, but I would not expect that to be the difference. Given the odd behavior I expect it's a java issue, but I don't know for sure.

 

[bprobst]

That is a bit of a UI surprise. Is there any reason becoming full size is not automatic?

I assume the reason is that those VASL code guys are kind of wacky, and they just like to spring these kinds of things on us so that they can waggle their fingers afterwards and say "what do you mean you didn't memorise the help file?".

After all, there's no conceivable reason why a player trying to set up a map for a game would ever want the overlay hexes to be the same size as the board hexes -- am I right?

 

[zgrose]

The overlay hexes ARE the same size as the board hexes once you're done getting it off the panel and setting it to full size. Dragging and dropping a large overlays on tiny screens can be a pain in VASL.

 

[BigAl737]

That is a bit of a UI surprise. Is there any reason becoming full size is not automatic?
JR

For ease of rough positioning it on the map before making it full size.

 

[bprobst]

Dragging and dropping a large overlays on tiny screens can be a pain in VASL.

Really? When was that survey taken? I've never noticed it.

Sounds like a classic case of "users do not need to be consulted when it comes to questions about the user interface that users will be forced to use" to me.

 

[zgrose]

Really? When was that survey taken? I've never noticed it.

Sounds like a classic case of "users do not need to be consulted when it comes to questions about the user interface that users will be forced to use" to me.

Well, how big is your screen so we can ask your informed opinion?

 

[bprobst]

Big enough for my needs. Not sure what the relevance to the topic is, the question was about sensible user interfaces, not screen sizes.

A sensible user interface does not require the user to take a mandatory manual action that the software already knows it needs to do. An optional action ("right-click, select 'shrink overlay' to make it easier to position") that some users might want to use because of the limitations in their particular hardware setups might be a good idea, though!

Just a thought.

 

[zgrose]

Big enough for my needs. Not sure what the relevance to the topic is, the question was about sensible user interfaces, not screen sizes.

Try using VASL on a smaller screen and you can see the relevance. Massive images on small screens (and even smaller windows in those small screens) are annoying in VASL. If the overlay could auto-spring to full size once dragged to the map, that would be handy, but I'd much rather have the reviewable size in the overlay window over the second it takes to pop it to full size once I have it down on the map. I like Al's approach. It's nicer than what we had in the Lock-n-Load VASL module for large overlays.

 

[bprobst]

I like Al's approach.

So it's impossible to improve on it, is that what you're saying?

"This suits my needs perfectly, so it must suit everyone perfectly, and we won't bother even investigating alternatives." I refer you back to my "we don't need to consult users" comment from above.

 

[zgrose]

So it's impossible to improve on it, is that what you're saying?

"This suits my needs perfectly, so it must suit everyone perfectly, and we won't bother even investigating alternatives." I refer you back to my "we don't need to consult users" comment from above.

I refer you to the middle sentence: "If the overlay could auto-spring to full size once dragged to the map, that would be handy,.."

At which point I believe the rest of your post is N/A.

 

[BigAl737]

Bruce, us VASL guys openly welcome input and consider suggestions to make VASL a better product for everyone. If I'm reading the tone of your posts correctly, you are stating otherwise. With all the suggestions and corrections you've offered and been thanked for over the years, I just can't believe you really think that. In this case, I value your input but not your manner. JR's question was answered. To answer yours, there is a VASSAL design reason big overlays work as they do.

 

[jrv]

The UI could be more obvious. One could overlay the image with text in electric blue (or other high contrast color; white-outlined black might actually be best) while it is in its tiny form that says, "press ctrl-f for full size" or similar.

I can't say I find having it not immediately spring to full size helpful. I can sort of position a full-width overlay in the right spot vertically because as best I can tell, the image expands from the center (and I only know that by experimenting). But horizontally I don't think I could get it near the right spot one time in ten. With an overlay that isn't a full-board width (e.g. beach) I don't think I could position it correctly at all, ever. That means that pretty much every time I drop the overlay, re-size it, then position it. In that case there's not much point to rough positioning. Drop it anywhere. Moving it a jot or a lot, it's pretty much the same. I do have a 2560x1440 monitor, so I recognize I may not appreciate the difficulty of doing the operation on a 640x480 screen.

JR

 

[bprobst]

To answer yours, there is a VASSAL design reason big overlays work as they do.

OK. Was anything fed back to the VASSAL team about this? It seems to me that a VASSAL design issue that prevents VASL from doing something that it logically should be able to do easily is a problem in VASSAL that someone might want to address. Perhaps they're already addressing it; that would be great. Since this is the first anyone has made mention of it in this forum, we have no data about it.

More importantly, why is your explanation completely different from zgrose's explanation? He was describing an attitude (and it was that attitude that I was taking exception to), while you're describing a technical issue that transcends anyone's attitude (maybe, depending on the ease of offering potential workarounds). There's a world of difference between "I didn't think to do that", "I don't want to do that" and "it's not physically possible for me to do that". Not knowing anything about the coding required, I'll always respect the latter, but the first two often fail to impress (remembering that there are always possible mitigating circumstances).

 

[zgrose]

You're a riot, Bruce.