Page MenuHomeWildfire Games

Allow resistance to StatusEffects.
Changes PlannedPublic

Authored by Freagarach on Jun 11 2020, 5:54 PM.

Details

Reviewers
None
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Summary

This allows resistance to status effects. Currently implemented:

  • Chance to block one.
  • Reduction (or multiplication) of the duration.

ToDo:

  • Properly internationalise.
Test Plan

Try to play with some values.

Event Timeline

Freagarach created this revision.Jun 11 2020, 5:54 PM
Owners added a subscriber: Restricted Owners Package.Jun 11 2020, 5:54 PM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2398/display/redirect

Design wise, we must figure out if it is preferable to put this here on in IID_Resistance, and then we ought to apply it as a universal maxim :p
I have to say I'm unsure for now. The design of attack effects is rather decentralised, so it seems to make sense that the design of resistance would be too... However the "chance" design might be re-usable for other armour type, so there is a logic in making it generic.

"How" the resistance is applied is definitely up to the receiver, so it seems GetTotalAttackEffects should be moved to Health. What resistance is applied however, seems more a concern for a resistance component of sort.

I'm wondering if you could set up a schema like so, which would also work nicely with D2229

<Resistance>
  <Armour type="Damage">
    <Hack>...</Hack>
  </Armour>
  <StatusResistance type="StatusEffects">
  	<chance>...</chance>
  </StatusResistance>
  <strongwill type="capture">5</strongwill>
</Resistance>

what do you think?

The thing is, without a StatusEffectsReceiver component it doesn't make any sense to have resistance against those. (Just like it makes little sense to have hack/pierce/crush armour when one has no health.) Therefore I'd say, put the resistances of a particular component therein.
That being said, I do not know whether this is feasible and I like the schema you proposed :)
It would mean, however, that one entry can only have one type of resistance. E.g. one cannot have a "magic" shield that protects against both health damage and status effects. But I guess without directional damage and/or hitboxes that does not make much sense (yet) ^^'.

The thing is, without a StatusEffectsReceiver component it doesn't make any sense to have resistance against those. (Just like it makes little sense to have hack/pierce/crush armour when one has no health.) Therefore I'd say, put the resistances of a particular component therein.

True. I guess I'll have to dig into the reason why armor and health were originally separate, but it seems it might be a relic of times past.

It would mean, however, that one entry can only have one type of resistance. E.g. one cannot have a "magic" shield that protects against both health damage and status effects. But I guess without directional damage and/or hitboxes that does not make much sense (yet) ^^'.

Ah, yes, that is annoying :p . Then I suppose your elaborate armour diff is better... But then I probably prefer moving the resistance in the component.
Needs more digging.

Initially there was only Health, rP1302 seems to have introduced Armour.

Freagarach planned changes to this revision.Jun 16 2020, 7:22 PM

Resistance in cmpResistance.

bb added a subscriber: bb.Jun 22 2020, 4:24 PM

Health and Armour have always been split ever since they are implementing. Browsing the forums doesn't yield any old discussion whether it should be one component or two. So I guess we should argue ourselfs:
The argument for not having a resistance component seems to be: Armour for an attackEffect makes only sense if we have the receiver component. And (very related) the Armour for an attackEffect on works on 1 receiver only. Using some checkrefs could save the vanilla from the useless lines, but mods might end up carrying useless template data around.
An argument for having a resistance component is that two AttackEffect can work on the same receiver, but with a different way of handling resistance. Ofcourse one can fix this in the receiver components too, however this would hardocde the receivercomponents of damagetypes.

IMO the latter argument outweighs the first, I would go for moving all resistances to cmpResistance.

Stan added a subscriber: Stan.Jun 22 2020, 4:29 PM
Stan added inline comments.
binaries/data/mods/public/simulation/components/StatusEffectsReceiver.js
36

Typo StatusEffectsReceiver here and below

Freagarach updated this revision to Diff 13313.Thu, Aug 27, 4:24 PM
Freagarach marked an inline comment as done.
  • Rebased.
  • Add test.
Freagarach updated this revision to Diff 13314.Thu, Aug 27, 5:40 PM

Some ugly tooltips.

Owners added a subscriber: Restricted Owners Package.Thu, Aug 27, 5:40 PM
Freagarach edited the summary of this revision. (Show Details)Fri, Aug 28, 12:27 PM
Freagarach planned changes to this revision.Fri, Sep 11, 4:15 PM

Properly internationalise tooltips. (The rest accepts review.)