Bubb Posted May 8 Share Posted May 8 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). Quote Link to comment
Luke Posted May 8 Share Posted May 8 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... Quote Link to comment
Bubb Posted May 8 Author Share Posted May 8 (edited) 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... Quote Link to comment
Dan_P Posted May 9 Share Posted May 9 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]). Quote Link to comment
Bubb Posted May 9 Author Share Posted May 9 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. Quote Link to comment
Bubb Posted May 12 Author Share Posted May 12 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. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.