Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×

Controlled tokens should stay on top

Score + 2
Presently, if I have a token for my character that I'm moving on the map, if I move it onto another token (either owned by another player or just something the DM dropped on the map) my token ends up BEHIND (or underneath, if you prefer) the other token. Every. Singe. Time. That means that the other token has to be moved out of the way by someone else, in order for me to access my token to move it. IMO, a token I control, should always remain on top (or in front if you prefer that terminology). When I move it onto the space of another token, the token I'm moving should always remain on top so I can keep accessing/moving it. And, if someone moves another token on top (or in front) of mine during their turn, when it comes to my turn, I should be able to access my token without the other token that was on top having to be moved out of the way temporarily.
1782651830

Edited 1782651852
Under the gear icon tab within that game, in the "Graphics Display" section there is a setting for this:
It's set. It doesn't work and never has. Not in legacy, and not in the newer version of the VTT.
Odd, it works for me, as a player, in two different games (both jumpgate), even when I, as DM on a separate account, force another token to be in front. Which it is for my DM account, but my player account still sees "my" token as front. Just to ask the obvious: - Did you, as player, turn it on? The control is per-person, so the DM's setting has no affect on the player account - Are the games non-legacy?  This is a jumpgate feature and the control doesn't even exist on legacy games - Is it possible that the DM set the other tokens to allow them to be controlled by you also (I have one DM I play with who routinely gets the view and owner permission fields confused and sets control to all players)? If not, then this sounds like some kind of bug affecting your token or games.  Although I suppose it could be a browser issue (I use Mac Firefox).
There was a similar setting in legacy. I don't remember what it was. It didn't work either. The feature is turned on for me: This is a "jumpgate" game. It doesn't work for me. It doesn't work for other players in the same game. It has not worked for me in MULTIPLE games over MULTIPLE game sessions. It has not worked for players in games that I've DM'ed (and, yes, they've turned it on too). I use Chrome. Most of the other players have used Chrome. Some have used Edge or Firefox.  When I move my token to where there's another token - including tokens not controlled by me - my token ends up being inaccessible because it's BEHIND the other token. The DM has to move the other token out of the way in order for me to access my controlled token. And, yes, I reported this to the Help Center a long, long time ago. I don't remember the response. Ken S. said: Odd, it works for me, as a player, in two different games (both jumpgate), even when I, as DM on a separate account, force another token to be in front. Which it is for my DM account, but my player account still sees "my" token as front. Just to ask the obvious: - Did you, as player, turn it on? The control is per-person, so the DM's setting has no affect on the player account - Are the games non-legacy?  This is a jumpgate feature and the control doesn't even exist on legacy games - Is it possible that the DM set the other tokens to allow them to be controlled by you also (I have one DM I play with who routinely gets the view and owner permission fields confused and sets control to all players)? If not, then this sounds like some kind of bug affecting your token or games.  Although I suppose it could be a browser issue (I use Mac Firefox).
Well, I don't use dynamic lighting, so I suppose that could be another reason why we're seeing different outcomes. I'm not doubting you.  I just can't reproduce the problem.