Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: More Explicit Token Visibility. #3347

Open
FullBleed opened this issue Jan 22, 2022 · 18 comments
Open

[Feature]: More Explicit Token Visibility. #3347

FullBleed opened this issue Jan 22, 2022 · 18 comments
Labels
feature Adding functionality that adds value

Comments

@FullBleed
Copy link

Feature Request

It's not obvious what a token's visibility is just by looking at it. Having a reliable and visually explicit method would be an improvement and make it more clear to GM's what their player's are seeing.

The Solution you'd like

Options should be up for consideration, though I suspect that it would be best if multiple options were available. In my opinion there should be a Preference for "Explicit Token Visibility" with at least a couple options:

  1. Chose a default "state" to be applied when not visible to players. One should be included with MT.
  2. Default to a custom transparency when a token is not visible to players.

Alternatives that you've considered.

The above can be done with macros, but that then forces users to make and apply special macros to indicate visibility. And, worse, most simple methods aren't entirely reliable. For example, I use a basic dot state to indicate when a token is invisible. But I also have tokens default to invisible when dropped on a map... I then have to remember to apply the in/visibility state. Or I have to make a property that fires on first token use... or put something in onTokenMove that checks... etc. Having a foolproof, reliable option that does not require macros is the goal here.

Additional Context

No response

@FullBleed FullBleed added the feature Adding functionality that adds value label Jan 22, 2022
@Azhrei
Copy link
Member

Azhrei commented Jan 22, 2022

This is an interesting idea. Our GM is constantly moving NPCs around and not realizing that the players can't see them! I think a mouseover state change would be sufficient — as you said, adding a state, or a transparency, or an aura, or something.

@dorpond
Copy link

dorpond commented Jan 22, 2022

I find that I always use the key strokes to “view as players”, so that I can see what the players see. Just last session I had about 20 monsters in the map that could burrow, and that was a little harder than normal sessions, because I was constantly switching back and forth from “viewing as player”, but that is the reason why we have that option.

I am not a fan of the option to use transparency, because in my framework, I use transparency when hiding or invisible.

I am not a fan of using a state, because in my framework, I have states all over the tokens, even the corners.

We already use halos to represent other thing as well.

I am thinking it would have to be an all new effect of some sorts to represent “not visible to players”, just not sure what.

Put more thought into it and see what you can come up with.

@dorpond
Copy link

dorpond commented Jan 22, 2022

As far as a mouse over, that would work great at the time that you are about to move the token - a reminder, but it won’t eliminate the need to see the overall situation - that is where “view as player” comes in.

Should we make “View as Player” more user accessible? I mean even after 15+ years of using MT, every so often I forget those keystrokes (but that might be due to my age lol). Maybe a UI switch for beginners sake?

@Azhrei
Copy link
Member

Azhrei commented Jan 22, 2022

As far as a mouse over, that would work great at the time that you are about to move the token - a reminder, but it won’t eliminate the need to see the overall situation - that is where “view as player” comes in.

I was thinking that a mouseover on any non-PC token would add the aura/state/whatever to every token that the PCs can or cannot see. So mousing over one bad guy would always remind the GM air which other bad guys were Visible to Players.

I don’t advocate checking for actual visibility — as in checking light/sight — as I expect it could introduce lag in complicated encounters and that lag would happen every time the GM mouses over an NPC, which is a LOT!

Should we make “View as Player” more user accessible? I mean even after 15+ years of using MT, every so often I forget those keystrokes (but that might be due to my age lol). Maybe a UI switch for beginners sake?

View As Player doesn’t really work if you’re using Individual Views from the server settings (and let’s be honest, that’s a really cool feature of MT!). Unless the GM can select which player to view as, it’s not a complete solution. However, the little layer box in the upper right of the map could be extended to include each token (that Has Sight) on the map as options on a radio button and the GM could select one to view as that token. We would also need an option for “all PCs” (which is what View as Player does now) and one to turn them all off. (Or maybe it’s only on until the next action taken by the GM? But then there’s be no way to use File > Export > Screenshot.)

@Phergus
Copy link
Contributor

Phergus commented Jan 22, 2022

@FullBleed you are talking strictly about a tokens visibility to Players and not anything sight/vision related, right?

As Dorpond has already said, hovering over a token is only good for a single token at a time and we already have that functionality in the display of the token name. By toggling token names on (Ctrl-T) you can see which ones are and aren't flagged as Visible to Players.
image

Additionally the Map Explorer also distinguishes Visible from Not Visible for both PC/NPC tokens:
image

Ideally being able to see that at a glance on the map would be better. Dorpond also covered why a regular state and transparency aren't going to work well. Perhaps a "super" state that is above the regular campaign states. A big closed eye symbol or something.

@FullBleed
Copy link
Author

FullBleed commented Jan 22, 2022

@FullBleed you are talking strictly about a tokens visibility to Players and not anything sight/vision related, right?

Correct. I'm just talking about the state of the "Visible to Players" check box since it supersedes all vision related visibility and is the primary way GM's often stage events/tokens.

Ideally being able to see that at a glance on the map would be better. Dorpond also covered why a regular state and transparency aren't going to work well.

I think it would work well for a large number of users and would, hopefully, require less coding to implement. I mentioned offering multiple methods because given all of the token effects already in MT one option is not likely to be good for all. I, of course, knew that some people won't want to add more states... and some use transparency for other things... those should just be two options. I'd use the state one, the transparency one I use for other things (but I could mix things up if we got this feature.) Some other methods would certainly be good to have... but coming up with entirely new methods will require more work... and, I wager, still won't appeal to everyone or will collide with something that's already being dumped on a token in any given framework.

Perhaps a "super" state that is above the regular campaign states. A big closed eye symbol or something.

Does state "order" determine draw order? If not, perhaps it could simply be used for that to allow a "Super State" to be created?

As a side note, you guys have done a good job of showing how and where MT indicates a token isn't visible... but I think we all know that, in practice, these cues just aren't good enough. We GM's are still messing this up all the time. ;)

@FullBleed
Copy link
Author

As far as a mouse over, that would work great at the time that you are about to move the token - a reminder, but it won’t eliminate the need to see the overall situation - that is where “view as player” comes in.

And, for me, neither of those is good enough. I need foolproof persistence on the view I'm using 99% of the time. ;)
Mouseover turns it into a memory game and I've long given up on the reliability of "view as player".

@dorpond
Copy link

dorpond commented Jan 23, 2022

Would a caution sign looking icon (yellow triangle) at the top right of the “non-visible to players” icons work?

Hmmm, I use square tokens so seeing it outside the token at the top right would look decent, but not sure how it would look on round tokens. Maybe just across the top then, this way it would look decent on round and hex tokens

Anyway, we could have an option or keystroke to always show this symbol, for those who want it.

@FullBleed
Copy link
Author

Would a caution sign looking icon (yellow triangle) at the top right of the “non-visible to players” icons work?

Hmmm, I use square tokens so seeing it outside the token at the top right would look decent

Are you suggesting displaying something (i.e. a yellow yield) outside the bounds of the token? I don't see how that would work. It would end up being on top of other tokens and objects.

If you're suggesting it be displayed within the bounds of the token, what you're describing is a state easily created within MT right now... but it would make more sense to allow users to make their own since they might want to use a different image or put it in a different corner.

@Azhrei
Copy link
Member

Azhrei commented Jan 24, 2022

How about a different color of selection? We have white/red for selected and owned, and white/green for selected and unowned. We could add a third color (maybe solid yellow, or black/yellow, since that works well with accessibility)?

perhaps it only appears on hover, but click the token and it stays on for all owned tokens? (I wouldn’t make this GM only, since players could have tokens that are not seen by others.)

@FullBleed
Copy link
Author

How about a different color of selection? We have white/red for selected and owned, and white/green for selected and unowned.

*Side note: Red and green selection colors is terrible for color-blind people. I know the information that particular color selection is supposed to project is fairly "invisible" to me. I don't know if that is just a color blind issue or if it's too subtle of a distinction.

We could add a third color (maybe solid yellow, or black/yellow, since that works well with accessibility)?

Like hovering, this only works if a token is, essentially, selected or additional action (on the part of the GM) is taken. That doesn't solve the problem. A GM needs to be able to know, without doubt, when looking at an entire map, what is and isn't visible to players all the time. Not by hovering, selecting, being forced to show all the names of tokens on screen, having to cross reference with the map explorer, having to toggle in and out of a "Player View" that can't be trusted, or having to build macros that can't be trusted, etc.

I seriously doubt that there is a single GM that's used MT (and the "Not Visible to Players" check box) that hasn't run into the problem. And it's not that MT doesn't have ways to see what's hidden, it's that they are insufficient to address the actual reason why GM's have the problem.

@dorpond
Copy link

dorpond commented Jan 24, 2022

I have been struggling with this concern since MT 1.0, so yeah, it is just as important, just not sure how to best do it. I think the closest solution I have heard so far is the candy cane box around the token.

Couple thoughts come to mind:

  1. If we decide on a candy cane box around the token, we need to make sure it doesn’t interfere with halos. As it is right now, when we select a token and the red/white candy cane appears, it often times covers the halo. We can have that if this is always on and used for helping the GM assess everything.

  2. If we decide on a candy cane box, we need to also make sure the colors we chose are not similar to common map colors, or else they will be tough to see.

  3. We have to also consider gridless and hex grids when figuring out the right solution to all of this.

@FullBleed
Copy link
Author

I think a persistent candy cane box around not-visible tokens would be using one of MT's less attractive token modifier methods (the halo)... and would not be very compatible with existing halo usage. It would be, for all intents and purposes, be a custom halo.

That said, I think it could/should be a part of a multi-option method since it appears to appeal to some people as an options: State, Transparency, and Halo.

All of those use existing systems and you'd think one of them has to work with the majority of campaigns.

I'd use the state or transparency option (in fact, I'm actually off to ping the event manager crew to see about having them make an event that causes "not visible to player" tokens to slowly pulse between 25% and 75% transparency. ;)

@Azhrei
Copy link
Member

Azhrei commented Jan 25, 2022

*Side note: Red and green selection colors is terrible for color-blind people.

Agreed. Like with everything else, it would be user-selectable in a perfect world, but we should at least have better defaults.

We could add a third color (maybe solid yellow, or black/yellow, since that works well with accessibility)?

Like hovering, this only works if a token is, essentially, selected or additional action (on the part of the GM) is taken. That doesn't solve the problem.

Well, you're entitled to your opinion. I think hovering would work fine for me, particularly if selecting a token turned it on for all tokens until I selected some other one...

No way to really know without trying it, though.

I seriously doubt that there is a single GM that's used MT (and the "Not Visible to Players" check box) that hasn't run into the problem.

Ah, the generalization. Yep, always a good argument. ;)

  1. If we decide on a candy cane box around the token, we need to make sure it doesn’t interfere with halos. As it is right now, when we select a token and the red/white candy cane appears, it often times covers the halo. We can have that if this is always on and used for helping the GM assess everything.

Hm, that shouldn't be happening. There's some math in the candy cane code to make sure they don't overlap, so if they are, it's a bug. It might have something to do with the thickness of the halo being customized via the Preferences dialog...?

I think a persistent candy cane box around not-visible tokens would be using one of MT's less attractive token modifier methods (the halo)... and would not be very compatible with existing halo usage. It would be, for all intents and purposes, be a custom halo.

No, the candy cane, aka stippling, aka outline, is not a halo. It's not related to halos at all. Custom halos are allowed now but are limited to simple colors.

Perhaps the colors used for the text when using Show Token Labels just need to be more contrasting? I don't like the grey/white/blue approach as I can never remember which color represents which state. I'm not sure what a good alternative is, though. Perhaps adding an icon next to the text to represent Hidden, sort of the same way that light sources are denoted by a little light bulb symbol when Show Light Sources is turned on?

The best thing might be a little jiggle animation added to the token. I say "best" because the human eye is fairly sensitive to movement. MT can't do this intrinsically though, so using an overlay would be necessary.

@FullBleed
Copy link
Author

FullBleed commented Jan 25, 2022

Well, you're entitled to your opinion. I think hovering would work fine for me, particularly if selecting a token turned it on for all tokens until I selected some other one...

Right. My opinion. And I've noted several times now that one solution is not going to satisfy everyone. In fact, it didn't take long for people to pop in and express that the solutions I presented would not work for them. Hence the multi-solution suggestion from the start with an invitation to add options.

I seriously doubt that there is a single GM that's used MT (and the "Not Visible to Players" check box) that hasn't run into the problem.

Ah, the generalization. Yep, always a good argument. ;)

You're the one looking for the "Argument" here. I've been using MT for a long time with a lot of different GM's... almost all of whom have moved onto other VTTs at this point. And everyone one had this problem. You came into the thread stating how your GM has the problem. I put this freq up because a new user on the forums was asking for help on a macro to address this problem... I have an unreliable macro solution to address the problem... and you want to take me to task for saying that "I seriously doubt" anyone who uses the "Not Visible to Players" checkbox hasn't had the problem?

No, the candy cane, aka stippling, aka outline, is not a halo. It's not related to halos at all. Custom halos are allowed now but are limited to simple colors.

It's a line around a token's bounding box. MT calls that a halo. So "for all intents and purposes" I'm gonna call it a halo, too. You can call it a hamburger if you want. It's still going to be a box around the token.

Further, Dorpond is right when talking about halos and the selection boxes interfering with one another. I don't think it's a bug though. If you zoom in close enough you can see that the halo is inside the selection box, but it does seem to have some issues rendering cleanly on certain zoom levels (probably due to scaling.) Regardless, you just can't put a pixel thin box around another pixel thin box and expect them to work that well together... especially at higher resolutions or smaller screens. Heck, at 1080p on a 72" tv screen a selection box with a default halo (as currently rendered) is pretty useless.

@dorpond
Copy link

dorpond commented Jan 25, 2022

For what it is worth, Fullbleed, I do think this is a great topic to discuss, as I agree that I have not been 100% satisfied with having to switch on token labels to determine visibility or looking at a long list of tokens. Those solutions aren’t noob enough, and I’ve always wanted an easy, default method of identifying “not visibles” without having to ask for it.

I show token labels, and while it works decent when there are only a few tokens on the map, it doesn’t work all that great with large numbers of tokens, especially with mine, since my token names are lengthy PC names and lengthy GM names (Winged Black Creature / Adult Black Dragon CR12), and the screen quickly becomes overwhelming with text written all over the place.

So I encourage us all to brainstorm ideas, because maybe finally, we can come up with something that just works without asking for it to work. I am always looking for ways to make MT easier for new users and lower learning curves, as well as making MT more efficient for us expert users. 😎

@FullBleed
Copy link
Author

Another example of a user using an "image indicator on the token" so that they can tell when a token is visible: https://discord.com/channels/296230822262865920/296657960720007169/964277538610352189

Appears to be using the "state" option that so many of us have resorted to (though, as noted, doing it with macros makes it less reliable than if we had something hard-coded).

@kwvanderlinde
Copy link
Collaborator

I've skimmed this discussion, hoping I've grokked it well enough 🙂

I think it's worth breaking down some uses of Visible to Players. I imagine there's quite a bit of different situations where it's useful to toggle, and no one particular behaviour would be sufficient to meaningfully communicate each case. I'm not even thinking about different folks wanting/needing different things - it can even be true that for a single GM or campaign there are different uses of the toggle that actually have their own needs.

Here's one case that doesn't seem to be front of mind in the current discussion: using Visible to Players on the Object or Background layer. The reason I would toggle it off on these layers is to get some environmental effects, but I wouldn't really care about these tokens beyond that. I.e., I wouldn't even care to see these tokens during gameplay, I only care about them when I specifically need to modify their effects. So this is a case that might be better supported by some specialized features dedicated to effects (for now it doesn't really matter what those could be).

I wonder what other use cases there are, especially on the Token layer? Some of these might also be better served by specialized features compared to Visible to Players, and we might be able to agree on some concrete behaviour for these hypothetical features (and hopefully without drowning in customization 😅). One that comes to mind is toggling Vislble to Players off to model invisibility - that case might be better served by an ambitious feature like #4379. Such a feature would have its own concerns about how to represent it, but that behaviour might be easier to pin down compared to the generic Visible to Players.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Adding functionality that adds value
Projects
None yet
Development

No branches or pull requests

5 participants