Issue with Token Layers After June 4 2019 Patch

Hi guys,

Since the patch that released on June 4, 2019, I've been having a strange bug with tokens and I'm not sure if it's just me who's having the issue.

Firstly, this only affects tokens that have player control.

When I try to change the layer of a player-controlled token, it doesn't visually change where the token is, but the 'box' around them remains the same. This makes things extremely awkward for when re-ordering player tokens in the layers.

Here's an example:

In this image, though you can't see it, I can guarantee that the character token is at the back layer, whilst the sledgehammer is at the front layer. This should mean the sledgehammer is in front of the token marked '<4> César', but it isn't. Both the sledgehammer and the character are on the token layer.

If I were to click where the sledgehammer should be, however, I will select the sledgehammer. So the hitboxes are being moved whilst the image isn't, which is... not too helpful, as you can imagine. 

So far, I have tried: deleting and pulling tokens back on (no effect), clearing my cache, backing up my server, closing and opening chrome, restarting my computer, deleting all API's in case they were interfering, and copying server to see if the backup doesn't have the issue (it still does, however). No luck with any of those.

The strangest part is that I'm only having this issue with one server. Other servers where I'm a GM seem to manage token layers just fine, so I'm not sure what the problem could be.

Is it just me that's having this issue / any ideas on how to fix? This was not happening prior to the June 4 patch. I'm not sure if that has something to do with it.

Yes same for me as well.

Glad to see it's not just me having the issue. Is this with all your servers, Mike, or just certain ones?

Confirmed: A token that represents a character will always appear "in Front" of one that does not. This occurs even if the tokens are manually set to front or back.

Additionally, it's no longer possible to select multiple character tokens and delete them simultaneously. Only one is deleted at a time.

I'm not sure if I speak for everyone, but there are times where I'd want to hide a character token or have something else in front of it, for visual purposes.

Having tokens constantly on top of everything might be helpful in some cases, but I can see it being a common hindrance as well.

Then again, if this was a requested change for a while by the majority, don't worry about it. Might just be me.

Being able to hide tokens behind scenery is of value to me as well.  :/

I wonder if this is anticipation of the upcoming layer enhancements?

My guess is that it has to do with making tokens visible behind fog-of-war, I think that's a recent change.

Wouldn't it be better to make a new server or something to test this stuff out first?

I noticed a similar thing when I logged in last night to work on my campaign.

The characters have various animal NPCs, including an owl, a dog, and a couple of mules. The owl and the dog can only be controlled by one player (the owning character) while the mules can be controlled by anyone in the party.

It used to be that I could control which token appeared above the other by using the "To Front" or "To Back" options on the token's menu. For example, when we finished playing last Monday night, the owl was left perched on the mule's back. But after the Tuesday patch, the owl token disappears beneath the mule token, no matter what I do with the "To Front" or "To Back" settings.

Experimenting has shown that tokens which can be controlled by all players will now always appear on top of those which can only be controlled by one player. With sometimes undesirable visual effects.

For example, the characters also own a wagon, the token for which can be controlled by any player. We used to be able to depict the characters riding in the wagon if I made sure to use the "To Back" option on the wagon's token. But now, the character tokens disappear beneath the wagon, regardless of "To Front" or "To Back" settings. Again, because all players can control the wagon token, but only the owning player can control their character token.

I realize these are somewhat specialized examples, but I'm sure many others will surface and for many other Roll20 users. Previously, I never had any real issues with players being able to access their tokens, as long as I used the "To Front" and "To Back" menu options appropriately.

I have AoE tokens that any of my players can pull from the journal and put on the map. These now can’t be moved behind the player tokens since they can be controlled by all players. They were a marketplace purchase, so this change specifically breaks a product sold by a marketplace creator on Roll20. It would be nice to be able to have my 20 ft radius fog cloud appear behind the player tokens again when I click “to back.”

I agree 100% with Brent E and Loren the GM. I have exactly the same issues they do.

Also why wasn't this tested and especially why wasn't this announced?

I want to have complete control over how things appear on my table, and I utilize to-front/to-back to arrange things the way I wish them.  Please don't take that control away from the GMs :(

Ditto here. For example, I use a player controlled token for spell effects that must go to the back in order to show all character tokens in the area. Controlled mounts must also go to the back, as must boats and carts.

Drespar said:

Hi everyone! We have confirmed this behavior on our end as well and that it is occurring intermittently-- refreshing the page may fix it for a time.

The design intention is to always have controlled tokens on top of other tokens for better visibility to the player (documentation will be updated within the wiki to be in-line with this change). That said, you should still be able to select and delete multiple tokens at the same time.

Thank you all for the extra information!

Pardon my french, but this is utter crap. The way I setup my games require that I as GM have control over the placement of tokens. Why spring something like this on us unannounced? 

Hi everyone,

We've investigated your reports and narrowed down the issues. The recent rendering change to ensure tokens you control end up on top of lighting introduced three problems:

1. Tokens you control aren't respecting their z-ordering when rendering.
2. Tokens you control that aren't on the object layer are jumping to the top, causing pages with map elements that have been set to be controlled by a player to jump to the front for them.
3. The VTT is not deleting multiple tokens you control, if you select them as a batch and attempt to delete them together.

We expect a short turn around on these issues with a hotfix in the next few days.

Drespar said:

The design intention is to always have controlled tokens on top of other tokens

This is bad design.

Steve K. said:

We expect a short turn around on these issues with a hotfix in the next few days.

ARE YOU F&#8ing KIDDING ME?

This has made my game literally unplayable.

I have lost money because of this change, and will continue to do so every day until it is fixed.

Do you even know the extent of the damage you have done here?

Why would you make vast sweeping changes to fundamental aspects of your PAID SERVICE without testing them first?

This is directly related to the idiotic change to interactions with the Fog of War, as I will demonstrate:

A page as shown to the GM, on Token Layer.

That same page, on the Map layer.

Moved the images on the map layer down to reveal lots of important stuff.

And back to the Token layer.

Tell me this isn't directly related to the Fog of War 'fix' you rolled out. With Roll20's recent history, I'm sure everyone will believe you.

Tell me you have 'experts' who did this. People who know what they're doing. People who thoroughly tested it beforehand.

I'll believe you.

Because I trust Roll20 to be honest, open, and fair with their paid customers.

I know, because I used to be one.

Wint said:

Drespar said:

The design intention is to always have controlled tokens on top of other tokens

This is bad design.

This is bad A Whole Lot of Things.

I too have lost a good chunk of hours due to this, but do remember mistakes happen. They're going to alleviate these issues, as frustrating as they are. At least they located the issue in a 48 hour period and after which wish to fix them within a 72 hour period (Timing based on this post of course). This mistake will probably lead to them re-evaluating their testing period so this won't happen again, hopefully. 

I have the same type of cave tiles. I made a cave system a few days ago with the tiles on the map layer, and tokens on the token layer.  In which it was fine, but when I loaded the page last night the tokens were underneath the map layer?

Hi all!

The Dev team just released a fix for this that includes some changes to behaviours, so please give it a look.

Fixed it for me, thank you for that. 

Another user posted a workaround in another thread to the bit of functionality that changed: If you really do need a non-player token to be on top of controlled tokens, set it to being controlled by the GM.

Bunny said:

Hi all!

The Dev team just released a fix for this that includes some changes to behaviours, so please give it a look.

Stephanie B. said:

Another user posted a workaround in another thread to the bit of functionality that changed: If you really do need a non-player token to be on top of controlled tokens, set it to being controlled by the GM.

This is, and I don't want to under-emphasize this, one of the worst changes the roll20 dev team has ever implemented. Beyond the fact that such a major change was stealth launched, it's just bad design. This isn't an over-reaction, you've decided to break one of the fundamental and foundational features of roll20. I struggle to put into words just how dissatisfied I am with this change, and equally struggle to even attempt to understand what the decision and process that led to such an upheaval being sprung on users for one of the most basic applications of the platform.

This is still not solved after the hotfix. Attached is a screenshot to demonstrate.

As you can see, I have both player tokens and NPC tokens on the map. NPCs are set to be controlled by the GM, the PCs by their various players. In my journal, I have this product purchased from the Marketplace and installed: https://marketplace.roll20.net/browse/gameaddon/460/area-of-effect-template-pack

It creates various AoE templates that are controlled by all players (this being one of the key features of this product - I do not have to be the one to pull the token out and position it, speeding up gameplay). When one of these templates is dragged out to the map, it stays on top. The attached image shows it even after being sent To Back sitting on top of all of the tokens, because of the ownership. Additionally, with the new update, I cannot select the tokens under it (with the update on tuesday the broken behavior would still put the hitbox to back, allowing the tokens under it to be selected, even though the image still appeared on top of those tokens).

Please restore functionality for your marketplace purchases.

And please think through/test the ramifications of your updates before rolling them out. I understand this change was part of the fixes for a AFoW issue of keeping tokens visible, but it seems that every update that has rolled out for the last several months creates new issues. I appreciate the team is trying to fix things, and trying to grow the tabletop, but it is growing very frustrating to try to keep up with what is currently broken, having to explain that to players, and try to find workarounds.

Stephanie B. said:

Another user posted a workaround in another thread to the bit of functionality that changed: If you really do need a non-player token to be on top of controlled tokens, set it to being controlled by the GM.

I posted that, and after testing, I found there is still a major problem. Players place spell template on the table all the time. There is no way to see which NPCs are affected by the spell, since the token must be controlled by the players in order to be positioned, but covers all npcs. This situation will likely affect all users of spell template packs on the marketplace.

The hotfix did nothing to resolve the situation I described above: Tokens which can be controlled by all players still always appear on top of those which can be controlled by only one player. Using the "To Front" and "To Back" options on these tokens has no effect on them.

I will say that I tried keithcurtis' workaround, and if I give myself as the GM control of a token, in addition to the owning player, then it restores my ability to use the "To Front" and "To Back" menu options. But that doesn't really feel like a permanent solution to the issue.

Hi everyone,

On June 4th, we rolled out a fix for Dynamic Lighting and Advanced Fog of War concealing tokens you control. Our solution was to make tokens you control appear on top of other elements on the token layer so you’d never lose them behind darkness or under other elements. While this solution works for the majority of cases, our users let us know about a variety of creative use cases that this change would make either more difficult or not possible.

We understand that this fix had effects reaching beyond its original scope. At this time, we are taking action to roll back this update to restore the previous functionality from Monday June 3. This will return some incorrect functionality from Advanced Fog of War (tokens being concealed) that was present before the update.

We are looking to provide a more complete and robust fix that does not affect other aspects of the play experience. We will update you on a timeframe within the next week as we solidify our resolution.

Our sincerest apologies for the trouble, and thank you for your efforts in alerting us to the difficulties caused by this update.

Thank you, Steve!

Thank you Steve!

I applaud this action. If a bug is caused by a code change and it cannot be easily and quickly fixed, rolling back provides the space to reassess the attempted solution without pressure. Well done, Roll20.

Thanks Steve; looking forward to things being back to normal again.

We've pushed out an update to the Development server with a tweak to the tokens you control vs lighting update. The major difference in this update is that only tokens you control and also have "has sight" is checked are pulled to the front.

We believe this adjustment resolves most of the concerns around having large set pieces that are controlled by players on the token layer, like spell effects or sail boats, since these things shouldn't be given "has sight". Please let us know if this change isn't meeting your needs or is still disrupting your existing style of play and how.

Steve K. said:

We believe this adjustment resolves most of the concerns around having large set pieces that are controlled by players on the token layer, like spell effects or sail boats, since these things shouldn't be given "has sight". Please let us know if this change isn't meeting your needs or is still disrupting your existing style of play and how.

This doesn't resolve player token on top of mounts, since both should have "has sight." This is especially true for games like DnD, Pathfinder, et al. where you have Paladins or Rangers that commonly have animals that they take into dungeons. e.g., tokens with "has sight" using dynamic lighting &/or advanced fog of war will still be fighting for positioning even after this change.

This does feel more like a bandaid rather than a real fix, as it doesn’t solve for all use cases (such as a mount as Wint pointed out - I am sure there are other use cases as well). I’d prefer to see some sort of new separate “keep token at front” toggle on the token (or the inverse, something that allows you to disable this new token behavior). As it is, this feels very hacked together and unintuitive, while also limiting my GM control of the tokens.

Wint said:

This doesn't resolve player token on top of mounts, since both should have "has sight." 

Can you expand on this use case? I'm having trouble understanding what the issue is here with your F20 example. You have a paladin who has been given control of his token with has sight and his mount's token, which also has sight. The GM would pushes the mount to the back and for the player his PC token would appear on top of the mount. For the player his token and his mount appears on top of other tokens.

The above example works well for the scenarios I'm imagining, but you two clearly have concerns. What's a use case this doesn't this fit?

Loren the GM said:

I’d prefer to see some sort of new separate “keep token at front” toggle on the token (or the inverse, something that allows you to disable this new token behavior). 

Loren, I hear what you're asking for with a toggle option for this functionality. We're reluctant to do that because the Dynamic Lighting and Advanced Fog of War are already the most complicated tools on the VTT. To the point where for new users they can be intimidating and sometimes inaccessible. Adding more options increases the cognitive load required to learn the system, so they need to be added with a deft hand. Which is why I'm hoping you'll help me understand your pain points here.

Steve K. said:

Wint said:

This doesn't resolve player token on top of mounts, since both should have "has sight." 

Can you expand on this use case? I'm having trouble understanding what the issue is here with your F20 example. You have a paladin who has been given control of his token with has sight and his mount's token, which also has sight. The GM would pushes the mount to the back and for the player his PC token would appear on top of the mount. For the player his token and his mount appears on top of other tokens.

The above example works well for the scenarios I'm imagining, but you two clearly have concerns. What's a use case this doesn't this fit.

If the horse is controlled by everyone it will end up on top, correct?

Ravenknight said:

If the horse is controlled by everyone it will end up on top, correct?

Only on top of tokens they don't control. So, if the horse was controlled by all of the players, then it could still be moved back and be behind any of the players other tokens they control. As in above where the rider, controlled by a player, is above the horse, also controlled by the player, but not the goblins, which are not controlled by the player.

As I understand it, there are two z-orders that you can sort in. From top to bottom:

1. Player-controlled, all sortable
2. Uncontrolled, all sortable

Uncontrolled cannot be placed on top of Controlled, but with this latest tweak you are free to move tokens to front or back within their own group. In the rare event you want something like an uncontrolled NPC on a controlled mount (Not sure how that would work for movement, regardless of ordering), assign control of the npc to yourself as GM.

Sounds functionable. I still dislike any kind of forced placement but I can work with this. Thanks Steve.

I think this will work for my own purposes (speaking just for me). I too don't like the imposed constraints of splitting up the order, but if it's necessary in order for those who use AFoW to have a workable system, I understand. Thanks to the devs.

Wholly agree with both Ravenknight & keithcurtis' comments.

Same here, I can now arrange and stack tokens as needed. Thanks to the Devs for getting this worked so quickly.

We're going to leave this change on Dev for a few more days to get feedback. Given the positive responses we're planning on rolling out these changes with our next code push. Please let us know if you're experiencing any issues or if this change still isn't meeting your needs.

Steve K. said:

We're going to leave this change on Dev for a few more days to get feedback.

Oh, so there is a Development server. Why was this not tested on that first?

Steve K. said:

Given the positive responses we're planning on rolling out these changes with our next code push. 

I'm not sure which thread you think this is. Some other thread may have more positive responses. This one seems pretty negative to me.

Steve K. said:

Please let us know if you're experiencing any issues or if this change still isn't meeting your needs.

If you've undone what you did, then yes, thank you for meeting my needs.

Yes, there is a dev server to test things on.  But that relies on Pro subscribers running their games (or at least testing) on the dev server.  Also, if you actually look at the posts on this page the tone has changed a bit.  No need to bring the hostility back.

Hi, everyone! We have released the changes to token z-ordering that were on the Dev server last week.

From the release note:

Tokens you control display above tokens you don't own. This was previously released, then rolled back to address issues brought up by users. It has been tested on the Dev server for a while now.

• If you control a token that has sight, it displays in front of other tokens. This prevents users from losing their tokens under Advanced Fog of War, Fog of War, and Dynamic Lighting. The token and its bars and icons will appear above the black fog of war.
• The player who controls the sighted token will always see it in front of tokens they do not control or which do not have sight. This is true even if the GM has changed their order.
• GMs can reorder all tokens relative to each other. The player controlling the token will always see their token in front, but other players will see the token where the GM has set it (in front of or behind other tokens).
• If the player controls more than one token with sight, the tokens will overlap either in the order the GM has set them, or with the most recently dropped token in front. 
• Using CTRL-L, the GM will see what the token sees, with that token in front of other tokens, if it has sight. If the token does not have sight, the GM will see it in the z-order the GM set.

Things that did not change in token z-ordering:

• Tokens you control that do not have sight (commonly used for spell templates) are not pulled to the front. 
• Tokens you do not control that other players control are not pulled to the front.
• Tokens are layered with the most recently-dropped token in front by default.

Some example use cases:

• 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.
• You have a PC that you control, and a spell template that everyone in the game controls. The spell template does not have "has sight" enabled. When you drag and drop it onto the tabletop, it will appear behind all tokens that are controlled by other players and have sight.

Please post any bugs or issues with these changes in this thread, as the team is watching and paying attention to your feedback.

Stephanie B. said:

The player who controls the sighted token will always see it in front of tokens they do not control or which do not have sight. This is true even if the GM has changed their order.

GMs can reorder all tokens relative to each other. The player controlling the token will always see their token in front, but other players will see the token where the GM has set it (in front of or behind other tokens).

This is emphatically not what was discussed above by Steve K.

Wint,

Can you clarify what you mean? It's live now, so you can take a look and see if there's a particular use case that it isn't meeting.

Thanks,
Stephanie

Wint said:

Stephanie B. said:

The player who controls the sighted token will always see it in front of tokens they do not control or which do not have sight. This is true even if the GM has changed their order.

GMs can reorder all tokens relative to each other. The player controlling the token will always see their token in front, but other players will see the token where the GM has set it (in front of or behind other tokens).

This is emphatically not what was discussed above by Steve K.

Under this new system, a token controlled by a player with sight is always pulled to the front of the z-order for that player regardless of what the GM does with ordering. This is the same problem being implemented as a "fix" as what was already discussed by everyone earlier, and comes after Steve K outlined a solution that did not involve this issue. You're recreated the wheel here, you're still going to run into issues with graphics for spells, or other tokens being used as mounts, or the entire litany of issues that was already discussed and outlined above. Its very frustrating to have to have this conversation, again, and explain, again, how these "fixes" are in fact making things worse.