I thought I’d report a few problems I’ve seen in the editor. I’m running the latest vassal 3.7.26 on a dell computer, windows 11. None of the problems are showstoppers.
I add a new deck of cards. I want to reposition it. In the deck component, I select “reposition stack.” I check “show other stacks/decks.” (To whoever added this checkbox, I give you an attaboy.) I now can drag the deck, but the arrow keys do nothing; they don’t work. To bypass this problem, I press OK, and then I immediately re-select “reposition stack.” Now the arrow keys work. In fact, they work from now to end of session in every deck and at-start stack. It’s the very first time that it breaks down. Note: If I don’t check “show other stacks/decks,” the arrows work. This checkbox seems to kill the arrows. Note2: It fails too in at-start stacks.
I add a discard deck, which is empty. I want to reposition it. In the deck component, I select “reposition stack.” The empty deck shows a gray ghost card, but it’s not where it’s supposed to be. If the deck is at (X,Y), it shows at (X+a,Y+b) where a and b are < the card’s width and length. IOW, the ghost card is shifted down and to the right. This also happens when I try to position other pieces/decks near the empty deck. To get around this, I must copy a dummy card into the empty deck so that I can reposition it accurately.
I’m working on an expression that has a bean shell button to the right. I press it. The bean shell expression field is light gray text on a slightly darker gray background. I can’t read it. I’m must compose my expression elsewhere.
Now two wish list items:
w1. I have a wide map in a game, and I find while playing, it’s a PITA to navigate left and right. Imagine a huge map of Europe and Russia. There’s a toolbar button labeled “Moscow.” I press it, and bam, the view is centered on Moscow. I press a “Berlin” button. Bam, I’m centered on Moscow. I’d like to be able to wire toolbar buttons to single pieces. In my example, I’d make hidden, immobile “focus” pieces in those cities.
w2. The does-not-stack trait defines if a piece can be moved and/or selected. It would save me a hell of a lot of work if I could control those fields with properties. Right now to turn those fields off or on, I have to use replace-with-other to replace the original mobile piece with a near duplicate that is immobile. I’ve considered coming out of retirement to do these myself.
This can probably be accomplished by a Move Cameria Button with explicit pixel coordinates, or by adding an invisible piece (in a low Game Piece Layers with traits Does not stack with no movement or selection, Restricted Access to make sure no one can manipulate it, and a unique name - say MoscowLocation), and a Move Cameria Button that moves to that piece.
But, you can probably achieve the same effect by a Dynamic Property that sets the property NON_MOVABLE to true when the piece cannot be moved, and to false when it can. I haven’t tried that, but as far as I can tell, it should work. Of course, you should be careful if you mix that with the Does not stack trait.
I’m not sure where you are getting NON_MOVABLE from perhaps you meant Immobile - the Vassal property set by the Does Not Stack trail? Trying to over-ride that via a Dynamic Property does change the property value returned - I tested with the DP lowest in trait order - but even this has no effect on drag & drop.
Christian, well, you got me red-faced. Any time I write to this forum, I ask myself if I’m going to look like a damned fool, and should I not submit. You have politely pointed out that my first request for being able to move the map focus around is already done. That “camera” component does everything I want and then some. I give you an attaboy. In my defense, I saw “camera” and thought it was some useless thing about taking pictures. Fooled me. Scratch my first request.
An odd thing happened during testing. I created a piece to center on. I gave it a marker property: Focus = 0. It didn’t work. When I pressed the button to go to the piece, it instead went to the top left map corner. Other options worked; the piece thing didn’t. Just as I was quitting and just for laughs, I changed the property to: flower = “rose”. That worked! So what’s with Focus? Is it some secret unspoken property? Actually, this has happened to me once before with a different word. Don’t remember what it was.
As for my other thing, I have never heard of NON_MOVABLE, and like Joel, I couldn’t get it to work. I printed it out in a report, and it was a null string, so I don’t think it exists. Please clarify for Joel and me. God, how I wish it did work, and I could give you a double attaboy.
BTW, I have a personal rule: thou shalt not write custom code. The last thing I want is 10 years from now someone crying boo-hoo-hoo, your custom code is obsolete. My response would be to go suck eggs.
My mistake: The property you want to set is cannotMove (NON_MOVABLE is a symbol in the Java code that contains the name of the property - i.e., has the value cannotMove).
However, that will not currently work, because in VASSAL.build.module.map.PieceMover.AbstractDragHandler#dragGestureRecognizedPrep, the content of the property cannotMove is compared against the constant java.lang.Boolean.TRUE. However, when returning a property value set - by VASSAL.counters.GamePiece.getProperty - set in a DynamicProperty or CalculatedProperty, it is always returned as a java.lang.String, so the comparison
I think is reasonable. It would be better if this was fixed in the Vassal code.
If such a chance was made, then one could implement that certain units can only move in certain phases or under certain circumstances, which would make a lot of modules even more useful. For example, an Allied unit may not move during the Axis movement phase.
I intent to make a Pull Request on this in the not too distant future. As this will likely not be merged on the 3.7 branch, it could tale some time before that chance was merged in.
Christian, thank you for your attention to this. My red face is due to embarrassment. It turns out that the camera component was exactly what I was looking for. I am embarrassed because I couldn’t be bothered to look up the camera thing. Oops.
Also, a special thank you for diving into the movable stuff. I found it interesting. Getting movement linked to a property would save me a ton of work. Currently I have to replace components with immobile copies after scenario creation is done, and this is quite error prone and requires attention. If you have any hand in it becoming real, please also look into “property-izing” the selectable trait too, which is just above moveable in does-not-stack.
I’ve just submitted a Pull Request. It will likely not be available until Vassal 3.8.0. However, it could go into 3.7.x as it will not break anything, but of course older Vassal older than 3.7.x will not behave the same way wrt. limiting movement.
In the mean time, you can take a look at a custom class here. Compile the code in cholmcc and include it in your module. On maps where you want to be able to restrict movement, replace the VASSAL.build.module.map.PieceMover element with a cholmcc.PieceMover element.
Just to understand - do you want to use f.ex. a Dynamic Property trait to set whether a piece is selected, or do you want to be able to say if a piece can be selected - at all - via f.ex. a Dynamic Property trait?
The former can be achieve via similar changes to those made in the above PR. However, a bit of care need to be taken because the SELECTED property is treated a little different than other properties.
I want to be able to turn movement on or off via a property. In my case, it’s typically a global property. Selection by property is not that important, and I’d suggest doing it for selection if it was a trivial change.
The TLDR: I’ve been creating modules where their operation consists of two parts: building a scenario/mission and playing the scenario/mission. The units in this games are usually man-level, and the map consists of large cardboard squares or hexagons. Some examples: Zombicide and my current project, SAS: Rogue Regiment. The builder must construct the map and add terrain overlays, so they need to be able to move, rotate, change images (layer), clone and delete. Once done, they press a button on the board that says “Press me when you’re done,” which does stuff and deletes itself. It sets a global property for one, setupComplete=true. At this point, I turn off all commands that only the builder needs via the restrict command trait. I cannot, though, shut down movement nor selection with that property. This is where I must jump through hoops where I replace pieces with versions that have different does-not-stack traits. In the past, I did selection and movement with control and alt buttons, but that was a PITA for the builder. I really thank you for your attention. If this happens, I owe you.
