ok, great :)

ah. (note that the heartbeats of the overland areas jump the other characters to the Leader’s location, but i agree that’s not quite good enough)

tbh I revamped my personal overland scripts (comprehensively, including the quite nifty overland ai) about 5 yrs ago … but im so rusty on it … fortunately its starting to come back though …

My solution seems to have been rewrite SetPartyActor() more robustly and call it whenever needed (OnClientEnter, OnLeaderChanged, eg) … but yeh ill knock my head against this over the next few days … basically following your lead in the scripts

I hadn’t noticed the heartbeat jumping party members, definitely a nice feature, but while it helps, agreed it’s not enough. It was particularly bad on a project I’m working on because some areas are completely cut off from others and can only be accessed through special means, so jumping back to areas you should no longer be able to be in was more than just a minor annoyance, and this was the fix I ended up with.

1 Like

hm Now I don’t want to change SetPartyActor() because @TonyK 's CnM AI packages 2 scripts that call it … and i don’t want to go chasing that …

Do you think it should be sufficient to ensure that “oPartyLeader” is set in the ClientEnter script nx2_ol_client_enter ?

I believe it likely should be fine. Can’t think of any reasonable scenarios where it should be an issue, but if I think of any I’ll let you know.

1 Like

@kevL_s I think there’s a bug in k_mod_player_rest, and more precisely in the DoSinglePartyRest() routine:

void DoSinglePartyRest(object oPC)
	PrettyDebug("Using Single Party Rest System (switch set)!");

	// if you press the rest button, an interface pops up alerting you to the danger level,
	// and asking how long you want to rest.
	if (!GetLocalInt(oPC, VAR_REST_NOW))
		AssignCommand(oPC, ClearAllActions()); // <= Here... This will actually cancel the rest event-wise, so the On Player Rest script will never fire. After I commented this line out, it did. The problem though is it does while the GUI is still displayed, so if a conversation is launched at this time, the mouse will not work (I suppose the GUI is set to modal).

		if (!IsPartyGathered(oPC, 20.f))
			//AssignCommand(oPC, ActionSpeakString("Hey, Let's all gather together so we can rest!"));
			FloatingTextStrRefOnCreature(STR_REF_MUST_GATHER_FOR_REST, oPC);
			//AssignCommand(oPC, ActionStartConversation(oPC, "gr_rest_convo", TRUE, FALSE));
			// conversation must set DoRestingNow to TRUE and make player rest
			DelayCommand(0.01f, DisplayRestGUI(oPC));

I have a few fixes I’ve made here and there, so I went ahead and compared them to the ones in nwn2fixes and put together the things that didn’t appear in there. There’s a text file inside describing all the changes. (There’s a couple files which already appear in nwn2fixes that required further changes, but they should include the already existing fixes too.)
Fixes.7z (575.1 KB)



what expansion/module uses the

int bSinglePartyRestSystem = GetModuleSwitchValue(MODULE_SWITCH_USE_NX1_SINGLE_PARTY_RESTSYSTEM);

… MotB ? (even though it says NX1 it could be used sometimes in SoZ, eg)

I haven’t looked through the (spaghetti of the) rest system for quite a while.

but i seem to recall that one of the ‘rest systems’ overrules the hardcoded
event … like, it does ForceRest() or similar … but I think that’s SoZ …
might be MotB … not sure atm

What strikes me, though, is if this is a serious bug then why has it worked as
expected (more or less) for so long? Or if it strikes under certain conditions
only, what are those conditions?

ps. In my notes (in that script, k_mod_player_rest) … VAR_REST_NOW means
“resting is currently in progress” – ie. rest is already underway (perhaps using that
Forcerest that i mention above) so, in that case, the rest-event actually needs to be

1 Like

Yes, according to your comments it looks like SoZ reused the MotB rest system and tweaked it for its own use (different way of finding hostiles apparently).
I just checked the latest NWN2fixes, and I can’t find k_mod_player_rest in the zip, so I don’t know how it ended in my nwn2fixes subfolder in override.

Well, forget it - sorry, I should have tested further. Apparently it’s the Red hand of doom campaign that’s problematic with resting (the GUI appears, but you haven’t chosen rest, wait or cancel that the progress bar shows!)

1 Like

np. In fact if you search Credits.txt for “k_mod_player_rest” you can sort of see the shenanigans that have been going on with the rest sys …


So one thought here: I know there’s been some troubles with the Client Extension and its handling of certain walkmeshes in the past, but while most of them are fixed, one area still throws an error when using the CE, generic forest in 2200_Port_Llast.

It would be most logical to expect the CE to be fixed to handle this, but I don’t know if the author of that is around still. Meanwhile, there’s also some level of implied responsibility for nwn2fixes, as the github page suggests using it for its other fixes.

For somebody not familiar with it, it may end up being rather confusing, and as it’s potentially game-breaking, it might well discourage people from continuing at all.
If the goal is to provide as bug-free an experience as possible, it might be worth considering including a re-baked .trx file in nwn2fixes even though technically it’s not technically an NWN2 bug, and there’s no real downside to it other than a slight increase in file size.

1 Like

Ok then, k_mod_player_rest was part of NWN2_fixes up to v.200309, but was removed from the package as of v. 200331

files deleted:

  • scripts
  • scripts\inc

I understand the reason for this is that “fixing” the SoZ OL actually created problems in the MotB OL.
And I also noticed that On Player Rest Script fires twice (first time when started and second time for the actual rest?), which explains why the rest is cancelled in gui_rest.


I confirm the event “On Player Rest” is never fired with the MotB rest system (I put a lot of SendMessageToPC() :wink: in the relevant scripts).
But why wasn’t it noticed before? I guess the reason is self-explanatory after looking at the corresponding stock scripts:


//:: Default: On Rested
//:: Copyright (c) 2002 Bioware Corp.
    Determines the course of action to be taken
    after having just rested.
//:: Created By: Don Moar
//:: Created On: April 28, 2002
void main()
    // enter desired behaviour here


// gb_comp_rest
	companion On Rest
// ChazM 12/5/05

#include "ginc_debug"

void main()
	object oPC = GetLastPCRested();
	int nType = GetLastRestEventType();	
	//PrettyMessage("gb_comp_rest: rest event fired for " + GetName(oPC) + " type " + IntToString(nType));


// gb_assoc_rest
	Associate On Rest:
    Prevent from resting 
// ChazM 2/15/07
// ChazM 2/26/07 - assign command fix
#include "ginc_debug"


void main()
	//object oPC = GetLastPCRested();
	//int nType = GetLastRestEventType();
	object oSelf = OBJECT_SELF;
	//PrettyMessage("gb_comp_rest: rest event fired for " + GetName(oSelf) + " by " + GetName(oPC) + " type " + IntToString(nType));
    int bPreventRest = GetLocalInt(oSelf, "PREVENT_REST");
    //PrettyMessage("gb_comp_rest: bPreventRest=" + IntToString(bPreventRest));
    if (bPreventRest)
        //PrettyMessage("gb_comp_rest: no rest for " + GetName(oSelf) + "! Action are being cleared...");
        // Specultation: Doing a clear actions immediately would do nothing if the event puts the 
        // resting related actions on the queue after this executes.  Assigning the command should 
        // delay it until after those actions are added.
        AssignCommand(oSelf, ClearAllActions());

So in order to have On Player Rest Script fire with the MotB rest system in place, I resorted to a user-defined event at the end of the case REST_EVENTTYPE_REST_CANCELLED: section in k_mod_player_rest

		 	//[4760] due to the ClearAllActions() call in DoSinglePartyRest(), the cancel event is always fired, even if not selected in the GUI!
			event eEvent = EventUserDefined(4760);
    		SignalEvent(GetModule(), eEvent);
1 Like

Noticed I copied the wrong files for the blueprints included in the previous set I uploaded, fixes are correct, but file names are slightly wrong, so I’m including proper ones here. There’s also some other fixes, because as it turns out, there are a lot of scrolls with incorrect classes set. Probably a good 75% of scrolls inherited from NWN1 for wizard / sorcerer spells that are not on bard spell list are in fact set to be usable on bard, so I went through all the scrolls and fixed what was incorrect. There’s also a few other minor fixes in there.
Fixes2.7z (74.2 KB)

1 Like

Ok, thanks. it will take me a while to give things some kind of a vetting …

Perfectly understandable, and no rush on my part, as I mostly make these for myself, but might as well share them.

I have another addition here too that I just made, the Shadow Reaver ambush was incorrectly crediting you for avoiding it, even if you hadn’t spoken to Mephasm or Guyven about it, since the quest state wasn’t properly advanced in several dialogues. This also adds a missing influence gain to 31_mephasm, so you can ignore the one in the previous archive.
ShadowReaverAmbush.7z (136.2 KB)


So here’s a few more fixes, for one a corrected scroll of Etherealness, as it was set to Ethereal Jaunt.

Other than that, there’s a few things that will require a judgement call, I included what I feel are adequate solutions, but… anyway:

Heal/Mass Heal - The description says it cures various status ailments, but does not actually do so, so I fixed that.
The problematic point is with removing ability score penalties, as the in-game description does not include these (the comments in the heal script however, does say to include them). It does however, remove diseases, and removal of disease should be accompanied by removal of the associated penalties, but it’s not possible to match these perfectly, at best you could make a good guess.

Looking at remove disease, it removes all ability score penalties regardless of origin, and another point here is that in PnP… heal DOES remove ability score penalties, so I went ahead and just added that to it. It’s not 100% according to description, but all things considered, I feel it’s the proper solution here.

Furthermore, Mass Heal was incorrectly affecting friendly undead, so I fixed that too.

disease.2da - Several entries were incorrect. According to contagion description, Shakes should be 1d8 DEX, but is actually 1d6 STR. Slimy Doom should be CON damage, but was set to DEX, so I fixed those two.

There’s one more entry that is wrong, Filth Fever, but what to do with that is slightly more complicated. They’ve generally stuck to the PnP versions of diseases (mistakes aside), and there Filth Fever is supposed to be DEX and CON, but here it is set to CON and INT, which would be easily explained by accidentally inputting values 1 point too high. On the other hand, it is referenced in Swamp Lung description, where it says STR and DEX. As it is, I put it down as DEX and CON.

traps.2da - The Epic and Fatal traps (entries 44-57) reference non-existent ResRefs for the trap kit to create upon trap recovery. The problem here is that, rather than give you nothing, the game gives you a short sword with no icon. Creating the trap kit is probably a bit beyond the scope of this, so the simplest option is to just change the ResRefs to the highest level trap kits of the same type that actually do exist, which I went ahead and did.
Fixes 4.7z (7.9 KB)

Also regarding traps: the ones in MotB are set to run “ga_xp_trap” upon disabling them, but the script is misnamed “go_xp_trap”. It works fine when renamed, but it’s not included in this archive.


How so?

I’m unable to look into it, at the moment.

Just off the top of my head, I’d expect a Mass Heal spell to harm summoned undead in a player’s party, if they’re in the area of effect. Especially when playing in hardcore mode.


In nwn2_inc_spells we have this for affecting non-faction members:

	if ( !GetFactionEqual( oTarget, OBJECT_SELF ) || GetRacialType(oTarget) == RACIAL_TYPE_UNDEAD ) // We've already done faction characters
			// this won't effect oTarget unless it is a friendly non-undead or enemy undead
 			if (HealHarmObject( oTarget, eVis, eVis2, nCasterLvl, nSpellId ) == TRUE)

Comment shows this is unintended, and in the code for faction members we have this:

	if (GetRacialType(oTarget) != RACIAL_TYPE_UNDEAD)
		HealHarmObject( oTarget, eVis, eVis2, nCasterLvl, nSpellId );

There we also have an exclusion for undead.

To me, this does make sense, because the caster can choose who to include in the area of effect - hence why you won’t heal living enemies within the area. Excluding friendly undead seems like a logical extension of this.

So here’s a slightly different fix for Heals, effect is the same, but organised a bit better, and also modified versions of Mass Cure spells to avoid the same issue with harming friendly undead. Also includes Warpriest Mass CLW/Heal, curiously enough it turns out Warpriest’s Mass Heal already excluded friendly undead, but nothing else did.

On a related note, there’s one other issue with Mass Heal which I haven’t touched - the description specifies it only heals party members in area of effect, but heals regardless of range. (Contrast with Mass Cure spells where descriptions say they heal regardless of range and function the same.)

Lastly, there’s a fix for Bone Dancer’s Ring; it had Damage Resistance 10/- to piercing and slashing, but this property does not work, so I changed it to Damage Reduction 10/ Bludgeoning instead, which results in the same effect.
Fixes5.7z (26.6 KB)


First of all, yet another update to mass cure light wounds, as it incorrectly capped the contribution from level to amount cured at +20, correct value is +25.

Also fixed mass inflict spells, as they did not count amount of targets hit, which should be limited to 1 target per level. Mirroring its cure version, inflict light wounds was capped at +20, whereas it should be +25 too, so that’s changed too.
Fixes 6.7z (6.5 KB)

Edit: And a few more:

d02_petioner_uthraki.dlg - Sleight of hand option didn’t actually give you the mysterious meat.

z05_p_wall_de.ncs - Script attempted to destroy all objects on copy, but did so incorrectly, resulting in it leaving a loot bag upon its destruction.

z03_rammaq_friend.dlg - If Rammaq turned upon you after failing to deliver both items he sought, his Deathless Warriors would not join him, and would even attack him. As a bunch of mindless undead under his control, that’s pretty silly. z05_rammaq_minions_attack.ncs fixes this and was added to dialogue node.
Fixes 7.7z (25.8 KB)