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 .
×
Create a free account

Players Tokens always on Top regardless of Token Layering.

While this may seem potentially a boon, it's very much a logistical nightmare for GMs who try to use a background and foreground objects. Unfortunately at the moment if a player as a token that's specified as being owned by them the token will always be on top , disregarding the numerous times a gm hits send to back. This seems entirely counter-intuitive to the actual function of "Send to Back" or "Send Back" for a token. I should not have to worry about each individual player having a different screen because their token takes priority over other tokens. From what I understand this happens regardless of browser, from Firefox to Chrome (both the latest versions). This happens regardless of any addons on the browser, even on default ones does this occur. This is on Windows 10 as well. Could we please have the VTT actually look the same for each player without having to worry about layer priority? This cannot be seen GM side, but if you place yourself as a player in the game after giving yourself a token. The token will start to ignore priority of the token's proper layer.
1590120011
Kraynic
Pro
Sheet Author
I believe this is intentional behavior so that players can't "lose" their token behind something else and not be able to select it. There was some discussion about the token z-order behavior in this thread (and explained in the directly linked post):&nbsp; <a href="https://app.roll20.net/forum/permalink/7894280/" rel="nofollow">https://app.roll20.net/forum/permalink/7894280/</a>
1590120872

Edited 1590121023
I understand that working by default . However, the problem as it stands is that if the GM specifically &nbsp;tries to send a player owned token to the back it has no effect. The particular problem is that "Send to Back" has no effect despite the GM actually attempting to do so. Why is there no real method to override this? Additionally, this is without dynamic lighting or similar, its only with a player owned token.
1590124116

Edited 1590124162
Can you give more details about what you are trying to accomplish in this use case? What token are you putting in front of the player token? If you succeed, your player will not be able to get to their token; is that part of what you want?
1590125155

Edited 1590125292
Basically it's meant to look more like a background with said characters on it more than a map for battle. Typically characters don't need &nbsp;to move themselves in this instance but they're never to be behind an object of their size or greater so they couldn't select themselves. At the present time you basically cannot have anything in front of a token akin to a desk as they will always pop up in front of it and it looks different per player with a token. Think of what a VN would look like, where it's characters on a background with scenery objects, but you have some form of movement. The use case is to provide a new sort of map should the players be about in a town or place where talks take place rather than an empty background. At the moment this doesn't quite work as well as it could if GMs can't change the actual layer this token goes on, not the default the layer, simply if "Send to Back" and "Send to Front" worked as it did for every other type of object. Before I forget, simply putting them in the background layer does not help, especially if one was to use Tongues or any other sort of API that relies on player tokens.
Try unchecking "has sight" for the player token.&nbsp; It's a limited solution, but might work fo what you want here.
1590188318

Edited 1590188334
Valerie M. said: Try unchecking "has sight" for the player token.&nbsp; It's a limited solution, but might work fo what you want here. I think you misunderstand. This is without any Dynamic lighting, so by default "has sight" is off on everyone and toggling it on or off does absolutely nothing to change the priority the tokens have.
1590189504
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
I believe the "has sight" still affects the Z-Order. regardless of page settings. In any case, this page may have some value to figuring out a solution: Token Z-Ordering
That leads into it's on problems then. It'd basically imply I would always &nbsp;need Pro or Plus to actually control the layering system of tokens, which appears to be an entirely inherent flaw. All I want is the Z-Ordering to actually work even as the page advertises For example: " You have a mount and a PC token, and both have sight. For the PC to appear in front of the mount, you'll want to either drop the PC token onto the tabletop last, or reorder them using the right-click menu to send the mount to the back." At the present moment the latter does absolutely nothing &nbsp;in terms of changing order if you have no dynamic lighting.
1590198356
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
I'm trying to duplicate this in a game created under a dummy account to which I have invited my main account to be a player. I seem to be able to send to front and back without issue. Is there a specific set of steps I can follow to reproduce this?
1590231227

Edited 1590231786
Basically, set a token to be owned by your player account (possibly set default token as well) and put something on the token layer on top of them (unowned). As expected on player end it should display their own token on front. However if you (as GM) attempt to send the owned token to the back, this will not change on the player end. Particularly with multiple players this is easier to see as each one of their token(s) will try to be at the front, creating a very very different display per player. The main issue &nbsp;is that "Send to Back" does absolutely nothing to a player token. Yes, by default they will pop up in front of all tokens, but the actual functionality of "Send to Back" or "Send to Front" arbitrarily not working for an owned token makes little to no sense. If I choose to change the layering order, this should actually be reflected to players, not have inconsistent VTTs across players and gms. I really should not have to set every object on the token layer to be owned by gm simply to provide a consistent view per player.
If i read the description of the z-ordering functionality, showing the player tokens on top is a consious design issue to ensure that players have the highest chance to be able to always select their token.&nbsp;You might not like it, but i think overall this was a defendable choice.&nbsp;
One option is to place a 2nd set of player tokens to the side of the map so they're accessible for selecting. Then you have more options for the PC tokens that present their locations on the main area. For example, you can place PC Tokens on the map layer, and swap to the token layer only when players need to move the tokens around the map. If you move the tokens to the map layer, they will always sit below items on the token layer but will be visible, whether owned or not. You could also use the API to toggle those map PC Tokens to owned/unowned when players do/don't need to move them.
Chris said: You could also use the API to toggle those map PC Tokens to owned/unowned when players do/don't need to move them. Note that the API is a Pro subscription feature.
1590266633

Edited 1590267876
Martijn S. said: If i read the description of the z-ordering functionality, showing the player tokens on top is a consious design issue to ensure that players have the highest chance to be able to always select their token.&nbsp;You might not like it, but i think overall this was a defendable choice.&nbsp; Yes, I understand the conscious choice, but what I do not &nbsp;understand is why I--as a GM--can't change this via the actual dialogue options of Send to Back and Send to Front.If I wish to change something from the "default" ordering, then I should be able to perfectly fine. 25x25 is a fine map size but we can change it from default, token sizes being 70x70 is fine but we can change the grid sizes, you could run a game with no tokens as player owned but we get to change that too from default. Why is it that Z-Order is simply something entirely out of GM control when, you know, actual dialogue options exists to send to back, send back, send forward, and send to front exist? At the very minimum there should be an option to disable this forced Z-Order within a token's options rather than just the state of Owned vs. Unowned (and sight vs not sight for pro I guess) tokens. It doesn't seem quite right that by design GMs would have no control over layering certain &nbsp;tokens, and that the VTT can look drastically different per player. &nbsp;&nbsp;&nbsp;&nbsp; Rabulias &nbsp;said: &nbsp;&nbsp;&nbsp;&nbsp; Chris &nbsp;said: &nbsp;&nbsp;&nbsp;&nbsp; You could also use the API to toggle those map PC Tokens to owned/unowned when players do/don't need to move them. &nbsp;&nbsp;&nbsp;&nbsp;Note that the API is a Pro subscription feature. That is correct, I'm trying to puzzle together exactly why changing Z-Order of tokens is basically locked to those with access to the API or Dynamic Lighting at all. Tokens can't "have sight" without DL so there goes any chance of changing order according to that wiki entry too. Also this API itself would only work provided you set no default token whatsoever for the player end, since their ownership is based on a per sheet level, unless you really, really wanted to do every step for setting default token in a per sheet level and per player in your campaign.
&nbsp;&nbsp;&nbsp; Rabulias &nbsp;said: &nbsp;&nbsp;&nbsp;&nbsp; Chris &nbsp;said: &nbsp;&nbsp;&nbsp;&nbsp; You could also use the API to toggle those map PC Tokens to owned/unowned when players do/don't need to move them. &nbsp;&nbsp;&nbsp;&nbsp;Note that the API is a Pro subscription feature. That is correct, I'm trying to puzzle together exactly why changing Z-Order of tokens is basically locked to those with access to the API or Dynamic Lighting at all. Tokens can't "have sight" without DL so there goes any chance of changing order according to that wiki entry too. Also this API itself would only work provided you set no default token whatsoever for the player end, since their ownership is based on a per sheet level, unless you really, really wanted to do every step for setting default token in a per sheet level and per player in your campaign. Sorry if my point was misunderstood. You don't actually need the API to change whether a token represents a PC or is controlled by a player. Granted, it's easier to toggle this back/forth on the fly with the API. But my real point is that if you orphan a token from its character sheet (by changing the represents field to none), the token becomes a simple object on the TT -- not subject to the z-ordering rules that are upsetting your design. You can do that with Tokens that represent PCs. So I'm suggesting you detach a set of PC tokens from the PC character sheets to lay out on your map so you have more control over it's z-ordering, while setting aside a 2nd set of PC tokens that ARE connected to sheets off on a sideboard (so players can access their tokens).