Nwn2fixes

Neverwinter Nights 2 General
#213

==TRUE

 
heya Axe,
iirc the folk at WestHarbor are supposed to auto-rez after Voarag and Waervaer… will have a look

----
SoZ Module: T_X2
area: t01_west_harbor
OnClientEnter: t01_client_enter_new - closes the gate, spawns the dragons etc, calls

GroupOnDeathExecuteCustomScript("T01 Dragons", "t01_a_dragonsdead");

The group “T01 Dragons” has Voarag, Waervaer, and 2 lizardmen elites. When the dragon-group is finished off ->

t01_a_dragonsdead calls

GroupResurrect("T01 Field");

Group “T01 Field” has Lazlo, Pitney, and Ginni (set in the ClientEnter script). Lazlo should try to initiate dialog. But if ‘bDragonDeal’ is true, Lazlo is set scripthidden and the gate opens automatically.

else, Lazlo’s dialog, t01_fieldlazlo, has nodes that (a) unlock the door inside WestHarbor to the player’s trading post and (b) fires t01_a_destroy_fieldgroup, which executes script t01_a_gate_open but doesn’t destroy the fieldgroup.  :|

 
long story short, i don’t want to change anything without knowing exactly where it failed. My best guess is GroupOnDeath* or GroupResurrect … while i have seen group-functs fail (pseudo-randomly), it also seems odd that GroupResurrect() assigns the command to the dead party member, to resurrect itself

/idk

#214

Yeah, Lazy Lazlo pushed up daisies for about ten real-time minutes while I was taking screenshots and looking to see if it had happened to anyone else. I wanted to use a Raise Dead scroll the monk carried, but his UMD isn’t high enough, yet.

NWN2_SS_060219_212809
NWN2_SS_060219_212809.jpg1920×1080 205 KB

Notes:
Lazy Lazlo: N, F6, 84hp, AC20, AB+9

#215

Did anyone ever fix the problem with the Siege Towers some time screwing up?
(" . . . Towers land on the wall, but don’t discharge any enemies (they are supposed to “produce” a lot of undead). You can’t destroy them - you can damage them only till the “Near Death” condition. That’s it.")

I recently was playing the OC and this happened to me. Apparently there was a fix on the old bioware forums but that was shut down so it’s inaccessible (IE "Well, I had the same problem and I think I found the solution:
http://social.bioware.com/%2522%2522%2522http:/social.bioware.com/forum/1/topic/158/index/7770511/1 ").

1 Like
#216

I don’t think the siege towers have been modified (yet). Personally i haven’t seen the immortal undead… but i have seen a tower or two stop before it gets to the wall – both of which strike me as game-breaking

edit: oh, the towers are immortal i get it …

1 Like
#217

lol / this could have helped unless Lazlo’s corpse is untargetable.

https://neverwintervault.org/project/nwn2/other/gui/dm-helper

in \override (it’s a standalone IG tool and shouldn’t affect anything or cause any conflicts unless it’s invoked and used haphazardly)

edit: It could probly make short work of immortal undead also.

#218

It seems you have a modified version of the appearance.2da in your override that causes this behaviour. I wrote about that here: Pain's Monster Pack

I’ve told @kamal about that problem, but he didn’t pay attention to it.

3 Likes
#219

Must have missed it. I will look.

#220

This should be included in the NWN2Fixes package, I guess.
https://neverwintervault.org/project/nwn2/other/werewolfwererat-weapon-orientation-fix
Orientation fix for the attachment points on the Obsidian Werewolf skeleton.

1 Like
#221
1 Like
#222


line 1178+

1 Like
#223

Note that this change does NOT fix scripts that have already been compiled.

I did a search over all the scripts in the stock game (inlcuding all modules and campaigns, I have them all unpacked) and there’s only one script that uses that function: ga_take_item. It’s worth recompiling it.

#224


(un)insightful comment from an original scripter

//TakeNumItems(oCrate,"BoxofUnstableBlastglobes",1);//this is not working as it should (long tag?)
#225

Hah.

12_a_bty_pay isn’t used by the game, btw. It’s something cut from the OC, why I didn’t mention it.

#226

oh / lol - that explains why its so effed

#227

I just wanted to thank everyone involved in this project. I’ve always wanted to play through NWN2 without nasty bugs, and you guys are making that come true. All the best.

2 Likes
#228
2 Likes
#229

2020 jan 3 update

If anyone finds that changing the damage immunity effect (which is definitely bugged) of these spells to damage resistance is problematic, please discuss.

#230

Hi KevL,

In the link it says, “… this is done to prevent the damage immunity overflow bug that turns them into vulnerabilities once they go past 100%”. Can you elaborate on this for me, as it may have bearing on some of my own coding for module 2?

I mean could you give an example of how this happens. For instance, if a creature has 100% damage immunity, how can it go past/higher than 100% to cause a problem? Or are we talking about 100% of something else?

In some of my testing for module 2 (where I need to apply this at various percentages at different times), the effect appears to work fine. (I remove it and add a new level as required.) So, again, I am not fully understanding where and how this is a problem.

EDIT REMOVED AS I HAD SET IT AT 95% (This was to allow additonal types of damage to work that required a minimum of 1 HP “normal” damage to acknowledge any damage is done at all.)

Cheers, Lance.

#231

hey Lance,

i haven’t looked into it for a long time, so maybe @Clangeddin could give better examples

the bug should/will manifest once you start stacking damage immunities and/or vulnerabilities from multiple items or various sources. (ips and effects?)

a simple example would be trying to stack something with 90% and 20% (of the same immunity type?) – you could end up with only 10% immunity, or a vulnerability instead … I put some effort into trying to figure out exactly what the borked algorithm is (because ya kinda have to know that in order to fix it) but that’s a year ago and i put it on hold

So … changing the Di/Dv to DResist could be a suitable workaround…

(ofc i’m prepared to admit it actually works fine if it turns out it does)

#232

Hi KevL,

Thanks for the quick response. (I have to shut down my computer in a minute so this may be last post for a while.)

Oh, I see, a kind of stacking issue … So, if that is the case, I would have thought it better to have some kind of “stack level” check in place that simply keeps track of how much the stack is at, or if it does go above 100%, then simply limit to 100% - even if the check involves removing and adding back a new effect.

But maybe that would be too involved … I don’t know for sure.

So, when I get the time, I could check if this bug should manifests if I tried to apply 70% plus 70% immunity, which would result in only a 40% immunity instead?

As I say above, any response to your post will be a bit later today.

Catch you later, Lance.