[Feature]: Draw tokens based on available light/the token's visibility/the observer's senses
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 22/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- java
- Domain
- computer-graphics, desktop, game-dev
Research direction
This is a design-level rendering change, not a first patch: tokens should look different per observer based on light, concealment, and senses (greyscale darkvision, brightness for dim light, false colour, outline, blur). Start from the linked issues #4379, #4836 and #3347 and from how tokens and lighting are drawn today. Done means per-viewer appearance plus accessibility prefs so hover labels and sheets do not undo the effect. No files or tests are named in the issue.
Written by the indexing model from the issue text.
Description
Describe the Problem
Similarly there are systems like Pathfinder which have the concept of being generally aware of a creature without being able to see them clearly.
Presently a tokens appears the same regardless of how well they are illuminated or if they are supposed to be unclear.
The Solution you'd like
It would be nice if tokens were rendered with regard to how they should be perceived.
Ideally this would account for the variety of perceptual senses available in various systems;
- Dark Vision is commonly supposed to be monochrome (apply a greyscale filter),
- Dimly lit (adjust image brightness/contrast),
- Different spectrum vision - e.g. IR, UV, N-Ray (apply a false colour filter),
- Concealed/Obfuscated (draw an outline)
- Unclear senses like hearing and tremor sense (blur the image)
- etc.
Consideration would need to be given to pop-ups. If something is supposedly obscured but you can just hover the mouse over the token and read the label or see it clearly on the attribute sheet the effect is somewhat nerfed.
There are accessibility concerns since we are deliberately messing with the ability to see things. Painting a token with reduced brightness will impact some users more than others. User preferences should include options for altering the method employed.
Alternatives that you've considered.
Token opacity can be applied for some circumstances like invisibility, but it affects all viewers the same. A token with the ability to see invisible does not get an improved view.
Additional Context
#4379
#4836
#3347
- Dominant language
- Java
- Stars
- 927
- Forks
- 286
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 94
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from RPTools/maptool
-
[Bug]: An initiative list with no current entry logs an error on every changePossibly taken @dwizard0 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[Maintenance]: Migrate gradle dependency submission to modern alternativePossibly taken @VelpulaGangavardhan claimed this 18 days ago. Opencode-maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
RPTools/maptool#6156 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
-
code-maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
Similar issues
-
Cleanup: restore the interrupt flag in AiFailureAnalyzerPossibly taken @Rishankgupta08 claimed this today. Opengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
seleniumboot/selenium-boot#258 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
johanhaleby/occurrent#1505 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FasterXML/jackson-databind#6443 ·
Maintainers usually reply within 1 day
-
Docs: 2 broken linksOpen
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day