-
Notifications
You must be signed in to change notification settings - Fork 263
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
Comments
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) 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 |
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. |
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. |
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
|
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... |
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:
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. |
That could be interesting. Looking forward to the FR 🙂 |
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. |
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:
Each of these could be configured to one of the following:
|
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. |
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:
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:
Alternatives that you've considered.
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: