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]: VBL/MBL adjustable displayed line width #3924

Open
icarean opened this issue Apr 14, 2023 · 1 comment
Open

[Feature]: VBL/MBL adjustable displayed line width #3924

icarean opened this issue Apr 14, 2023 · 1 comment
Labels
feature Adding functionality that adds value

Comments

@icarean
Copy link

icarean commented Apr 14, 2023

Feature Request

Please could we have a setting to adjust the displayed VBL and MBL line widths?

The Solution you'd like

I find VBL and MBL lines difficult to see, and I'd like to be able to make them more obvious. However I understand changing the thickness of VBL and MBL lines would have potential to affect vision and movement (i.e. I'm guessing as currently implemented a thicker line would block more of the map). So my suggestion is both of the following be implemented together:

  1. VBL and MBL lines be infinitesimally thin (implemented as math/theoretical lines between two defined points, etc)
  2. A setting be added to the Edit -> Preferences -> Application tab for "VBL/MBL display width" (as per "Halo line width" under "Map Visuals"). This setting should be a number of pixels or another relevant scaled measure, and only affect how the GM sees the VBL/MBL lines displayed on their map but in no way affect how vision and motion interact with the infinitesimally thin actual lines specified in Can't yet build a distribution. #1 above. This setting would not affect filled areas (I acknowledge there's an edge case where someone draws a very thin area).

Alternatives that you've considered.

Continuing to squint at the screen and 'zoom in' by leaning closer :)

Additional Context

No response

@icarean icarean added the feature Adding functionality that adds value label Apr 14, 2023
@kwvanderlinde
Copy link
Collaborator

In a non-obvious way, this is related to #3485. Both FRs touch on the fact that each *BL type as one area (literally a java.awt.Area) which prevents us from having multiple areas (which is that FR) or ideal lines (which is this request). Both require a change of our internal representation.

IMO we treat this as an opportunity to pick a new representation that is easily consumable by our vision and pathfinding algorithms, and that will be flexible enough to support improvements (such as ideal lines, editability, overlap, improved visualization, etc). I expect there would also be some performance improvements if we ditched Area for *BL in favour of something more direct.

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

2 participants