It appears the “Stack Normally” setting for the “Does Not Stack” trait in 3.6.0 beta2 is broken.
It seemed to be working in the first beta release.
Could you please describe in exactly which way it is broken? What happens differently between beta1 and beta2, how do I reproduce it?
Sure, the first time I used it was the same context as the second in the same module (a developmental module I am working on currently).
I am immobilizing some pieces with the “Replace with Other” trait when a turn phase changes. Before 3.6.0, the pieces all collapse behind the top piece in the stack, giving no visual cue that there is a stack of units there. I had been struggling to find a workaround for this when you guys released the first beta. When I tested the feature, it worked as expected. The replaced units were in a nice stack and not concealed.
Now I have the same behavior as before even after replacing the old pieces with new ones that have the “Stack Normally” feature selected. They all appear to “hide” behind the top piece of the stack, giving no indication that there are more units present.
The one thing that may or may not have been different between the first test and the second was the state of invisibility. I can’t be certain that the first test was done with Invisibility activated. In the second test it was activated.
Please let me know if you have specific questions or if you would like me to test something to support.
Could you please paste a screen shot of the Does Not Stack trait settings belonging to the immobilized pieces created by the Replace by Other traits.
Thanks.
I wasn’t able to reproduce this. I’ll need the module and a vlog file showing the problem happening.
Regards.
Just sent you a .vmod and .vsav …
generating a .vlog now
Got em, thanks, I’ll look at those tomorrow.
Thanks… also, just sent link to a .vlog of pieces freezing.
I’ve tested this quite a bit and still find that the pieces I “Replace With Other” in a stack on the board will collapse into one piece, showing no stack, even when “Stack Normally” is set on the “Does Not Stack” trait. (3.6.0beta2)
It would really help my project if I could get them to show a normal stack, giving the players a visual cue that there are multiple pieces on the grid square.
Incidentally, “hover” doesn’t show the hidden pieces either, amplifying the problem and further degrading player situational awareness.
Did you send me the vlog of pieces not Stacking? I only got the piece freezing ones.
I think I have a workaround for this issue. I will give you my results sometime today and summarize what I’ve isolated if everything works properly.
I have succeeded in developing a workaround for this issue in my case and will therefore mark this solved. Below is a summary if anyone is interested…
The module I am developing has hidden movement by both players. This is achieved with invisibility. At certain points in the game phases, Global Key Commands are triggered by the turn counter. These GKCs trigger the “Replace With Other” trait on game pieces in order to immobilize pieces. It turns out that it DOES matter who clicks the Turn Counter forward, triggering the GKCs. That Turn Counter advance is “owned” if you will, by the player who clicks it. This ownership causes certain functionality to be denied to the GKCs because invisibility denies certain things to non-owners. This is true even when the “Replace With Other” trait is outside of the “Invisibility” trait.
***In my case, this made it imperative that the “correct” player be the one to advance the Turn Counter into particular phases…otherwise, the “Stack Normally” setting on the “Does Not Stack” trait would be subverted. This also caused the stack viewer to be subverted, only showing the top unit on hover.
***My workaround / solution to this has been to separate the GKCs that trigger the “Replace With Other” functionality to only pertain to one player side at a time AND to force the Turn Counter advancement for those triggering phases to only allow the correct player to trigger the GKC… and this now works well.
I definitely find player ownership of the click that advances the Turn Counter to be highly desirable and I WOULD NOT change it. It is enormously helpful to be able to test for who clicked the Turn Counter advance button. This gives me the opportunity to prevent the subversion of my hidden movement module by ensuring the opponent must participate before revealing hidden pieces by improperly advancing turns during PBEM.
The one thing that MAY or may not be considered a “bug” or in need of alteration would be the inability to allow a non-owning player to advance the Turn Counter if it triggers a GKC that triggers the other player’s “Replace With Other” trait on invisible pieces and subverts the “Stack Normally” and “Stackviewer” features. As it stands, the status quo makes it imperative that the “correct” player advances the Turn Counter when dealing with invisibility and possibly other ownership-testing traits.
1 Like