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

Medical Treatment - Change stitching when wound reopening disabled #8912

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Freddo3000
Copy link
Contributor

When merged this pull request will:

  • Allow stitching when "Clear Trauma" is set to "On Stitch".
  • This changes behaviour as such that trauma is cleared upon finishing stitching, instead of periodically, with time calculation based on ΣbodyPartDamage * GVAR(woundStitchTime). This is due to some of the values otherwise used for stitching are only available when wound reopening is enabled.

IMPORTANT

  • If the contribution affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
  • Development Guidelines are read, understood and applied.
  • Title of this PR uses our standard template Component - Add|Fix|Improve|Change|Make|Remove {changes}.

@kymckay
Copy link
Member

kymckay commented Jun 2, 2022

I think in terms of end user experience this isn't the ideal solution (since if action is interrupted that progress will be lost). However, it does identify a valid case that's not being handled and seems fine as an initial solution.

Having recently reacquainted myself with our stitching code to produce #8926, the way we handle stitching logic is not very intuitive and seems over complicated. I reckon if someone was motivated they could refactor the underlying system in a way which also accommodates this case with incremental progress.

@Freddo3000
Copy link
Contributor Author

I think in terms of end user experience this isn't the ideal solution (since if action is interrupted that progress will be lost). However, it does identify a valid case that's not being handled and seems fine as an initial solution.

Having recently reacquainted myself with our stitching code to produce #8926, the way we handle stitching logic is not very intuitive and seems over complicated. I reckon if someone was motivated they could refactor the underlying system in a way which also accommodates this case with incremental progress.

This was essentially my thought on it as well, a stopgap solution until someone who is more acquainted with ACE produces something better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants