Improved rendering of stacked Tokens: Interface elements of Tokens are no longer rendered on top of other Tokens that are stacked on top of it

[StrictlySkyler]

Implemented changes

• Added Token#voidMesh, which renders the Token#mesh at the position where it would be if it was part of the Token instead of the PrimaryCanvasGroup with ERASE blending.
• Removed PrimaryCanvasGroup#tokensRenderTexture without replacement.
• Removed ReverseMaskFilter and InterfaceCanvasGroup#reverseMaskfilter without replacement. System/modules that used this filter to mask their added Token interface elements simply need to add these elements to Token at a position beneath the Token#voidMesh.
• Removed GridLayer#borders without replacement. Token#borders are now once again children of Token.

Original issue

What happened?

When stacking tokens on top of one another, the statuses for underlying tokens overlap onto tokens stacked on top of them, incorrectly indicating status on a token.

Token with a status effect on it (e.g. "death"):

Adjacent token moves to stack on top of token, and now has incorrect status showing on top of it:

This used to work correctly in versions of Foundry before v9. It broke with the layer changes in v9.

What ways of accessing Foundry can you encounter this issue in?

• [X] Native App (Electron)
• [X] Chrome
• [X] Firefox
• [X] Safari
• [X] Other

Reproduction Steps

1. Create a token and assign a status to it (doesn't seem to matter which one or how it's assigned)
2. Move another token to stack on top of the first token
3. Observe the bottom token's status shown on top of the top-most token, as if assigned to it

What core version are you reporting this for?

Version 10 Stable (Build 284)

Relevant log output

No response

Bug Checklist

• [X] The issue occurs while all Modules are disabled

[aaclayton]

This is a side effect of the change to separate the TokenMesh from the Token placeable object displayed in the interface layer. There are a number of counterveiling considerations here. We will internally consider in the future whether to attach the token overlay status icon (in particular) to the token mesh instead of the token interface, but at least for V10 this is the best compromise solution we were able to reach.

[StrictlySkyler]

This is an unfortunate bug to experience as part of an upgrade, and makes me sad to learn about this response.

As a paying customer to Foundry who self-hosts the application, it effectively makes using status token overlays un-usable for their intended purposes, and causes me to consider moving to an alternative VTT platform. The last thing I want to experience as a paying customer is to hear that a new version which broke existing functionality won't have a fix.

[aaclayton]

I respect your opinion about which Foundry VTT features are most important to you, but this was not a regression made out of spite. This was a necessary side effect of us empowering far better control over verticality and elevation handling for Tokens which is a much larger net win for Foundry VTT than the temporary setback regarding overlay icons.

Overlay icon handling is something we'll explore improving in the future as we continue pushing down the route of formal support for scene levels (of which the V10 changes were an important foundational step). In the meantime, it's a pretty safe bet that there will be a module that changes this behavior in some way that you'll find more appealing.

Foundry VTT is not SAAS and it's not a subscription which entitles you to wave the paying customer flag and demand things. You purchased a perpetual software license for Foundry VTT which gives you the freedom to install and use any of our versions, whether that means updating to V10 or choosing to remain on V9 where you like the way that Token overlay icons are handled.

[StrictlySkyler]

Respectfully, delegating a fix to userspace for this issue shouldn't be the solution. While I can appreciate the desire to improve an internal API, such work shouldn't break existing functionality.

[aaclayton]

That's like saying if I offered you $100 but in exchange you had to give up $10 you would say no way, I refuse to budge.

[StrictlySkyler]

Not sure I follow how the analogy is relevant, apologies. 😞

I don't use any of the verticality or elevation features you're referencing – my use case is very near to "out of the box" with a pre-made module. Our use-case is very similar to what we'd find on the competitor's products (Roll20, Fantasy Grounds, etc.), in that it's a strictly 2D top-down view.

Perhaps, to use your analogy, it might be more accurate to say that you're offering €100 in exchange for my $10. But Euro doesn't spend in the US, so it's not really useful.

[alexdiste]

Try to install Token Z module from theripper93. This could be solv your pbolem because you can assign a Z-index to each token so better understand which is above and which is below. https://theripper93.com/wiki/index.php/Token_Z

[ghost91-]

Not sure I follow how the analogy is relevant, apologies. 😞

I don't use any of the verticality or elevation features you're referencing – my use case is very near to "out of the box" with a pre-made module. Our use-case is very similar to what we'd find on the competitor's products (Roll20, Fantasy Grounds, etc.), in that it's a strictly 2D top-down view.

Perhaps, to use your analogy, it might be more accurate to say that you're offering €100 in exchange for my $10. But Euro doesn't spend in the US, so it's not really useful.

I understand your frustration, but it’s not an easy problem to solve, and the change is definitely a net benefit for the overwhelming majority of the community, in particular when considering the possibilities this opens for modules and future core features.

If this is enough to drive you away from foundry, that’s very unfortunate, but there isn’t really anything that can be done about the situation in foundry v10. Well, not strictly true, potentially, a module could change the behavior, but unless one already does so, by chance, I think it will be difficult to find somebody to implement it.

On the plus side, you always have the option to stay on version 9 for as long as you want, which still has the old behavior. So if this behavior is more important to you than the other improvements that come with v10, that may just be the best option for you.

[StrictlySkyler]

Try to install Token Z module from theripper93. This could be solv your pbolem because you can assign a Z-index to each token so better understand which is above and which is below. https://theripper93.com/wiki/index.php/Token_Z

Unfortunately, the issue seems to be with the way in which token statuses are rendered, not with which tokens themselves are rendered. Sadly, the module you listed doesn't solve the issue.

I understand your frustration, but it’s not an easy problem to solve, and the change is definitely a net benefit for the overwhelming majority of the community, in particular when considering the possibilities this opens for modules and future core features.

If this is enough to drive you away from foundry, that’s very unfortunate, but there isn’t really anything that can be done about the situation in foundry v10. Well, not strictly true, potentially, a module could change the behavior, but unless one already does so, by chance, I think it will be difficult to find somebody to implement it.

On the plus side, you always have the option to stay on version 9 for as long as you want, which still has the old behavior. So if this behavior is more important to you than the other improvements that come with v10, that may just be the best option for you.

This issue is present in v9 as well. As a customer of the tool, I suppose my expectation would be to have a timeline for this bug to be fixed, rather than to be told "We'll consider it in a future release." Given that assigning the "Taken Out" status is a core part of the capabilities of the system, and that it integrates with the combat encounter tracker, it seems a reasonably common workflow.

[ghost91-]

Ok, replace v9 with v8 then, the general statement still holds.

it’s very much debatable whether this is a bug, or just a change in behavior. The behavior may not be desirable in all situations, but it’s the currently intended behavior. So I would argue it’s not a bug.

Expecting a timeline is not reasonable, considering that there is no timeline for the next release at this point at all.

You’ll just have to accept how things are for now. Atro has said they will consider it in a future release. That’s the best you’ll get for this.

[StrictlySkyler]

This is still very much an issue, more than a year later. Is this project even addressing its issues at all?

Here's a prime example of why this is a problem:

Here is one token (a cloud giant), clearly able in a game to stand over the fallen body of an ogre (marked as dead so as to stay up to date in the combat tracker). Yet the ogre's status is obscuring the larger token overtop of it.

What recourse is there to be had?

[aaclayton]

This is still very much an issue, more than a year later. Is this project even addressing its issues at all?

Hello @StrictlySkyler. I encourage you to check out https://foundryvtt.com/releases/ for a clear record of all the amazing work we have done in the past year including the numerous issues that we have addressed during that time. Sorry that this one was not among them.

What recourse is there to be had?

There may be modules available on https://foundryvtt.com/packages/modules which address your use case. For example perhaps https://foundryvtt.com/packages/status-icon-tweaks or https://foundryvtt.com/packages/illandril-token-hud-scale.

Otherwise you have done the right thing to comment on this post reiterating its importance to you. We are working on V12 and I expect it will contain numerous improvements. This issue is not yet scoped for V12 work, but it's possible it may be picked up if it intersects well with other priorities we have.

Despite this seeming like a trivial/simple thing to you, the reality is that it's not simple to fix due to some technical details of the canvas rendering pipeline.

[StrictlySkyler]

Thanks for replying, @aaclayton.

Sadly, neither of those modules solves this issue. I've looked for other modules as well in the intervening year since, with each Foundry update released, and it seems that this is impossible for a module to solve due to similar complexities in the rendering pipeline. So long as the status layer is hardcoded to render above the token layer in Foundry's pipeline, it seems highly unlikely any 3rd-party solution will solve this without a fork and introducing breaking changes.

Foundry's competitors support rendering statuses in the desired manner (the manner by which Foundry did in v8 and earlier). The module we're using is the classic Against the Giants, so this seems like a common use-case, especially for the D&D crowd -- arguably one of the largest cohorts using Foundry.

Given that tinting tokens works as expected (the overlaying token obscures the tint of the underlying token), it seems that the status tokens should follow suit.

It does currently appear that the status tokens and the tokens themselves are rendered using the same canvas element, so the desired behavior would be for the status indicator to match the owning token's "z-index", as it were, but increased by 1. (Of course, selecting underlying tokens remains an issue.)

[aaclayton]

It does currently appear that the status tokens and the tokens themselves are rendered using the same canvas element, so the desired behavior would be for the status indicator to match the owning token's "z-index", as it were, but increased by 1. (Of course, selecting underlying tokens remains an issue.)

At the risk of repeating myself ... it's not that simple.

If you are confident that it is that simple, you will have no problem achieving the behavior you want by developing a small module which implements that change ;)

[StrictlySkyler]

At the risk of repeating myself ... it's not that simple.

@aaclayton Respectfully, I've never claimed it was a simple fix. If I recall, this regression was introduced in v9 as the team sought to address other perceived shortcomings with the rendering pipeline at the time.

I've attempted to provide clear expectations of how the feature ought to work, independent of how it's implemented currently. It seems others have brought up this issue in the past as well and been rebuffed.

As a consumer, I'll add that your belittling tone is disrespectful. I'll take my money elsewhere if being ignored and subsequently disrespected is the response I can expect here.

I would expect the team to have some adequate documentation detailing how this feature is meant to be used in common workflows with similar content to what I've shown above, and how to avoid what looks like a predictable problem.

I hope you reconsider your stance on this.

[aaclayton]

If I recall, this regression was introduced in v9 as the team sought to address other perceived shortcomings with the rendering pipeline at the time.

Correct., this "regression" was a necessary side effect of other major improvements in our rendering which separated interface elements (like token borders, measured templates, etc...) into a separate layer from primary objects which exist within the game world. Without this change, status effect icons and other UI elements were affected by darkness or lighting in the game world, often rendering them illegible.

As a consumer, I'll add that your belittling tone is disrespectful. I'll take my money elsewhere if being ignored and subsequently disrespected is the response I can expect here.

My engagement on this thread with you shows that you are actively not being ignored. Stop gaslighting and feel free to go wherever you like.

[StrictlySkyler]

Without this change, status effect icons and other UI elements were affected by darkness or lighting in the game world, often rendering them illegible.

This behavior would actually be preferable, since if the token isn't visible due to lighting, neither should the status markers upon it.

My engagement on this thread with you shows that you are actively not being ignored. Stop gaslighting and feel free to go wherever you like.

Except that it's been over a year since I reported this issue with no update, nor timeline as to when a fix can be expected.

[dev7355608]

Hey @StrictlySkyler, here are a couple of examples of why we don't want the UI elements to be affected by lighting.

• This is a token with darkvision. On the right you can see what it would look like if its UI elements are effected by lighting. Everything becomes grayscale. Especially affected are the border color, which makes it very difficult to tell the disposition of the token, and the temporary HP bar, which depending of the current color of the HP bar could become nearly invisible.

• Here you can see what the effect of blindness would have.

• The Token Color Marker would be impossible to use if the status effects were affected by lighting, because all colors would become a shade of gray under darkvision.

Unfortunately we cannot render the UI elements interleaved with tokens, tiles, etc. and not have them affected by lighting at this time, because lighting is applied as a postprocessing effect on the entire scene with the exception of the interface layer. That's why we are forced to render them on the interface layer, which sits on top of the scene. The consequences of that are the issues you describe related to stacked tokens. Unfortunately this isn't an easy problem at all, especially considering the solution mustn't bear a significant performance overhead.

[StrictlySkyler]

That's interesting context, @dev7355608, and thanks for sharing. Unfortunately, we don't generally use the lighting features in our game, so those aren't issues for us.