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

Wounds mi-go take should clot faster #49243

Closed
Maleclypse opened this issue Jun 9, 2021 · 5 comments
Closed

Wounds mi-go take should clot faster #49243

Maleclypse opened this issue Jun 9, 2021 · 5 comments
Labels
Monsters Monsters both friendly and unfriendly. <Suggestion / Discussion> Talk it out before implementing

Comments

@Maleclypse
Copy link
Member

Is your feature request related to a problem? Please describe.

Mi-go are the masters of their own biological processes. I believe they should take damage from bleeding but I believe their bleeding wounds should close faster than human speed.

Describe the solution you'd like

I'd like to know how to make this happen or encourage someone more knowledgeable than myself to make this change.

Describe alternatives you've considered

Mi-go not bleeding at all, but that seems overkill.

Additional context

Add any other context (such as mock-ups, proof of concepts or screenshots) about the feature request here.

@Maleclypse Maleclypse added <Suggestion / Discussion> Talk it out before implementing Monsters Monsters both friendly and unfriendly. labels Jun 9, 2021
@Venera3
Copy link
Contributor

Venera3 commented Jun 9, 2021

Hey, great minds. I was playing with the idea of introducing bleed resist to keep chunky monsters from being kited to death recently. I could come up with two ways of doing it:

  • In is_immune_effect in monster.cpp, as a flat chance to negate an application of bleed, similar to what I did for blobs getting downed,
  • The nicer way would be to include it in make_bleed as a multiplier on the effect's applied duration - this way there could be monsters that are more susceptible to bleeding as well.

I admit haven't really looked into the feasability of either solution, so consider it up for grabs.

@Saicchi
Copy link
Contributor

Saicchi commented Jun 9, 2021

From a quick look I think it would be possible to add it to Creature::deal_damage_handle_type, the make_bleed as a multiplier seems like a better solution, as a multiplier of 0 would make the monster immune. Other functions that apply bleed would also need to be touched for the new feature, like in mattack::longswipe and mattack::bio_op_impale.

@Venera3
Copy link
Contributor

Venera3 commented Jun 10, 2021

The attacks applying the effect directly is pretty janky, and a relic from the old bleed system if I had to guess. I can take care of longswipe in the PR unhardcoding reach attacks by buffing the throat slit damage and removing the effect in preparation.

Ideally there would be a genericized resistance array that would allow for completely dynamic immunities, but I don't know how centralized the code for effects being applied to creatures is (and the hope somebody would implement the nice solution kept me from starting on the sloppier ones).

@stale
Copy link

stale bot commented Jul 11, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not 'bump' or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

@stale stale bot added the stale Closed for lack of activity, but still valid. label Jul 11, 2021
@anothersimulacrum
Copy link
Contributor

Should have been closed by #49546

@anothersimulacrum anothersimulacrum removed the stale Closed for lack of activity, but still valid. label Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Monsters Monsters both friendly and unfriendly. <Suggestion / Discussion> Talk it out before implementing
Projects
None yet
Development

No branches or pull requests

4 participants