One of the things that got confusing is labeling the PCs and NPCs and then having them get within melee range. The labels started to overlap the other tokens and what not. We came up with a method to deal with it, but it’s a work around. Essentially for every PC/NPC on the map we create two tokens of the same colour. One is in the action and the other is in the far corner of the map as a legend. Each character gets it’s own colour. Would be nice if you could have the labels only show up when you hover over the token or even a feature that could turn the label off and on at will. Other than that, and then wishing we had larger rectangular tokens for cars Shmeppy worked really well!
(I split this off from the original post because this paragraph very cleanly fits in this feature category, while the other paragraph very cleanly fits in the gallery category)
It’s good to hear feedback on the label overlapping, I haven’t heard much about it since the anti-overlap code landed.
I try to avoid “options” as much as possible, because each configuration setting is another choice GMs have to make. And the choices can quickly add up and become overwhelming. So having label overlap be managed by passing off some of the control to the user will be my last resort.
I wonder how it would feel if my anti-overlap code didn’t allow any overlap at all, and instead, when it can’t find a home for a label it’d annotate the icon somehow for users. Then these labels would only appear when hovering over the token.
I wrote the code and tried out having all labels hidden by default until hovered over and it was just too inconvenient. You end up having to hunt for what you want by moving your mouse over a bunch of tokens, and a lot of use cases are made much harder (like Using tokens for tracking initiative order). But this might be a nice compromise…
Yeah… we had about 8 characters mixing it up in melee and though the system did it’s best to make sure overlap didn’t happen… it did. It wasn’t horrible or anything. And as you can see above we came up with this option. I like to update the labels with condition codes. S=Shaken / W=Wounded, etc. It would be nice if we could place a label right inside a token for things like conditions or hit points. What’s there is perfectly workable now mind you.
I do like the idea of hiding labels that overlap and then the hover option. That would be a very workable solution vs. all off / all on. I get your point with the ‘hunting’ for the label.
But the general problem of tags floating over the top of other tokens/terrain features can get annoying form time to time. I’m not sure what the silver bullet for this problem is but perhaps an option to have the first letter and number of the token name become a texture on the token, like this
I qualify this suggestion with having no knowledge of it’s implementation. If the triangles that connect the label to the token were longer could the collision detection be allowed more room for label placement. Possibly avoiding label overlap.
I may try allowing the arrows to be slightly longer (it’s one of the avenues I want to investigate). But the general form of this problem, where you allow the labels to go anywhere, is in a special class of problems that mathematicians and computer scientists call “fucking challenging” … (The actual term is NP-hard, here’s some intro reading about the problem if you’re curious)
Edit: Actually I think even the way I have it set up right now, it’s already NP… Because each label has 4 possible positions it can go in, so the number of possibilities is 4^N where N is the number of labeled tokens in the map. My algorithm only checks around 4 * N of those solutions though, which is why Shmeppy doesn’t slow down super fast as the number of labeled tokens increases, but is also why Shmeppy very often doesn’t find the best possible arrangement of labels.
If the triangles that connect the label to the token were longer could the collision detection be allowed more room for label placement. Possibly avoiding label overlap.
… (The actual term is NP-hard, 