How does monsterAttack:setCauseCondition() work?
It expects a table.
But, of what?
I am interested in having monsters cause more than one condition,
e.g., spiders obviously poison, but IRL that poison causes paralysis,
so I would increase the base chance, and pick a condition randomly (weighted).
But the format for telling it a new condition, made its saving throw.
setCauseCondition expects table
Re: setCauseCondition expects table
Looks like another oversight in the scripting interface :/ It does expect a table when it should've been a string
A way of making it work would be to use the `onAttackHit(self, champion)` hook to manually apply the random condition, ignoring the causeCondition property entirely
A way of making it work would be to use the `onAttackHit(self, champion)` hook to manually apply the random condition, ignoring the causeCondition property entirely
- DaggorathMaster
- Posts: 53
- Joined: Thu Sep 08, 2022 7:29 pm
Re: setCauseCondition expects table
I suppose I can settle for that if needed.
That approach does open the possibility of just reworking attack conditions entirely.
That approach does open the possibility of just reworking attack conditions entirely.
Re: setCauseCondition expects table
To emulate causeCondition, use the onDealDamage hook rather than the onAttackHit hook; causeCondition only causes conditions for attacks that deal damage, whereas onAttackHit is called even if the attack deals no damage (it's called before damage calculation, in fact).
Grimrock 1 dungeon
Grimrock 2 resources
I no longer answer scripting questions in private messages. Please ask in a forum topic or this Discord server.
Grimrock 2 resources
I no longer answer scripting questions in private messages. Please ask in a forum topic or this Discord server.
- DaggorathMaster
- Posts: 53
- Joined: Thu Sep 08, 2022 7:29 pm
Re: setCauseCondition expects table
OK. Actually now I see that that is just what Dark Acolytes do - causeCondition for poison, and a hook for paralysis.
The choice of whether to use onDealDamage or onAttackHit can be made based one whether late-game heavily-armored champions are god-mode or still too vulnerable (pending playtesting).
I have been eyeing a conditions rework anyway (because of things like monster vs. monster fighting, and making the mod a worthy challenge/mind$cr3w for people who know the game a little too well.)
So maybe ignoring most or all of the "normal" way of doing it is in order.
The choice of whether to use onDealDamage or onAttackHit can be made based one whether late-game heavily-armored champions are god-mode or still too vulnerable (pending playtesting).
I have been eyeing a conditions rework anyway (because of things like monster vs. monster fighting, and making the mod a worthy challenge/mind$cr3w for people who know the game a little too well.)
So maybe ignoring most or all of the "normal" way of doing it is in order.