Jump to content

EE: Additional op39 info


Recommended Posts

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).
Link to comment
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...

Link to comment
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 by Bubb
Another correction...
Link to comment
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]).

Link to comment
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.

Link to comment

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.

Link to comment
On 5/8/2022 at 3:43 AM, Bubb said:

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).

IESDP seems to be right about timing modes. I tested that on BGEE 2.6 with timing mode 1 and it indeed left STATE_HELPLESS even after applying cure sleep opcode. However with timing mode 9 it worked normally, STATE_HELPLESS was removed and character become again selectable.

EDIT: It seems that op39 with timing mode 9 doesn't set STATE_SLEEPING and STATE_HELPLESS at all.

Edited by marchitek
Link to comment
13 hours ago, marchitek said:

IESDP seems to be right about timing modes. I tested that on BGEE 2.6 with timing mode 1 and it indeed left STATE_HELPLESS even after applying cure sleep opcode. However with timing mode 9 it worked normally, STATE_HELPLESS was removed and character become again selectable.

EDIT: It seems that op39 with timing mode 9 doesn't set STATE_SLEEPING and STATE_HELPLESS at all.

Timing mode 1 sets STATE_SLEEPING and STATE_HELPLESS in the cre file and immediately terminates, so the states aren't maintained by the effect, but are truly permanent. You are correct that op2 removes STATE_SLEEPING from the cre, but not STATE_HELPLESS, so there's no way to remove STATE_HELPLESS once it has been applied by op39 with timing mode 1.

Every other timing mode maintains STATE_SLEEPING and STATE_HELPLESS as part of the effect, and the states can be cleared by removing the effect. I'm not sure why you say timing mode 9 doesn't set the states.

Link to comment
10 hours ago, Bubb said:

Timing mode 1 sets STATE_SLEEPING and STATE_HELPLESS in the cre file and immediately terminates, so the states aren't maintained by the effect, but are truly permanent. You are correct that op2 removes STATE_SLEEPING from the cre, but not STATE_HELPLESS, so there's no way to remove STATE_HELPLESS once it has been applied by op39 with timing mode 1.

Every other timing mode maintains STATE_SLEEPING and STATE_HELPLESS as part of the effect, and the states can be cleared by removing the effect. I'm not sure why you say timing mode 9 doesn't set the states.

I was not aware about difference between setting state in cre file and setting state as part of the effect. Let me rephrase myself:

  • Timing mode 1 (and probably 4 and 7) sets STATE_SLEEPING and STATE_HELPLESS in cre file.
  • Timing mode 9 seems to set STATE_SLEEPING and STATE_HELPLESS only as part of the effect, what makes it different from other "permanent" timing modes.

 

I think I misunderstood:

On 5/8/2022 at 3:43 AM, Bubb said:

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).

I was thinking that you refer to note in IESDP: "In case of Timing Modes 1/4/7 the bits cannot be removed in-game".

Link to comment

All good. I'm going to write down this next point mostly so I'll remember it later:

On 5/29/2023 at 11:47 PM, marchitek said:

and probably 4 and 7

That's correct. Timing modes decay as follows:

+-----------------------------------+--------------------------------------+--------------------------------------+
| 0 - Instant/Limited               | => 0x1000 - Absolute                 |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 1 - Instant/Permanent until death |                                      |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 2 - Instant/While equipped        |                                      |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 3 - Delay/Limited                 | => 6 - Limited after duration        | => 0x1000 - Absolute                 |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 4 - Delay/Permanent               | => 7 - Permanent after duration      | => 1 - Instant/Permanent until death |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 5 - Delay/While equipped          | => 8 - Equipped after duration       | => 2 - Instant/While equipped        |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 6 - Limited after duration        | => 0x1000 - Absolute                 |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 7 - Permanent after duration      | => 1 - Instant/Permanent until death |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 8 - Equipped after duration       | => 2 - Instant/While equipped        |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 9 - Instant/Permanent             |                                      |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 10 - Instant/Limited (ticks)      | => 0x1000 - Absolute                 |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+
| 0x1000 - Absolute                 |                                      |                                      |
+-----------------------------------+--------------------------------------+--------------------------------------+

So timing modes 4 and 7 eventually turn into timing mode 1 => op39 sets the states in the cre.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...