3.6 beta 3 Mat/Cargo bugs

Not sure this is really a bug but some strange undesired behavior with mats and cargo. Links below to the module and a vlog explaining what I’m seeing. Neither of these is a big deal but thought I’d report it.


  1. When dragged from one map to another the cargo disappears until the mat is moved a second time.

  2. When moving mats, especially over counters on the map, some cargo disappears until the mat is moved again and the cargo shift a little on the mat.

Module Here

vlog Here

Hi Jim,

Sounds/looks like your mats & cargo are all in the same “game piece layers”, and so when they get dragged around they can end up getting plopped down in essentially a “random” order w/r/t each other.

If you go on your map(s) and add a Game Piece Layers component to each map (if it doesn’t already have one), and just make sure you mark all your Mats as being in a layer that’s drawn before your Cargo pieces then you’ll be all set – you can then put a Marker trait in the prototypes w/ property name Layer and value e.g. “Mats” or “Cargo” and that will tell each kind of piece which Game Piece Layer to draw in.


Note - Brent may be coding something for 3.6 that will solve your problem without resorting to Game Piece Layers, but in the mean time adding them would definitely solve the problem.

Thanks, Brian. That worked. Think I got it now.

Hi Jim,

Thanks a lot for posting the sample module and vlog. That has helped me a lot and will be a great test for the changes I am planning. A couple of the problems you are experiencing I know about, some I hadn’t thought of.

Issue 1 - Mat pieces ending up under the mat. This is being caused because the PieceMover does not really know about mats, so moves the mats and cargo in a fairly naive way. Sometimes, the cargo can be moved before the mat, and ends up under it. My solution is to make the movement of Mats by the PieceMover ‘special’. I’ll move pieces in a particular order: 1. Move any non-mats, non-cargo and any cargo not on mats. 2. Move the mats. 3. After moving each mat, move the cargo belonging to that mat and ensure it ends up at the same offset to (and on top of) the mat.

Issue 2 - Cargo interacting with Stacks already existing on the mat. Because the cargo is being moved before the mat (sometimes), it can end stacking into an existing Stack, causing it to adjust away from it’s correct mat offset.

Issue 3 - Mats and Cargo can interact with grid on the map, causing offsets. If a Mat is snapped to a grid location, the cargo does follow. Cargo can snap to a grid location, changing it’s offset on the mat. (Not in your module which has no grid).

Issue 4 - Cargo dropped onto mats is first snapped and stacked before being added to the Mat, causing it to drop out of place or possibly under the mat on an existing stack of units.

What I want to achieve:

  1. When cargo is dropped on to mat, we want it on the mat where we drop it, not snapped somewhere else.
  2. Once a Cargo is on the mat, we want it to be locked in place and to follow the mat exactly wherever it goes.

So, the changes I plan to make:

  1. Move mats, then cargo.
  2. Make cargo on mats pretend to be non-stacking and non-snapping.
  3. At the moment, when an individual Cargo is dropped onto a mat, it snaps and stacks before being added to the mat. The Mat test needs to be done first and if there is a Mat at that location, then turn the piece into Cargo (non stacking, non snapping) before it is placed.
  4. Review SendToLocation and Move Fixed Distance being applied to Mats and ensure the cargo behaves as expected.


I’m not sure that “making cargo on mats pretend to be non-stacking” is a good idea, depending on how it is implemented.

When I have a stackable set of cargo pieces, I want them to be stackable on their mat.

Hmm, That will cause problems if the mat is placed so that there are stackable units under the mat in the same location as the cargo will be above the mat.

Unless the cargo is on a different Game piece Layer than the units under the mat, they will want to stack with them.

Perhaps that is the answer, to have the option of Mat Cargo existing on a different layer while loaded on the mat. I say option, because you may not have created Game Piece Layers for the map, I can’t magic them up if they don’t already exist on the map.

If mats and cargo work when on different layers then yes, absolutely, a mat should be on a different layer to cargo to keep everything at the right relative “height”.

Just add that requirement to the documentation.

That’s not really what I am saying.

I ‘think’ what you are asking for is that you have some pieces on a map, that stack together on a map. When you move those units to a mat as cargo, then they can stack together on the Mat as cargo. But we don’t want them to stack with any units of the same type that might be under the mat. That can only happen if the cargo changes layer when it is loaded onto the mat

OK. I definitely expect stacks to remain stacks when moved on and off mats, to be expandable on a mat, etc.

If this means that a mat carrying a stack has to pick up and add to the stack another cargo piece if dragged over more cargo, that’s acceptable.

I would probably have a game piece layer for mats below a game piece layer for cargo anyway, to make sure I never get a mat on top of cargo.

If cargo can change to a defined layer when on a mat, that’s also fine by me.

Random thought about Mats in general; would it be practical to make them part of the property hierarchy and also provide their own location scheme for Cargo to use ?

Property Example: a Cargo piece would check a property value in the Mat piece after looking for the property on itself and before zone, map and module.

Location Example: A Mat could have its own regular or irregular grid defined, so Cargo would snap to the Mat’s grid rather than the underlying map and be aware of its relative location on the Mat.

The property idea would be relatively straight-forward to implement.

The grid on a mat idea, would be nice, but difficult to implement in the V3 architecture in a generalised way.

Agreed, added to design goals.

This may be acceptable for your purposes, but I think will be completely unacceptable for other people. I would find this odd.

Yes, but this assumes your cargo is ‘special’ and different from ‘normal’ pieces. You can’t do this if your normal pieces are also cargo, they will all be living on the same layer.

I think this is the way forward to allow stacking of Cargo on mats, independent of any non-cargo floating around under the mat. The disadvantage is that the solution has more moving parts that need to match up.

I am severely constrained by the V3 architecture with what can be done. Plus there is need to support different requirements.

I am thinking along the lines of these additional options for the Mat trait where cargo on the mat can have stacking/snapping over-ridden from what they would normally have:

Cargo on mat ignores map grid Y/N?
Cargo on mat can stack Y/N?
If Y, then enter the name of the Layer they will stack on.

You would normally want cargo to ignore the mat grid, however, if the mat is snapping to the grid and has ‘slots’ for units that match the underlying grid, you may want the cargo to snap as well.

The stack option allows you to force Cargo to be non-stacking, or allow it to stack on a specified Game Piece Layer, which would prevent it from interacting with any units under the mat on a different layer. Would require a sensible GPL layer setup.

@Cattlesquat interested in your take?

Just wanted to add that ideally any solution should also be flexible enough to accommodate a mat being cargo of another identical mat carrying cargo.

I can certainly imagine use cases where you’d want Cargo pieces that stack, and if on a Mat they’d stack with Mat pieces, but when off the Mat they’d still stack together (just not on a mat).

One way to go about that might be to have the find-me-a-stack algorithm(s) check for identical “what mat am I on” status before joining a stack – essentially you’d put it in the same place(s) that have the check to make sure they’re in the same Layer. That actually avoids a whole host of the architectural problems with having the Layer (visual sort-order) change. I think that would be both easier & more robust (and more intuitive for the module designer) than the move-the-cargo-between-layers strategy.

When a Mat is dragged, the pieces on it should not generate any “spurious interactions” with other non-mat pieces (and for that matter, though as a secondary priority, cargo pieces on other mats). So it should not pull non-mat pieces into stacks for example, and it should not do the various buggy-feeling behaviors we’ve gradually been eradicating where e.g. the cargo pieces on the mat get nudged by stacks & decks & snap-to’s etc.

Having Mats also be Cargo is presently not supported. It would be “geometrically more difficult” to architect. Theoretically possible of course, but I’m sort of saying … not in 3.6!


This already works fine, nothing needs to be changed here. If you drag a stack of cargo onto the mat, they stay stacked and on the mat. They are not stacked with the Mat, Mats are non-stacking, but they are stacked with each other and work perfectly from what I can see, except for the interactions with what is off the mat.

It also works dragging additional cargo on to the mat and have it stack with existing cargo, again, once you remove the interaction with underlying pieces.

Another idea. (@Technical mode on) How about we modify the way the PieceMover finds Merge Candidates and prevent Cargo on a mat merging with any pieces not also loaded on the same mat? That should prevent all interactions with pieces under the mat, it would be as if they did not exist for the pieces on the mat.

Yes, I completely agree with the @Technical Mode node!

I would expect mats to be able to stack on each other. Cards as mats would seem to be a very common application. Maybe I misunderstood your comment?

Unfortunately, there is no way that can happen. The tricks we had to pull to get mats to work at all just won’t allow for stacking mats.

OK. Best make that very clear in the editor and/or documentation. Cards carrying tokens was one of the first applications I thought of.

Just to be clear, does this mean that any piece that has the mat trait can’t stack with any other pieces with the mat trait, even if they currently contain no cargo? Like Benkyo, I was thinking about using this with cards that can carry tokens, and in my use case, the cards would only hold tokens when not stacked, but it’s now looking like that won’t work.

I suppose I can use some Replace with Other trickery to work around that, though…