Token Order (Move to Back/Front)

Last night my players were fighting swarms in a game I am GMing. The swarms were under the player tokens where they were supposed to be. But when a swarm got hurt, I couldn't move it on top of the player for a quick edit. Before, I pushed the player to back, tweaked the swarm's life bar (and everyone saw it go down) and then sent the swarm "to back" again. It was tidy and took just a few seconds. Now, all I could do was move the swarm to its own space, change it, and put it back under the player once everyone had looked at it. Is there a way to get the old behavior back?  Send to back/front used to work fine for me (as the GM).

This was a behavior that was changed with the AFoW revisions near the beginning of the year. Controlled tokens sit on top of uncontrolled. You might be able to change the behavior by specifically assigning yourself control of monsters, but I haven't tested it.

As the GM, I thought I controlled everything.  Do you mean I need to specifically assign control of both tokens to me, instead of leaving that blank? Hmm... I just tried that and it didn't work. The player token says "determined by character settings" and for the monster I made it controlled by "me" instead of blank. Next, I tried adding "me" to the player token permissions as well (so now it's him and me) and just "me" on the monster. I still cannot move the monster on top of him. 

I have a similar stacking problem, and my players do also. If I put a swarm or area effect token on top of them, they can't see their tokens until I move the swarm. To reduce the HP of the swarm (if it's on the bottom), I usually just access it through the character sheet. I double-click to minimize the character sheet when not in use, so I don't have to dig through the Journal again for it. I hope this is useful to you.

Very strange. I just did some testing, and I can move things to front or back without issue, regardless of control. This was not my understanding.

Odder still that the two of you are having opposite problems. I'm kinda stumped.

Thanks for chiming in, Mike. I don't have sheets for most of my monsters (and certainly not for obstacles or AOEs) so that will only work for players and NPCs for me. What I'd like is a workaround to make it work like it used to, i.e., front and back "just work" when the GM uses them. I read a thread about sight and ownership being at play, but it didn't work for me, and since I couldn't ask a clarifying question there (it was too old) I started a new thread here. I don't use Advanced Fog of War, so it's a shame I can't disable it and have stacking work intuitively. Considering how often my tokens overlap vs. how often I use lighting, I would do that in a heartbeat!

Keith, you described exactly what I want!  "I just did some testing, and I can move things to front or back without issue, regardless of control." Does it work for you when one token is "defined by character settings" and the other one blank?  I am wondering if the order the token was created on the map matters here. In the fight I was running, a shambling mound turned into two swarms when it died, so I pasted the swarms onto the map later.  But, no matter what I tried, that swarm would not  go under the character.  Edit: And when I say I "pasted" the tokens, I have a map where I keep my prepared tokens for certain adventures, and then I copy and paste them where I need them. Some of them may have been created years ago, and I'd certainly still like to use them (and I could before).

Yes it worked as both an assigned and controlled token, and as an unassigned graphic.

Thanks for confirming, Keith. I decided to go and do more testing, and this time, I think I figured it out.    It was only when a token was assigned and had sight that it began ignoring the commands. I started with two unassigned tokens like you did. I can move them front and back with no problem. When they are both assigned to me, I can do the same. When they are both assigned to me, but one of them has sight and the other does not, the one with sight always stays on top. When I give them both sight (and they are both assigned to me), I can also switch them back and forth freely. Finally, when I tested them both unassigned but one had sight and one didn't, I could freely switch their positions. With all that in mind, I re-tested my unassigned, pasted swarm -- and got it to work by assigning the swarm to me only (the GM) and giving it sight. I could send it behind the character or move it back on top -- but then "to back" stopped working for everything else (other monsters, NPCs, etc.) since they were unassigned and unsighted. To send the swarm behind them, I had to remove "has sight" from either the swarm or the character -- and then turn it back on when I wanted the swarm to go on top of the character again. So, in summary, if two tokens are both assigned and sighted, you can move them front and back relative to each other . However, those settings also force the tokens to be "always on top." To change that, either a) the "blocking" token must also have both ownership and sight so you can use "to front" or b) the "to be blocked" token must lose sight or ownership. If it's a character, you can toggle off sight and watch it disappear behind another token that was moved "to front." I'm glad I figured it out, but it's frustrating there isn't a command or setting that  always works . The workarounds are OK, but unless you make all your monsters, NPC and scenery tokens owned and sighted, you won't get consistent results with front/back. And even if you did, doing so ruins fog of war and dynamic lighting for those who use it.  Is this really how roll20 is going to leave it, or is it being looked at?  

I believe it was deemed necessary in order to solve some performance cases of Dynamic Lighting. There were complaints at the time, but this is the way it works now. THANK YOU for figuring out the rules. I only had dim memories of the discussion at the time. If you wanted to write up a Stupid Tricks entry on this, I'm sure others would benefit. If not, I'll do it when time allows.

Happy to help.  I think it would be good if you tested to make sure it works for you the same way, then we can figure out how to write about it so it's not confusing. As I was explaining it to a friend after lunch, he seemed to understand the inverse better than the problem. When I told him "front and back commands work fine unless the token is assigned to an owner and has sight, like your character token " we had a good baseline.  Then I said " That's because an owned/sighted token will default to the front, and will always show up on top of unassigned and/or unsighted tokens. " That means your character probably can't hide behind a tree token, since that token is most likely unassigned and/or unsighted. So how do  you hide behind that tree token? First, have the GM send the tree to front. Then, you can either temporarily remove sight from the character token, or you can make the tree owned by the GM and give it sight. In other words, to switch positions you need both tokens to be owned AND sighted or neither of them to be (i.e., remove owned and/or sight for both of them). Does that help?  Lol, I understand how it works now, but making it simple is still difficult. See what you can do when you have time!