-
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
Add directionality to walls #5118
Open
kwvanderlinde
wants to merge
8
commits into
RPTools:develop
Choose a base branch
from
kwvanderlinde:feature/5080-wall-directionality
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Add directionality to walls #5118
kwvanderlinde
wants to merge
8
commits into
RPTools:develop
from
kwvanderlinde:feature/5080-wall-directionality
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Each wall can have a main direction (`Left`, `Right`) or be bidirectional (`Both`). Relative to the main direction, specific uses (`Sight`, `Light`, `Aura`) can be configured to respect the main direction (`SameDirection`), work in the opposite direction (`ReverseDirection`), ignore directionality and be bidirectional (`ForceBoth`) or ignore the wall entirely (`Disabled`). Movement also supports the `ForceBoth` and `Disabled` cases, but does not support direction itself and so does not have the `SameDirection` and `ReverseDirection` cases. Internally, the representation of walls got more complicated, but a future change will work to reduce that again. `WallInternal` now sports a mutable `WallData` that is capable of being overwritten and merged with `WallData` from other walls. Individual walls can have their data be updated through the new `UpdateWallMessage` message. The `WallData` is what carries the directional information for the wall. A new control panel gives access to changing wall properties. The currently selected wall will have its state reflected in the control panel, and modifying the values there will update the wall. When drawing a new wall, the current values from the control panel will be applied. The XML for walls has been extended to store the wall's direction and modifiers as child elements.
There is no more distinction between the public `Wall` and `Vertex` types vs the private `WallInternal` and `VertexInternal` types. Everything now works with `Wall` and `Vertex` directly, and `Wall` and `Vertex` are now pretty plain data types. The cost of this is the `Wall` cannot directly reference `Vertex`, so looking up the endpoints requires going through the source `Walltopology`. On the plus side, it is now easier to manipulate and create `Vertex` and `Wall` without having to involve the `WallTopology` at all. `WallData` is now `Wall.Data` and is opaque to callers (all members are private). This allows it to be read, stored, and restored, but cannot be directly manipulated by callers. Callers instead have to use the `Wall` itself to manipulate its data.
This means we don't need the `reverse` parameter in `Wall.mergeDataFrom()`, and some case work can be reduced in that method.
This avoids having to worry about whether a `Wall.Data` that is passed around might be unexpected modified. Instead, the `Wall` itself can replace its `Wall.Data` completely when needed. Also add merging methods to each of `Direction`, `DirectionModifier`, and `MovementDirectionModifier` so that `Wall.Data.merge()` is much easier to read.
kwvanderlinde
force-pushed
the
feature/5080-wall-directionality
branch
3 times, most recently
from
December 24, 2024 08:46
90051d8
to
7f93feb
Compare
A bar is placed near the source vertex, and an arrow head is placed near the target vertex. Additionally, these new decorations along with the directional arrow are not drawn if the wall is so small relative to the vertex handles that it wouldn't be visible.
kwvanderlinde
force-pushed
the
feature/5080-wall-directionality
branch
from
December 24, 2024 08:49
7f93feb
to
d306f20
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Identify the Bug or Feature request
Resolves #5080
Description of the Change
Walls can have one of these enumerated directions:
Left
Right
Both
An arrow indicates to the user what the direction of the wall is. If there is no arrow, the direction is
Both
.Walls can also have overrides applies for different types of "vision" blocking (sights, lights, and auras):
SameDirection
(default) means that blocking for this type works in the same direction as the wall.ReverseDirection
means that blocking for this type works opposite to the wall's direction (no effect if wall direction isBoth
).ForceBoth
means that blocking for this type works as if the wall's direction isBoth
.Disabled
means that blocking for this type is disabled for this wall.Movement blocking does not support directionality yet as there are extra complexities for it that would go way beyond this change. But it support has been added for the
ForceBoth
andDisabled
options, withForceBoth
being the default for movement blocking.The way the user modifies these properties is through a new control panel:
This control panel with show the properties of the currently selected wall (if there is one). When drawing new walls, the properties set in the control panel will be applied to the new walls.
The XML for walls includes the new information as child elements of the
<wall>
elements, e.g.:There is some code maintenance as well. The biggest point here is that
Vertex
andWall
are more basic values - they don't depend on their parentWallTopology
, and can be more easily constructed and serialized. This makes the privateVertexInternal
andWallInternal
obsolete and they have been removed.Wall
andVertex
have also been moved out of theWallTopology
class just to make it less busy.Possible Drawbacks
Merging behaviour regarding direction modifiers for sights, lights, and auras could be a bit surprising with the various case work in play.
Documentation Notes
Walls can have one of these directions:
If "Both", the wall blocks in both directions. If "Left" or "Right" the wall only blocks in that particular direction. The interpretation of "Left" and "Right" depends on the heading of the wall, i.e., which one of the wall's endpoints is the start of the wall and which one is the end of the wall. To make the direction clear to the user, an arrow is drawn through the wall to indicate the direction:
To support different directional effects, sights, lights, and auras can be configured to override the wall direction. In this example, a directional wall models a one-way mirror:
The Troll is unable to see out of the room due to the wall's direction:
But the Elf is able to see into the room through the one-way mirror:
Also notice that the orange light inside the room is allowed through the wall beccause the Light option is set to "Reverse Direction".
This next example represents a cliff face, with a Troll at the bottom and an Elf at the top. As in the previous example, the Elf and see the Troll, but the Troll can't see the Elf. But this time the Troll's light is not allowed through the wall to illuminate the top of the cliff, because the Light option is set to "Same Direction".
Release Notes
This change is