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]: Add directionality to walls for vision #5080

Open
kwvanderlinde opened this issue Dec 2, 2024 · 11 comments · May be fixed by #5118
Open

[Feature]: Add directionality to walls for vision #5080

kwvanderlinde opened this issue Dec 2, 2024 · 11 comments · May be fixed by #5118
Labels
feature Adding functionality that adds value

Comments

@kwvanderlinde
Copy link
Collaborator

Describe the Problem

The new walls feature always blocks vision regardless of direction. This prevents them from being used in cases that VBL is currently used for:

  • Cover VBL for seeing out of an area
  • Hill+Pit VBL for seeing into an area

Directional walls would enable these use cases while being more flexible and useful in other situations, e.g., one-way mirrors and faux-elevation effects.

The Solution you'd like

There's multiple parts to this:

  1. Walls would have a little arrow or other aspect that indicates their heading. I.e., which of the walls two endpoints is the "start" of the wall and which is the "end". This is to make sense of the "left" and "right" options described below.
  2. Show a UI when drawing walls that allows setting properties of newly drawn walls.
  3. Allow walls to be selected, and make the UI from (2) be bound to the selected wall.
  4. Add an option to the above UI to select the direction of the wall. Options for "both" (current behaviour), "left", "right", and "none" (no vision blocking).
  5. Draw an icon or arrow indicating the directionality of a wall. If "left" or "right", the arrow points in the direction that vision is allowed through, i.e., not blocked. Unsure what to draw for "both" or "none".

Alternatives that you've considered.

No response

Additional Context

No response

@kwvanderlinde kwvanderlinde added the feature Adding functionality that adds value label Dec 2, 2024
@cwisniew
Copy link
Member

cwisniew commented Dec 3, 2024

I think from a UI perspective, rather than displaying the heading of the line, which is the wall and asking users to decide block from left or right it might be better to present an arrow passing through the wall that shows the direction you can see through it (obviously no arrow if you can't see through it either direction). Something like this (excuse the crude drawing)

image

These, of course, are just the normals of the wall (although usually you don't draw normal passing through a line :) ). You could even then store these as part of the wall if you wanted to make use of them to determine if the wall blocks or not (e.g. by comparing the angle of a line from viewer to wall with normal). Even if its not needed for how you plan to determine wall blocking it is easier at first glance to see what GM should expect.

The other thing to think about is light sources, technically a wall that allows vision one way only allows light from the opposite direction. But not sure if implementing it how it would really work would lead to too much head scratching trying to figure out why I can't see something even though I have a light source

@FullBleed
Copy link

  1. I don't think a directional "heading" of the wall is needed and would add additional complexity. I think there is an inherent understanding of what the right and left side of a line is on a 2d map (with the exception of determining what a 180 line is... i.e. up is the right side and down is the left.)

  2. I think displaying vision directionality on walls should be a kind of "wireframe toggle" that overlays the basic segmentation display. That is, you would click a button to show a vision blocking wireframe. I think this is the way to go because I suspect that similar treatment could be applied on movement blocking and you'll need a separate toggle for that (maybe inverted B&W for movement blocking.)

directional walls

Using the screen shot you shared in your PR, I mocked-up what the "toggle on" wireframe might look like. I think you can see that the top segment has no vision blocking "wire" (so no vision blocking). The right wall has a centered white triangle showing that sight can travel through in the direction. The left wall indicates the opposite. And wires without triangles is the default blocking.

2-4 is pure UI and I'm not sure what the limitations within MT are but I think you've got the right functionality in mind.

@FullBleed
Copy link

Btw, after seeing your screenshot illustrating the new walls on a gray background I got to thinking how difficult it is to identify and apply VBL/MBL on some maps... and how toggling the background maps to 50% transparency on a gray background while wallscaping makes it much easier to see the lines I'm working with. I'm macroing that solution up for myself, but I'm wondering if that might not be a decent idea to incorporate... perhaps modifiable as an Accessibility option.

@cwisniew
Copy link
Member

cwisniew commented Dec 3, 2024

  1. I don't think a directional "heading" of the wall is needed and would add additional complexity. I think there is an inherent understanding of what the right and left side of a line is on a 2d map (with the exception of determining what a 180 line is... i.e. up is the right side and down is the left.)

The problem is what is obvious to you looking at an image is not obvious to the the program, if you want left and right you need a direction for the vector. So you define the direction or you have to reorganise all polygons/lines to ensure that they are either anticlockwise or clockwise -- which is not always easy -- for example in your drawing below right and left of a line are dependant on if you started or ended at the green vertex. So I think its just easier (for both the program and the user) to let the user define the direction vision can pass through

directional walls

Using the screen shot you shared in your PR, I mocked-up what the "toggle on" wireframe might look like. I think you can see that the top segment has no vision blocking "wire" (so no vision blocking). The right wall has a centered white triangle showing that sight can travel through in the direction. The left wall indicates the opposite. And wires without triangles is the default blocking.

2-4 is pure UI and I'm not sure what the limitations within MT are but I think you've got the right functionality in mind.

@FullBleed
Copy link

With the wireframe concept you can add arrow heads to the line segments at the vertexes to indicate line direction... it'll look a bit busy but it's not as big a deal if it's only visible when the wireframe is on and people are modifying vision direction.

In general, I think it's a good idea to keep the wallscaping as basic as possible (like it looks in the original #5050 pr) and only invite complexity to those who want it. The vast majority of wall topology is going to block vision both ways so displaying vision and line directionality all the time would be clutter, imo.

@cwisniew
Copy link
Member

cwisniew commented Dec 3, 2024

With the wireframe concept you can add arrow heads to the line segments at the vertexes to indicate line direction... it'll look a bit busy but it's not as big a deal if it's only visible when the wireframe is on and people are modifying vision direction.

In general, I think it's a good idea to keep the wallscaping as basic as possible (like it looks in the original #5050 pr) and only invite complexity to those who want it. The vast majority of wall topology is going to block vision both ways so displaying vision and line directionality all the time would be clutter, imo.

That's why I did say display no line if it's blocking both directions :)

But I very much prefer arrow through line depicting which way it can be seen through for one way rather than directional arrows on the head of the vector that is the wall. Arrow bisecting wall you need no other information, direction of wall arrow you also need to ask user can you see through standing on the left or right, user has to potentially rotate line in their mind, it just gets messy...

@FullBleed
Copy link

But I very much prefer arrow through line depicting which way it can be seen through for one way rather than directional arrows on the head of the vector that is the wall. Arrow bisecting wall you need no other information, direction of wall arrow you also need to ask user can you see through standing on the left or right, user has to potentially rotate line in their mind, it just gets messy...

I guess I'm not sure how your "arrow bisecting line" is applied and how much space there is between what I've said and what you're saying. I assume that at some point you have to select the segment and apply an arrow with your method? That's covered in Kwvanderlinde's 2-4 UI. And an arrow through the center or a carrot at the center like I've shown is the same thing (just an aesthetic preference.)

Neither of us seems to be a fan of displaying or messing around with line directionality. I mocked it up and actually think it looks fine, but it will still mean that users will feel somewhat obligated to pay attention to line direction and, as you note, require them to rotate the line in their minds to apply specific "left/right" designations (which will not be easy for everyone). It's a fussy technical element that I don't think we need.

Without visible line directionality and without MT being able to math-out what's "right" and "left", that seems to indicate that "left/right" distinctions need to be scuttled and something like a simple "Apply 1-Way Vision Blocking" with a toggle to "Flip Vision Blocking Direction" would work.

Clicking a segment and being able to:

  1. [Apply/Remove] Vision Blocking.
  2. [Apply/Remove] 1-Way Vision Blocking.
    2a) Flip 1-Way Direction. (Visible only if 1-Way has been applied.)

That covers Both, None, "Left", and "Right" without having line directionality visible or requiring any sort of understanding what left and right actually is.

As for the Persistance of directionality indicators, I'm a bit torn. If we don't use a toggleable wireframe for the vbl then there has to be a two-way arrow/carrot applied to segments with no vision blocking. And if/when we get directional MBL or Custom Bypass (i.e. x-ray vision or height) a second or third persistent indicator will need to be applied to the segments. Then the segments start to get cluttered and small segments will likely have problems showing all indicators.

I see myself dropping the lines quickly and then, if needed, going back and adding directionality and other options as a finishing step. I don't need to see the technical line distinctions all the time and could leave the wireframe on if I did.

@kwvanderlinde
Copy link
Collaborator Author

Btw, after seeing your screenshot illustrating the new walls on a gray background I got to thinking how difficult it is to identify and apply VBL/MBL on some maps... and how toggling the background maps to 50% transparency on a gray background while wallscaping makes it much easier to see the lines I'm working with. I'm macroing that solution up for myself, but I'm wondering if that might not be a decent idea to incorporate... perhaps modifiable as an Accessibility option.

That could be interesting. Looking forward to the FR 🙂

@kwvanderlinde
Copy link
Collaborator Author

I think from a UI perspective, rather than displaying the heading of the line, which is the wall and asking users to decide block from left or right it might be better to present an arrow passing through the wall that shows the direction you can see through it

The arrow is exactly what I meant by my point (5), though I didn't phrase it very well. I am not intending for this directional arrow to be at the head of the wall as some later comments seem to interpret it.

But the heading or orientation of the wall I do consider important to communicate somehow. Without it, the effect the adding a direction to a wall can seem arbitrary - two walls that appear identical may have reversed concepts of "left" and "right", causing confusion when the user adds the same directionality to both and gets opposite results. And note that the confusion would apply regardless of whether we show the terms "left" and "right" anywhere, this is a more fundamental orientation issue.

The only way I can see to avoid that kind of confusion is to let the GM interact with the wall itself rather than going through the described UI. E.g., grab it's midpoint and drag a direction arrow out of it.

@kwvanderlinde
Copy link
Collaborator Author

The other thing to think about is light sources, technically a wall that allows vision one way only allows light from the opposite direction. But not sure if implementing it how it would really work would lead to too much head scratching trying to figure out why I can't see something even though I have a light source

This is a good point that I did not think much about. Our current directional VBL such as Cover VBL treats lights and vision as the same sort of thing in terms of direction. I'm just so used to it I implicitly assumed walls would do the same. But now that you mention it I really want some way to accomplish this - a one-way mirror doesn't really work if vision and light are treated the same. On the other hand, a cliffside modeled as a wall should treat them the same so it would need to be configurable.

Trying to think a bit more generally here - let's say walls either have a direction ("left"/"right") or don't have one ("both") - no "none" option. Then we could configure a number of things relative to that:

  1. Light blocking
  2. Sight blocking
  3. Aura blocking
  4. Movement blocking

Each of these could be configured to one of the following:

  1. Agree with the wall's direction
  2. Reverse of the wall's direction
  3. Ignore directionality (force "both" just for this one thing)
  4. Be disabled.

@FullBleed
Copy link

The only way I can see to avoid that kind of confusion is to let the GM interact with the wall itself rather than going through the described UI. E.g., grab it's midpoint and drag a direction arrow out of it.

This sounds really intuitive. I like it.

But... do you foresee a time when people will have access to modify the individual segments with macros? I could see that being useful for triggering changes in wall behaviour (i.e. once a token steps on a pad in the center of the room they can see outside all of the walls. When they step off, the walls go solid again.) With that we're back to needing to know segment directionality for that sort of thing.

As for why arrows at the head of a line was brought up... it's because the notion of needing to know segment directionality keeps being brought up. Here is the mockup of the wireframe concept I mentioned showing wall directionality in the wireframe. It doesn't look bad... though, as mentioned above, I don't think we'd need (or want) to see the wireframe all the time. I like the idea of the wireframe looking like a kind of simplified electronics schematic because I suspect more features will be added over time.

directional walls - wireframe with directional arrows

@kwvanderlinde kwvanderlinde linked a pull request Dec 20, 2024 that will close this issue
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

Successfully merging a pull request may close this issue.

3 participants