EE: Additional op39 info

[Bubb]

Stuff I've noticed while testing:

• Parameter2 (Wake on damage?) == 1 -> Maintains splstate DOESNT_AWAKEN_ON_DAMAGE.
• Special (Icon) != 0 -> Maintains splstate PRONE.
• Special == 0 -> Moves creature to the backlist while in effect; this makes the creature invisible to most things that search the area. For example, any sort of Nearest object, object selectors (like [ENEMY]), and some projectiles, (like chain lightning's secondary strikes). This mode is applied when op12 knocks a creature out with STUNNING damage.
• And a minor nitpick: Always maintains STATE_SLEEPING and STATE_HELPLESS, (this is noted at the bottom for certain timing modes, though it does this for all timing modes and all parameter configurations).

[Luke]

9 hours ago, Bubb said:

and some projectiles, (like chain lightning's secondary strikes)

Did you perhaps mean call lightning's secondary strikes (i.e., hardcoded projectiles "Call_Lightning_Chain_1", "Call_Lightning_Chain_2", ... , "Call_Lightning_Chain_11")?

9 hours ago, Bubb said:

any sort of Nearest object, object selectors (like [ENEMY]),

9 hours ago, Bubb said:

This mode is applied when op12 knocks a creature out with STUNNING damage.

Could you please clarify this point...? I mean:

• Candlekeep Watchers ("seeenemy.bcs", "AttackReevaluate([ENEMY],30)") ignore "sleeping" creatures (due to op12, p2=STUNNING)
• "bddefai.bcs" ("AttackOneRound(NearestEnemyOf(Myself))") does not ignore "sleeping" creatures (due to op12, p2=STUNNING)
  • That is to say: what do you mean by "any sort of Nearest object"...?

Also, what if op39 is applied with `Special == 0`...? In such a case, everything functions as expected...?

Separately, do you perhaps know if there's a secret hidden mode that can bypass / ignore op101 (see `parameter2` of op24)...? If not, we still can't properly distinguish Earthquake from Sleep/Unconsciousness without introducing new splstates...

[Bubb]

On 5/8/2022 at 4:23 AM, Luke said:

Did you perhaps mean call lightning's secondary strikes

Yes I did, typo...

On 5/8/2022 at 4:23 AM, Luke said:

• Candlekeep Watchers ("seeenemy.bcs", "AttackReevaluate([ENEMY],30)") ignore "sleeping" creatures (due to op12, p2=STUNNING)
• "bddefai.bcs" ("AttackOneRound(NearestEnemyOf(Myself))") does not ignore "sleeping" creatures (due to op12, p2=STUNNING)
  • That is to say: what do you mean by "any sort of Nearest object"...?

Ok, so I was partially wrong here. Object selectors never see backlist creatures, (your first example). The following objects:

• 12 - NearestEnemyOf
• 50 - NearestEnemyOfType
• 60 - NearestMyGroupOfType
• 95 - NearestAllyOf
• 105 - FarthestEnemyOf

can see backlist creatures, but they are de-prioritized to match only if the object fails to find another "normal" creature.

So, for your examples:

* The Watchers ignore sleeping creatures because their script is using an object selector, (it can't match backlist creatures). Now, if it was using one of the above objects it would initially prefer to attack normal creatures, but would attack a backlist creature if there are no normal creatures around / keep attacking one if it had already started doing so.

* bddefai.bcs is using NearestEnemyOf() so it can see backlist creatures; like the above example with the conventional object, the prioritization rules determine how this behaves. Now, since AttackOneRound() actually ends periodically the script will reevaluate the target, potentially switching off of attacking a backlist creature to attack a normal creature.

On 5/8/2022 at 4:23 AM, Luke said:

Also, what if op39 is applied with `Special == 0`...? In such a case, everything functions as expected...?

Not sure what you mean, op12 STUNNING applies op39 with Special == 0, it should act the same regardless if the engine applied it / you applied it.

On 5/8/2022 at 4:23 AM, Luke said:

Separately, do you perhaps know if there's a secret hidden mode that can bypass / ignore op101 (see `parameter2` of op24)...? If not, we still can't properly distinguish Earthquake from Sleep/Unconsciousness without introducing new splstates...

No, there's nothing like that for op39.

Edited May 12 by Bubb
Another correction...

[Dan_P]

3 hours ago, Bubb said:

Ok, so I was partially wrong here. Object selectors never see backlist creatures, (your first example). The following objects:

• 12 - NearestEnemyOf
• 29-37 - [SecondNearestEnemyOf-TenthNearestEnemyOf]
• 105-114 - [FarthestEnemyOf-TenthFarthestEnemyOf]

can see backlist creatures, but they are de-prioritized to match only if the object fails to find another "normal" creature.

Just to add to this, the NearestEnemyOfType() identifiers works the same for knocked out creatures, so you can still target object selectors. Against downed trolls, for example, you can attack them with Attack(NearestEnemyOfType([0.0.TROLL])), but not with Attack([EVILCUTOFF.0.TROLL]).

[Bubb]

42 minutes ago, Dan_P said:

Just to add to this, the NearestEnemyOfType() identifiers works the same for knocked out creatures, so you can still target object selectors. Against downed trolls, for example, you can attack them with Attack(NearestEnemyOfType([0.0.TROLL])), but not with Attack([EVILCUTOFF.0.TROLL]).

Good point, thanks. You made me realize I missed a code path, turns out basically all of the Nearest / Farthest objects can see backlist creatures — I've edited the list.

[Bubb]

And yet another correction, I said these objects could see backlist creatures when they otherwise failed to match a normal creature:

• 29-37 - [SecondNearestEnemyOf-TenthNearestEnemyOf]
• 38-46 - [SecondNearest-TenthNearest]
• 51-59 - [SecondNearestEnemyOfType-TenthNearestEnemyOfType]
• 61-69 - [SecondNearestMyGroupOfType-TenthNearestMyGroupOfType]
• 96-104 - [SecondNearestAllyOf-TenthNearestAllyOf]
• 106-114 - [SecondFarthestEnemyOf-TenthFarthestEnemyOf]

They can't. Unlike their first "Nearest/Farthest" object, these ignore the backlist. Behavior actually changed here recently; in v2.5.16.6 the above actions would return the script runner for BALDUR.BCS on failure. Due to a technical change in v2.5.17.0, (which seems to have inadvertently affected this), these objects now fail completely instead of falling back to the global script runner.

So... yeah. I'll probably be back here tomorrow with another correction given how convoluted this system is.