Refactored Edge Handling to Use Adjusted Edge Values #6573
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.
getEdge()
withgetAdjustedEdge()
to account for the "unlucky" trait in edge calculations.PersonViewPanel
to display adjusted edge values in the GUI.resetCurrentEdge
method to reset based on the adjusted edge value.getEdge()
andgetAdjustedEdge()
to clarify usage and behavior.Dev Notes
When I first implemented Unlucky I modified the
getEdge
method. That was a poor call, as it meant we could no longer view Edge score without incorporating Unlucky. So I went back and moved Unlucky out ofgetEdge
and createdgetAdjustedEdge
which does include Unlucky.I then went through and updated relevant calls to
getEdge
to use the newgetAdjustedEdge
method, where appropriate.Finally, I fixed a bug with
Unit
that was causing any Edge used to be disregarded when determining the Edge available to a crew. Basically, we were always assuming those characters had their full allowance of Edge, when that might not be the case. Such as when there are rapid successive deployments, or if a member of the crew is also a Technician who spent some of their Edge on repair tasks.