I suppose my question will seem a bit of a noob one, but I am beginning to lose all understanding I supposed I had concerning Vassal Modules.
I am currently trying a simple thing: an editable text label in an At-Start Stack where you can put your name with the “Change Label” command integrated with the Text Label trait. My issue is that I can not select the piece when I define the shortcut for the Change Label menu item whereas I can select it if I leave the shortcut empty…
There is nothing more in the piece than the basic piece trait (with a name but no image), then the text label trait and a delete trait (that appears correctly if I leave the shortcut empty for Change Label).
I would gladly receive any advice you could give to me! And sorry if it is a stupid question
Well, I just made a quick test and I, for one, can confirm 100% what you say!
I found that it only works if you define an image on the piece. Otherwise, if you leave it undefined/invisible then even the delete trait will disappear (but only when the change label command is defined), just as you say.
I tried with both 3.1.18 and 3.2.0 beta 1 (with the latter I even tried changing from a combo key (was using CTRL-A) to a named command on the change label, but no difference).
To work around this bug I suggest you create an invisìble gif of roughly the same size in pixels as what you expect the text label to be.
As a side note - but this might be a known bug not yet fixed even in 3.2.0 beta 1 - when you define an image, then remove it again… you are then stuck with the impossibility of defining it yet again. The image previously used shows in the pull down menu choice (indeed it’s there in the Images folder in the module), but selecting it makes no difference: the image remains undefined (=invisible piece). I think you need at least 2 images in the folder so to actually change the default showing in the basic piece trait or it cannot be assigned an image ever again. You need to remake the piece from scratch. Two bugs in one go?
As a side note - but this might be a known bug not yet fixed even in
3.2.0 beta 1 - when you define an image, then remove it again… you are
then stuck with the impossibility of defining it yet again. The image
previously used shows in the pull down menu choice (indeed it’s there in
the Images folder in the module) choice but selecting it makes no
difference: the image remains undefined (=invisible piece). I think you
need at least 2 images in the folder so to actually change the default
showing in the basic piece trait or it cannot be assigned an image ever
again. You need to remake the piece from scratch.
Incidentally, since I read that Vassal 4 is going to be so much different and everything… can you clarify if it will build on 3.2.x to add/fix stuff - with all major changes being under the hood - or should we expect a complete new product?
I suppose it is the former, but I was wondering if it was the latter … and hence my reluctance in filing bug reports (if the present engine is at the end of the line).
Incidentally, since I read that Vassal 4 is going to be so much
different and everything… can you clarify if it will build on 3.2.x to
add/fix stuff - with all major changes being under the hood - or should
we expect a complete new product?
There will be a module converter for V4.
I suppose it is the former, but I was wondering if it was the latter …
and hence my reluctance in filing bug reports (if the present engine is
at the end of the line).
I definitely want to fix any bugs which are new in 3.2. I’m planning to
circle back soon (maybe next week?) to take care of the ones for which
we have reports, before releasing 3.2.0-beta2. I don’t intend to work on
bugs which predate 3.2 myself from here on. That doesn’t mean nobody
else will and I’m still perfeclty happy to have patches for old bugs, as
I suspect that the 3.2 series will be in use for some time before V4 is
Have had a look at 4600 and I don’t believe it is a bug.
The pop-up menu appeatrrs when Vassal detects that you have right-clicked on the counter image. Since you are not defining any image for the counter, it is impossible for Vassal to detect that you have clicked on the counter. Hence no pop-up menu.
You counters are not ‘Invisible’ ( a bad term, since in Vassal, it means a counter turned invisible by the Invisible trait), but are non-existent.
The way to do what you want is to use a fully transparent image of the apprropriate size (say 50x50 or 75x75) as the Basic Piece image of your counter. This will keep the body of the counter from having any visible image, but when you click on it, you will see get a right-click menu appear and the shape of the transparent image will be outlined by the Selection Highlighter.
Can you just confirm that this is a problem if and only if there is just the one image in the entire module?
The problem lies in the fact the the image only gets selected when the drop-down list item changes. With only one item, it can never change.
You can always reload the single image by double-clicking on the image display panel. It doesn’t help that the image display panel dissappears when teh dialog repacks after the image is deselected. You can manually resize the dialog and double click where the image is usually displayed.
I can see two ways to approach this
The quick way is to have the ‘Double-click here to add new image’ message re-appear when you deselect the current image by cancelling the image picker.
The longer way is to Add a new ‘(No Image)’ option at the head of the image list that is displayed when you first create a piece, or when you deselect the image. Selecting the ‘(No Image)’ option will also deselect the image.
My initial thoughts where that since this only occurs in the one image situation, that option 1 was the way to go.
However, given the current non-intuitive method of deselecting an image (by starting to load an image and then clicking cancel), I’m thinking that option 2 is probably worth the effort. In fact, both option 1 & 2 together would probablty be best.
yes, I also think option 1 would be best (or both 1 and 2).
Again, I don’t think you have read this thread through and/or maybe my bug report was not much clear.
The piece we are talking about are not non-existent: they have a text label defined printing out some actual text. Thus they have some sort of physical presence. Indeed, as he said in the original post, and I confirmed in the 2nd post, traits like DELETE do show up when right clicking on the text label. They do. If this is a bug, and the piece should really be non-existent, I don’t know. But surely it looks more like a feature to me (the fact that a text label alone gives a “presence” to a piece even without an image defined).
The bug, instead, is that those other traits like DELETE stop showing up when you define a command key to change the text label. Why would the theoretical possibility of changing the text all of a sudden make the piece completely non-existent?
Yes, the workaround is to use an actual invisible image, again something already suggested in the thread (2nd post).
Brent, can I ask that you look at bug 4302 next, when you have a chance? Unless somebody else is taken care of this, that is.
It is a bug related to global hotkeys not respecting order of execution (jumping the line) in network play for the remote clients. It is very painful to work around, if possible at all.
As an example (but this is a relatively painless one) suppose a trigger on your units fire an hotkey to move forward the turn counter after a moving/action is done on the piece. Then the report trait associated with the turn counter will show up first on the remote computer, which is rather confusing/ugly:
Local client: Tank fires on infantry - Turn finished
Remote client: Turn finished - Tank fires on infantry
This same example becomes much more painful if you have any extra “intelligence” in the module to change state when the turn moves on, as it will change it too soon on the remote client.
However, I personally think that it is a nice feature to have pieces with no image defined and a variable text label selectable (and hence right click commands and all). Without the need for the transparent gif work around… why forcing the extra work?
Even should dynamically changing the size of the selectable area prove too difficult/impossible, just having it set to cover the initial preset string is better than having to remember creating and adding a transparent gif of the same size (what if one changes idea about the font size later on etc).
As always, the problem is compatibility with existing modules where the designers have set up the module to work in a certain way and should reasonably expect that the way it operates does not arbitrarily change to suit someone else.
One possibility would be to have a new checkbox option in the Label trait to the effect of ‘Always include label in selection area’ to change the default behaviour.
Note that there is the danger that if a user changes the label to nothing, the counter becomes completely innaccessible.
I’m moving discussion of bug 4302 to a new thread.