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.

1 Like

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 …

1 Like


Passing an integer value of from 2 to 9 to the ItemPropertyImmunityToSpell(nLevel) call will set its GetItemPropertyCostTableValue(iprop) returned value to nLevel-1. Passing an nLevel value of ‘1’ will result in an invalid cost table value result of ‘-1’. Basically it looks like you can’t make something immune to only 1st level spells. There’s probably no way to fix this though.

I suspect level 1 was disabled since an nLevel of 1 would result in a cost of 0. But that seems dumb; why not fix it to use nLevel? Ah well.

interesting, Rj

i’ll have a look myself when time permits,

Are you sure there isn’t an item (stock) that grants immunity to 1st level spells like Magic Missile? …

There’s an item property call to add immunity to specific spells. Is that what you mean?

It might be that the toolset works differently. I was just working with the script calls.

in the toolset there’s an AvailableProperty “Immunity: Spells by Level”

in its CostValue dropdown are the following:

Level 1 or Lower
Level 2 or Lower
Level 3 or Lower
Level 4 or Lower
Level 5 or Lower
Level 6 or Lower
Level 7 or Lower
Level 8 or Lower
Level 9 or Lower

requires tinkering to figure out what’s going on tho.

as far as i’m aware any IP that can be scripted can be set on an item in the toolset, and vice versa

The ItemPropertyDamageReduction function seems to be messed up, or at least the toolset documentation is incorrect. It is unclear what goes in the nDRSubType field, for example. The documentation says something about an nDmgBonus field, but there’s non-such in the function definition. I tried putting in various values, but I just end up with an invalid itemproperty.

DamageReduction isn’t an IP anymore. It doesn’t script as an itemproperty (although as an effect it scripts fine)

the only way, apparently, to apply the DamageReduction property to an item is with the toolset.

point is, it’s not an IP anymore – it’s its own beast in Nwn2 – so the function that was used to apply it is obsolete.

Edit: changed “work” to (verb) “script”

Only way I know to put Damage Reduction on an item is to use the GFF editor. Sometimes I put Damage Reduction 5/- on Fire Mephit Padded Armor, but only after I am finished enchanting it. Tried doing it first once and could not enchant it afterwards. Don’t know why.

fleenots discovered a bug that left 2 Ward Mossfelds in the OC’s opening battle in WestHarbor (right after the tutorial ends)

I may try to get Georg and Tarmas to participate in the second part of the battle later. They seem to want to sit on their butts … so you (people who keep up to date w/ Nwn2Fixes) might want to wait a few days before downloading – to see if I see if they ought participate. Atm it seems that they should … their chatter is pretty gung-ho

EDIT: ayep i see their waypoints on the battle-line but they ain’t there


You might look at some of my fixes regarding West Harbor (it’s in beta version still, so use with caution). I refactored all battle related scripts (11_in_postattack, 11_in_atkend, 11_in_atkwarn, 11_in_endsetup, 11_tr_arrow, 11_tr_charge, 11_tr_startwaves, etc), Georg and Tarmas participate in the battle as they should do. It may help you to save a couple of days.


no offense, Aqvi, but i try to look at the OC as little as possible these days. It’s really getting on my nerves, it’s just so effing baadf00d.

Don’t get me wrong: I still pound away at my personal “fixes” (more like rewrite) for days or weeks at a time. But there i just start from the top of a script and rewrite the whole dang thing. But if something screws up [or alters from the original intent] it affects only myself.

Nwn2Fixes, by contrast, is and was always ever meant to be surgical: leave it cr*ppy, figure out what’s wrong and do a pinpoint fix. That is no refactoring (*)

I mean sure Georg and Tarmas participate in the battle as they should… I often use Lt.Danger’s AAR playthough as a reference, and they appear in his screenshots as they should – and i’m sure he didn’t use any modifications at all.

on the other hand, fleenots expressed it quite well:

Anyway, i’ll tinker away at ‘11_a_georg_lv’ for now … that’s fired from his dialog and either (a) moves Georg and his guards to the gathering point, or (b) moves Georg and all recruits to the battle-line in the wheatfield.

Yet as a resource for others (or myself for that matter) your stuff is always welcome in the thread, afaiac

* i got fed up and in the script am working on now, appears this note:

// kevL 2019 apr 14 - got sick of looking at their crapcode and refactored it

/shrug lol arg runs for the hills pulling his hair out etc ad hoc

1 Like

Sure, no hard feelings :wink: My approach tend to be more thorough and may not suit very well for NWN2Fixes’s concepts. Btw, while tinkering with WH’s scripts and reading comments in them, I discovered that they were written when the engine hadn’t supported some useful functions like AssignCutsceneActionToObject and some others. It was funny to rewrite these scripts in a more neat form. Though I know It wasn’t necesseary here, but anyway. Cheers.


Regarding Tarmas: he stucks on his way to the farm due to ForceRest calls in his heartbeat script. If you remove this line, he will move to his waypoint. But there’s another problem: if you look at his properties, you’ll discover that he doesn’t have any wizard spells in his arsenal… and he will fight in melee during the battle (so that these ForceRest calls are useless here anyway).

thank ya, will have a look at Tarmas while twiddling