Jump to content

Incorrect info for the NoAction() script action (BG1, IWD1, IWD2, possibly PsT)


Recommended Posts

Hi, I thought this was worth highlighting because this is a common script action, and it appears at the top of the Actions pages, so wrong info is very likely to be seen. On the pages for BG1, IWD1, IWD2, and PsT, it says this line:

This command also sets a creatures ModalState to 0, and so can be used to stop other modal actions (e.g. Bard Song).

 

I haven't checked PsT, but for the other games, this is incorrect. NoAction() works the same as in the EEs and BG2. It blocks script actions below it, but does not disable Modal States (thankfully, or it would break my scripts for these games). All my tests are done with GOG versions of the game, so I don't know how non-expansion versions work.

This can be tested really easily by giving a character a script with just this block:

IF
    True()
THEN
    RESPONSE #100
        NoAction()
END

Give it to a bard or cleric, and have them use Bard Song or Turn Undead.
Then watch those abilities not get deactivated.

 

The only case where I've noticed NoAction() disabling Modal states, is if installing TobEx with BG2 (tested with v26 and v28, with and without TobEx Afterlife). Specifically, the Expanded Actions hack will change NoAction() to stop Modal States. Disabling the hack will prevent this. Note that TobEx files added by others mods don't necessarily do this. For instance, the TobEx files added with Ascension (the one from this site), do not change how NoAction() functions.

Link to comment
10 minutes ago, Dan_P said:

For instance, the TobEx files added with Ascension (the one from this site), do not change how NoAction() functions.

The ToBEx has 2 configuration files that can be used to set or disable all it's parts. Meaning that it's not an install time thing, but an edit to the .ini file... after having installed it.

The files being "TobExCore.ini" and "TobExTweak.ini".

Edited by Jarno Mikkola
Link to comment
12 minutes ago, Jarno Mikkola said:

The ToBEx has 2 configuration files that can be used to set or disable all it's parts. Meaning that it's not an install time thing, but an edit to the .ini file... after having installed it.

The files being "TobExCore.ini" and "TobExTweak.ini".

You're right. To be more clear, what I meant was, Expanded Actions is enabled in the TobExCore.ini file with Ascension, but doesn't change how NoAction() functions. When installing the standalone TobEx installer (at least with v26 and v28), that specific hack is what makes the change, and setting it to =0 in the ini will prevent it.

Link to comment

This was added 17 years ago, so the info is unrelated to ToBEx. :) Could be a reverse-engineering mistake.

What I think it refers to is the scripted modal actions, not the GUI triggered ones (though internally I'm pretty sure they share the code). The example given does not make much sense though, since all these actions are blocking and I don't know of any other way to set a modal state. So you'd have to use ActionOverride which then kills the previous action anyway.

IF
  ModalState(BATTLESONG)
THEN
  RESPONSE #100
    NoAction()
END

 

Link to comment
33 minutes ago, lynx said:

...

IF
  ModalState(BATTLESONG)
THEN
  RESPONSE #100
    NoAction()
END

 

But that's not at all what was discussed. As in, what was was: the NoAction() -action does NOT revert the ModalState to no state, as it keeps on chirping.

 

By this we would note; say, we use this script as the Override script, "in combat", on a cleric that passively turns undead, or a thief that is detecting traps:

IF
  CombatCounter(0)
THEN
  RESPONSE #100
    NoAction()
END

IF
  !CombatCounter(0)
THEN
  RESPONSE #100
    Attack(NearestEnemyOf())
END

The not in combat state will never stop ModalStates if they were activated by the player, but any combat will.

Link to comment
11 hours ago, lynx said:

This was added 17 years ago, so the info is unrelated to ToBEx. :) Could be a reverse-engineering mistake.

What I think it refers to is the scripted modal actions, not the GUI triggered ones (though internally I'm pretty sure they share the code). The example given does not make much sense though, since all these actions are blocking and I don't know of any other way to set a modal state. So you'd have to use ActionOverride which then kills the previous action anyway.

IF
  ModalState(BATTLESONG)
THEN
  RESPONSE #100
    NoAction()
END

 

Basically what Jarno says in the last post is true. Your example block actually fits my observations. That block will never disable Bard Song, unless you install TobEx. What that block will do is prevent lower blocks from triggering if the character has Bard Song active.

 

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