The difference is the EffectHeal does not have a negative example in the OC as far as I am aware. I made the assumption (perhaps presumptuously) that the negative inputs in the example given do make sense under the circumstances of application. However, I have not tested it, so point taken. Personally, I do not have an example usage of using negative numbers when using the function, so can add nothing more at this stage. :frowning:

Cheers, Lance.


Even if your assumption is correct and it produces positive versions of these effects, that’s not what it’s supposed to be in the examples given (these effects must be negative obviously).

effect CreateBeam(int iBeamVisualEffect, object oSource, object oTarget, int nDurationType=DURATION_TYPE_PERMANENT, 
		float fDuration = 0.0f, int nBodyPart = BODY_NODE_CHEST, int bMissEffect = FALSE)
	effect eBeam = EffectBeam(iBeamVisualEffect, oSource, nBodyPart);
	ApplyEffectToObject(nDurationType, eBeam, oTarget, fDuration);
	return (eBeam);

Replace EffectBeam(iBeamVisualEffect, oSource, nBodyPart); with EffectBeam(iBeamVisualEffect, oSource, nBodyPart, bMissEffect);.


to be brief, i agree w/ Aqvilinus

those functions should not be passed negative values. If you have to decide on which function to use on-the-fly, calculate the adjustment then check it against >0, 0, <0 and call the proper function (or bypass if 0)

may take me a while … looks like ‘ginc_overland’ (SoZ) needs to be merged w/ ‘ginc_overland’ (stock) before it goes in the /Override folder


Hi Aqvilinus,

Sorry, you lost me here … What does the code that followed the above sentence have to do with the GetScaledEffect code? i.e. You list some CreateBeam code, but I have no idea what that has to do with the GetScaledEffect function? What examples are you actually referring to?

EDIT: If you refer to my own examples, then actually I believe what I said is true, as their spell code calls DO NOT USE that part of the function call. That’s my point. It only uses the part that changes the EffectDominated (Stunning Effect v Dazed Effect) stuff, because the other references are never called from anywhere as far as I can see. So, even if they were incorrect, it would not matter … but if the function was used because of the difficulty setting (in past old code), then the “shortcut” if it works, seems reasonable to me (even though they had the -2 and -4 around the wrong way).

Sorry to misunderstand, but maybe I am missing something here. :frowning:
Thanks, Lance.

I agree, but I was trying to explain why they may have been used in that way … as in-house shortcuts?

Cheers, Lance


My sentences regarding ginc_effect have nothing to do with my answer to you. That’s just another small bug I’ve found in the stock scripts.

And I’ve done a search and I agree with you that GetScaledEffect isn’t used for EFFECT_TYPE_FRIGHTENED anywhere. But this doesn’t matter much. It was just another example when these effect functions were used with negative numbers.


Ah … OK, my bad. Then, see what I meant by my own examples above.
Cheers, Lance.


nah personally i think it was just a mistake  :)_~


Hi KevL,

Fair enough … Although I don’t see why they would have applied anything under the difficulty settings for “EASY” and “VERY EASY” in such a way that would have otherwise penalised (if positive numbers used) the player for easier settings to the NORMAL or greater? That makes even less sense than the original “mistake”.

However, it’s just a curiosity to me more than anything else now. :slight_smile: I guess that unless the original coder can verify, then we will just have to surmise. Thankfully, as I say above, that part of the code is (as far as I can see) never used anyway.

Cheers, Lance.


The point is this: if you play on low game difficulty levels (easy or very easy), EffectFrightened() is supposed to be replaced with a simple attack penalty instead (-4 for easy and -2 for very easy one).


Ah! I see what you mean now. I did not know that. :slight_smile: Thanks for clarifying it for me!

Cheers, Lance.



Should this Nimbre fix for SoZ not be included? I think it remained a problem even with the final patch.

Great project btw!



running this testscript (console) appears to do nothing (character sheet didn’t change)

// 'test_effect_neg'
void main()
    effect e = EffectAttackDecrease(-2);
    ApplyEffectToObject(DURATION_TYPE_TEMPORARY, e, OBJECT_SELF, 10.f);

but simply changing the value to positive worked as expected. So it looks like negative values for effect-decreases are indeed mistakes.

@Hina will look into the InquisitivePig issue and see what ~pops


Yep, did a smilar test.

void main()
	effect e = EffectAttackDecrease(-2);

		SendMessageToPC(GetFirstPC(FALSE), "Effect is valid.");

		int i = 0;
		for (; i <= 5; i++)
			SendMessageToPC(GetFirstPC(FALSE), "EffectInteger" + IntToString(i) + ": " + IntToString(GetEffectInteger(e, i)));
		SendMessageToPC(GetFirstPC(FALSE), "Effect is invalid.");

It prints “Effect is valid” in the console window. EffectInteger #0 (nPenalty) is -2, EffectInteger #1 (nModifierType) is 0 (ATTACK_BONUS_MISC), EffectInteger #2 is -1 (always, doesn’t affect anything). The rest effect integers are zeros.

So the effect seems to be valid, just do nothing…


Nothing beats a good testing … :slight_smile:

Thanks for confirming.



all fixed (hopefully correctly, there’s a lot of merging and dependency-interaction going on)


SoZ: Accusation in Nimbre and the Inquisitive Pig by HS_Tri

as is


Just in case: There is also this old fix still floating around in my override, but I presume it’s been redundant for a while with the last patches?


All these global creature blueprints use a non-existing On Inventory Disturbed event handler (nw_e0_default8 instead of nw_c2_default8):

  • c_ancom_spider1.UTC
  • c_ancom_spider2.UTC
  • c_ancom_spider3.UTC
  • c_ancom_spider4.UTC
  • c_ancom_spider5.UTC
  • c_ancom_spider6.UTC
  • c_ancom_spider7.UTC
  • c_ancom_spider8.UTC
  • c_ancom_spider9.UTC
  • c_ancom_spider10.UTC
  • c_ancom_spider11.UTC
  • c_ancom_spider12.UTC
  • c_fam_beetle1.UTC
  • c_fam_beetle2.UTC
  • c_fam_beetle3.UTC
  • c_fam_beetle4.UTC
  • c_fam_beetle5.UTC
  • c_fam_beetle6.UTC
  • c_fam_beetle7.UTC
  • c_fam_beetle8.UTC
  • c_fam_beetle9.UTC
  • c_fam_beetle10.UTC
  • c_fam_beetle11.UTC
  • c_fam_beetle12.UTC
  • c_fam_beetle13.UTC
  • c_fam_beetle14.UTC
  • c_fam_beetle15.UTC
  • c_fam_spider1.UTC
  • c_fam_spider2.UTC
  • c_fam_spider3.UTC
  • c_fam_spider4.UTC
  • c_fam_spider5.UTC
  • c_fam_spider6.UTC
  • c_fam_spider7.UTC
  • c_fam_spider8.UTC
  • c_fam_spider9.UTC
  • c_fam_spider10.UTC
  • c_fam_spider11.UTC
  • c_fam_spider12.UTC
  • c_fam_spider13.UTC
  • c_fam_spider14.UTC
  • c_fam_spider15.UTC
  • c_beetlebomb.UTC
  • c_beetlefire.UTC
  • c_beetlestag.UTC
  • c_fiendish_spider.UTC
  • c_spidgiant.UTC
  • c_spidglow.UTC
  • c_spidkristal.UTC

Possible ways of fix:

  1. Create a new script named nw_e0_default8 that will simply execute nw_c2_default8 with the ExecuteScript() command.
  2. Edit all these blueprints.

AFAIK, when the player summons familiars or animal companions, their default blueprint scriptset is replaced with that one specified in nwn2_scriptsets.2da for associates, so it’s not a big deal for those particular blueprints, but there are also blueprints for some common creatures in the list.


Port Llast Undead Army Fix (SoZ)

as is

DO NOT DOWNLOAD – the blueprints are causing the toolset to throw exceptions.

am looking into it …

okay. Too many entries in their SkillLists (fixed)



I went with forwarding the event …