3.6.0 beta mats behaviour

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.


Thanks, CurrentMat is what I needed.

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:
pixel drift
(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?

Sounds good to me, and would presumably resolve most of the problems I’m experiencing.

I cannot think of any use for more than one go-to-facing key command at this time.

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.


Where do I find that file for download?


I get a NET::ERR_CERT_AUTHORITY_INVALID error when I try to open that page using Chrome.

EDIT: Edge is the same, but lets me override.

It works well, thanks!

Oh, there’s something broken with Undo.

If I make two rotation steps, then undo the second rotation, selecting the mat displays all the mat cargo at some weirdly displaced location.



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.

Works fine now, thanks!

1 Like

Is that with the basic rotation trait, or trying the new Direct rotation? Which commands exactly?

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.

Perfect, thanks.

I’ll investigate and make sure Undo is working for a standard rotate trait, then I’ll follow up with Brian on the Mats behavior.


I just confirmed that the problem occurs regardless of whether direct rotate is used. Must be a mats problem.

You’ll have to wait for @Cattlesquat to be back, you are using Mats in new and interesting ways that where never considered.