Is it possible to stack together two counters belonging to different layers?

I need to have two different types of counters belonging to two different layers so I can hide one type (hiding its layer) and see only the other one.
But when two counters of different type stack together I’d like to see the stack when hovering the mouse over them… I can just see the counters belonging to the upper layer and not the others.
Is it possible?


From the Game Piece Layers documentation:

Pieces assigned to different layers will never combine into a Stack.

So what would you suggest to hide one type of counter and have two counters of different type stacking together?

One possibility would be that all the pieces that might need to get hidden have no image assigned in the Basic Piece trait at all. The piece image would go in a Layer trait with multiple levels, one that shows the image and another that is again blank, use the “Layer follows expression” and set it to track a Dynamic Property on the piece that you can adjust from a Global Key Command elsewhere.

Effectively, something (a toolbar button? another static controller piece that works like a button? whatever you want) will send a GKC to the class of pieces that needs to be hidden, they all have their Dynamic Properties adjusted simultaneously so that the Layer level on each toggles to the one with no image assigned.

1 Like

Not sure if this is what you are looking for but perhaps it will help…

A technique that I’ve used is to modify the Game Piece Layer property value on the piece that you wish to bring into a stack.

One example - player counters stacking with faction blocks in Liberté. I use movement triggers and a location/piece constrained GKC to determine the layer change needed. When the game player piece leaves the stack the GPL change is reversed.

I also use a dynamic GPL like this in Flying Colors (v2.6), to align ship/leader nationalities to a side for the game (so different nationalities may or many not stack together).

So in these cases the Game Piece Layer is assigned via a Dynamic Property trait rather than a Marker trait, correct?

1 Like

Dynamic Property trait rather than a Marker trait; yes, correct.

1 Like

Here is an extremely minimal proof-of-concept module demonstration the approach I laid out before: Demo Module

I wouldn’t be surprised at all to find that @marktb1961 has done it better, but this will show there’s at least a kernel of viability to my idea.

1 Like

I’d go with the worked example first, for sure.

There is something else to check out if @maxfra isn’t already aware of it… the MouseOver component allows you to specify those layers that the mouseover will display, other layers being ignored. Defining one or more mouseovers like this might be part of the solution.


Thanks Joel.
I got the same result using the invisible Trait instead of changing the layer to an empty/transparent image and commanding it using the same GKC.
The final effect is the same.
The problem (very little indeed) in case is that if there are many Type A and Type B together in the same stack (for example a stack with counters A, B, B, B, A) when B is invisible between the first and the last type A counter there is a gap 3 times wide the space of a single counter (that is Counters B are invisible but are anyway using the same space between the two type A as if they were visible).
Moreover the invisible Counters may be selected and moved anyway … you don’t see them but you may see the selection around it.

1 Like

I tried this solution that seems to work and I’d like to share it with you.

I have two layers: LayerOn and LayerOff.
LayerOn is active and LayerOff is inactive.
Usually Type A and Type B counters are all in LayerOn, so they can stack together and I can order them in the stack as I wish.

When I want to hide Type B counters I just move them to Layer B (Game Piece Layer is assigned via a Dynamic Property trait).

When I want to show Type B counters again I set LayerOff active (otherwise counters in that layer don’t get any command => is this correct? Counters on an inactive Layer cannot execute a GKC?), then move Type B counters to LayerOn and then set LayerOff inactive again. Eventually the situation is the same as the start. I used a Multi-Action Button to invoke the single commands.

It all works but there is a little lag using the last Multi-Action Button.

Is this normal?
Hiding counters using the invisible Train or sending them to an inactive layer is very fast.
Executing a Multi-Action Button invoking:

  1. Set LayerOff active
  2. Move Type B counters to LayerOn
  3. Set LayerOff inactive
    takes almost a second…which is fast … but not immediate.

Thanks a lot for your help.

1 Like

If I’ve understood your design right, you will need to set LayerOff active for the piece to receive a command because -

  1. If you select a stack, commands will be transmitted to all pieces in that stack. As per your implementation, pieces in GPL “LayerOff” will not be in the stack and so won’t be selected.

  2. Your GKC may be specifying search criteria that exclude the DP value when = “LayerOff” or, similar to point 1, your GKC may be limiting itself to the current stack.