I finally had a chance to try this out. It seemed perfect for a block wargame, with the commanders as mats, and other blocks as cargo.
The first problem I encountered is how slow it is. A mat with 1 small graphically simple piece on it, dragged to a location where it is caused to rotate, locked up Vassal for several seconds. Maybe this is a problem with how my rotate works: 120 facings, trigger if Facing!=CurrentZone, repeat until Facing==CurrentZone, where the Zones are all named 1-120. This worked fine with dragging a bunch of blocks previously, but is now a problem.
The second problem I encountered is that I donât know of a way to prevent the blocks on the mat from being a) rotated to maintain facing relative to mat (good), and then b) rotated again by the same trigger that rotated the mat in the first place (bad). Is there some way to disable a trigger when on a mat? If not, there really should be.
The third problem I foresee is linked to this, in that the rotation to maintain facing relative to mat seems to be independent of a pieceâs actual Facing property. So if I move a piece that is already rotated to another Facing onto the mat, the mat rotates it further to âmaintain facingâ, which obviously isnât good for anything. As a workaround, I guess Iâd need a trigger to reset Facing when a piece is placed on a mat. Is there some way to do this? If not, there really should be.
Howdy! Glad to hear youâre trying out Mats. It does sound like your problems are related to the way your facings are working, with the extra triggers and stuff (and maybe even more especially the fact that the mats & cargo are being triggered from the same keystroke).
I have some pretty elaborate hi-res pieces in my Almoravid module and the Mats stuff runs very quickly even for large numbers of them.
Note that you can use the CurrentMat property of a cargo piece to see what Mat it is on (or it will return a blank string if it is not on a mat), so you could have an expression check that and ignore the âextraâ triggers. If you currently have the keystroke directly on your Rotate property, you could replace that with a NamedKeyCommand, and have a Trigger Action trait what received the original ârealâ keystroke, checked the expression to make sure the piece isnât on a mat, and then if that were the case fired the NamedKeyCommand that activated your Rotate trait.
Iâm thinking that maybe just fixing that would remove your performance problems, but let me know how it goes. My own cargo pieces donât have âtheir ownâ Rotate traits, they only rotate with their mats if theyâre on one.
I understand now that the mats use âarbitrary rotationâ, which has always been incompatible with âFacingâ. Facing is still the only way to achieve automated rotation though, isnât it? If I want a piece to rotate to a given facing under certain conditions, the only way to do it that I know of is to create a loop that repeats a change of facing until a condition is met.
Looks like the new coordinates and rotation of the pieces on the mat are being calculated for every step of the loop until the desired Facing is achieved.
This has three effects. One is the lag, which is significant. I can only achieve a fast result using arbitrary rotation drag to rotate. Facing loops take time.
Another is pixel drift causing pieces to become misaligned:
This can get pretty crazy if you repeat enough times:
(Here, I have a thin mat, and one of the blocks âfell offâ it due to the drift partway through the clockwise rotation.)
The other is that movement trails for a piece that is rotated on a mat then moved off the mat get messy:
I donât know if any of these things constitute problems that need fixing, or indeed if they can be fixed. Perhaps mats are just going to be incompatible with Facing rotation, in which case Iâll strip out Facing and automated rotation from the module and make it all manual via arbitrary rotation. Not ideal, but mats are so good that the trade-off seems worth it.
Iâve been using Mats w/ âFacingâ rotation w/o problem, but my mats only have 8 facings.
I doubt it ever occurred to anyone doing the original implementation that someone would want 120 facings and use multiple automated triggers to achieve rotations. Possibly there is something we could do to automate arbitrary rotation.
How do your users normally rotate a piece? Hit a key a bunch of times for the number of 3 degree rotations they want? Or you have other keys to go e.g. 30 or 45 degrees at a time?
Well, is there any way to have a trigger to go direct to a given facing? Or set an arbitrary rotation? If not, there arenât any convenient alternatives.
Without triggers, arbitrary rotation is very limiting.
In my module, every âapproachâ is a visual line on the board that a block can enter and reinforce, which is indicated by rotating the block to align it with the line. Approaches can have any angle, as the screenshots above illustrate.
I have every approach configured as a Zone with a Property, which is the number matching the appropriate Facing. So, a 90 degree approach has a value of⌠31, I think. A block dragged there will repeat a clockwise change of Facing until it reaches Facing 31. Same for every other approach on the map. Even the areas near approaches are set up so that Ctrl+A aligns the block with the approach. Ctrl+H resets to Facing 1.
I also included 9 degree manual rotations, but Iâve never seen a use for that.
Weâve just been discussing this on Discord. If there was a single âGo To Facingâ Key Command that allowed an expression to select the target facing, would that be enough?
Can you think of a reason you would need more than 1 âGo To Facingâ Key Command? Given that you could fiddle the target value via Beanshell/Calculated Properties/Triggers?
When you have a chance, could you have a play with build VASSAL-3.6.0-beta2-f0a5e58-10394-Direct-Rotate (built on top of beta2)? I have added a âRotate directlyâ command to the Rotate trait as discussed. Any suggestions appreciated and if it looks good, it will go into 3.6.0-beta3.
The virtual host config for https://www.vassalengine.org was missing SSLCertificateFile and SSLCertificateKeyFile directives, and as a result was using the default automatically generated self-signed SSL certificate instead of the Letâs Encrypt one it should have been using.
Try now; if you find youâre still seeing this problem, please let me know.
Trying out the new Direct rotation. I do not know if it is a problem with Mats or Direct rotation.
The command that I am undoing is a Trigger that activates two other Triggers: trigger 1) sets a Dynamic Property to match CurrentZone if conditions and activates the Direct rotation to set Facing to equal the Dynamic Property, while trigger 2) does much them same thing, setting the Dynamic Property to match another property if different conditions and activating the Direct rotation to set Facing to equal the Dynamic Property.
