#9 conditions: add hp.can_explode_pct

[bloerwald]

The hp.can_explode condition assumes 40%, but there is at least Corpse Explosion having the same semantics but using 15% instead. Future abilities might be added with yet another percentage but scripts already can't handle Corpse Explosion, so adding support for this would be good.

I don't want to break existing scripts, so there are two approaches here:

• In addition to hp.can_explode (40%), add hp.can_explode_15 (15%) and hp.can_explode_40 (40%) (or hp.can_explode15, hp.can_explode40)
• In addition to hp.can_explode (40%), add hp.can_explode_pct(x) and thus hp.can_explode_pct(15) to have full flexibility.

I don't like the first solution since it requires a hard list of percentages (then again, there are only two). I don't like the second solution because the name is ugly. Sadly, hp.can_explode(15) isn't possible that easily and I don't want to do bigger changes just for this feature.

[axc450]

What would be the effort involved in .can_explode == .can_explode() == .can_explode(40) ?
I see you mentioned it isn't easy so I will have a think about this.

[bloerwald]

What would be the effort involved in .can_explode == .can_explode() == .can_explode(40) ?
I see you mentioned it isn't easy so I will have a think about this.

Currently, only the first part can have an argument, i.e. self.ability(y).z is possible, but self.ability.z(y) is not. This is buried very deep and implicitly in the parser, to be specific

• https://github.com/axc450/pbs/blob/78cd41e/Core/Condition.lua#L153-L165 splits into an array of [self, ability(y), z] / [self, ability, z(y)]
• https://github.com/axc450/pbs/blob/78cd41e/Core/Condition.lua#L168 then passes the latter two further

• pbs/Core/Util.lua

  Lines 19 to 23 in 78cd41e

  	local major, quote = str:match('^([^()]+)%((.+)%)$')
  	if major then
  	return major, Util.ParseID(quote) or quote
  	end
  	return str, nil

  is called only for the first part, i.e. ability(y). It splits it into ability, y and
• https://github.com/axc450/pbs/blob/78cd41e/Core/Condition.lua#L142 then assembles ability.z to be looked up in the registered conditions, as well as having y as the argument which is passed to argParse to make it an actual ability/pet.
• https://github.com/axc450/pbs/blob/78cd41e/Core/Condition.lua#L178-L181 then handles the entire argument stuff

There can be exactly one argument, and it can only be in the first/middle part of a condition. This is before we even talk about overloading the function to optionally have an argument rather than requiring it.

If one wants changes like this, I'd highly recommend redoing the parser/evaluation completely to have the math expressions and alike and have this as a side effect. Doing it just for this seems very not worth it.

[cosinussinus]

I noticed that the condition needs an opts.pet = false. It's always the active pets that are affected.

Addon:RegisterCondition('hp.can_explode', { type = 'boolean', pet = false, arg = false }, function(owner, pet) return ConditionCanExplode(owner, pet, 0.4) end)

Addon:RegisterCondition('hp.can_explode_pct', { type = 'boolean', pet = false }, function(owner, pet, arg) return ConditionCanExplode(owner, pet, arg / 100.) end)

[bloerwald]

### `hp.can_explode_pct`
If the damage from a pet self-destructing would kill the opponent.

**Return**: `bool`  
**Examples**: `self.hp.can_explode_pct(16)` (Can the explode damage of the current player pet kill the enemy pet, assuming it does 16% damage?)

[bloerwald]

After trying this again, it seems that I did a bad PR here. This adds hp(15).can_explode, not hp.can_explode(15) and from reading my comment again, it seems the latter isn't possible either. I'll change the condition to be _15, to at least have something.

[bloerwald]

I noticed that the condition needs an opts.pet = false. It's always the active pets that are affected.

It actually always is the selected pet vs the opponent active pet, i.e. enemy(#2).hp.can_explode compares enemy.2 vs self.active.

This entire condition is confusing as hell, especially with the inverse nature and the horrible name. My desire to not touch this at all is rising every minute.

[cosinussinus]

Technically it works. but this can lead to unexpected behavior. here is an example:

To me it makes sense to be restrictive in this case and only allow active pets.

What the user want is: ´[enemy(#2).active & enemy.hp.can_explode]´

[bloerwald]

Technically it works. but this can lead to unexpected behavior. here is an example: To me it makes sense to be restrictive in this case and only allow active pets.

What the user want is: ´[enemy(#2).active & enemy.hp.can_explode]´

I'm not saying it is the most useful thing, but I don't think there needs to be a restriction here. There could be a pet with both explode, force-swap-enemy and backline-damage. That pet could

use (force-swap-enemy) [ enemy(#2).hp.can_explode ]
use (explode) [ enemy(#2).active ]
use (backline-damage)

It doesn't exist and it likely never will, but hey, why not support it?

[cosinussinus]

Indeed, that's a creative way of using it :D
You are right, there is no point to be restrictive.