uh …

SendMessageToPC(GetFirstPC(FALSE), "Огненные великаны отправились расследовать причины только что случившегося обвала!" +
" У вас есть 30 секунд максимум, чтобы убежать отсюда или спрятаться с помощью заклинаний невидимости...");


This’s what I warned you about :upside_down_face:


so … uhh, I get to fix the OC and i get to fix your stuff

(and i get to fix WRFan’s stuff…)


Nobody forced you to do that. I fixed all WRFan’s stuff and made many of my own fixes. If you have some specific comments, I would be willing to listen, otherwise these are demagogic assertions and unfair accusations.

What exactly are you going to fix in my stuff? Remove several debug messages? Is that so hard for you, or what?


y, sorry. I should have said “vet” instead of “fix” in my last post.

but, that doesn’t strike me as a debug message:


main() case 10: [fired by 3031_text_boulders.dlg]
calls BouldersFall()
calls CreateObjects()
calls FireGiantsInvestigate()
calls SendMessageToPC(GetFirstPC(FALSE), …)

note also, case 20 is called by the dialog but has been commented out of the script …

  1. I removed the call for case 20 from the dialog file itself. That’s why I included it in my pack.
  2. Sorry, in that particular case this message is more for players. I like these kinds of messages here and there, since they create better immersion (e.g.: the message you posted above informs the player that fire giants started investigation (the character standing on the top of the mountain would notice that in the real world, but the game is somewhat limited in that kind) and (s)he has to get out of here or prepare an ambush for them), and I did this pack primarly for me, that’s why I left them there. But I could remove all of them and recompile all the scripts, if they confuse you. No problem.


I was curious to see if google translate could handle that message and this is what I got back -

Fire giants went to investigate the reasons for the collapse that just happened! You have a maximum of 30 seconds to escape from here or to hide with invisibility spells …

Is that about right?



the thing about chat-strings is that Nwn2Fixes doesn’t package Dialog.Tlk

I’m sure a few English-only strings have crept in, but the overall intent of the Fixes pack is sparse and minimal (unless a point by point fix just won’t do it).


Yep, the translation you and @rjshae posted here is perfectly right :slightly_smiling_face:

Fire giants are investigating the incident! You’ve got 30 sec max to get the hell out of there or go invisible…


@kevL_s so what is the problem to add my fix for fire giants? :neutral_face:

  1. The conversation is called through the boulder’s OnUsed handler, so the conversation owner (OBJECT_SELF) is the boulder itself which gets destroyed during conversation after you throw it on giants (in the case 10). That’s why I commented out the case 20 and assigned the action to the PC instead of OBJECT_SELF. You can assign it to the module object or to the nearest IPoint (3031_ip_regulator) if you want.
  2. Assigning the kill action to the PC results in the PC gaining the XP for killing those giants and seeing the feedback about the damage dealt in the chat window.
  3. FireGiantsInvestigate() incorrectly ends the execution of the script (it uses return instead of break), so nothing happens.
  4. The use of a group formation has been successfully tested in-game.
  5. The faction change for prisoners is probably better to move to the area’s OnClientEnter handler.

The cleaned version of the script was posted here.

If it doesn’t meet any approval, I’ll stop posting any fixes here.


the problem is I don’t want to go through it in the foreseeable future.

maybe at some point I will, then i’ll just go through it and do it commit by commit,

in the meantime, as long as your archives are available, the repo (Nwn2Fixes) can be forked and they can be merged into it. I don’t have to do it, right? Anybody can do it, that’s the nature of git.

I don’t know if it meets “any approval” or not – but my personal default, as far as Nwn2Fixes is concerned, is that if I don’t know, don’t do anything.


Okay, I see your point…

I’ll release my work as a separate project when it’s done and will be including any future fixes of mine as part of it. It will be merged with NWN2Fixes at some point, of course.

Have a good time.




I just wanted to say thank you to everyone who is still trying to improve nwn2. It is great to see things getting fixed.


Just submitted a fix for Adamantine shields not properly applying damage reduction, see here for the bug description:


bork bork /jk



effect EffectShaken()
	effect eLink = EffectLinkEffects(EffectAttackDecrease(-2), EffectSavingThrowDecrease(SAVING_THROW_ALL, -2));
	effect eResult = EffectLinkEffects(EffectNWN2SpecialEffectFile("fx_confusion"), eLink);

	return eResult;

effect EffectOffGuard()
	effect eLink = EffectLinkEffects(EffectACDecrease(-2), EffectSavingThrowDecrease(SAVING_THROW_ALL, -2));
	effect eResult = EffectLinkEffects(EffectNWN2SpecialEffectFile("fx_confusion"), eLink);

	return eResult;

EffectAttackDecrease(-2) -> EffectAttackDecrease(2);
EffectACDecrease(-2) -> EffectACDecrease(2);
EffectSavingThrowDecrease(SAVING_THROW_ALL, -2) -> EffectSavingThrowDecrease(SAVING_THROW_ALL, 2).

Note that SoZ uses its own version of this include lying in the campaign folder.

Scripts that need to be recompiled:

  • Neverwinter Nights 2 Campaign_X2\ga_mated_encounter.NSS (uses SpawnEncounterCreatures)
  • Neverwinter Nights 2 Campaign_X2\gui_rest (uses SinglePartyWMRestEncounterCheck)
  • Neverwinter Nights 2 Campaign_X2\k_mod_player_rest.NSS (uses WMRestEncounterCheck)
  • Scripts_X2\ga_initiate_encounter.NSS (uses InitiateEncounter)

The dependency look like this:
WMRestEncounterCheck() <- SinglePartyWMRestEncounterCheck() [the SoZ version of ginc_ressys.nss] <- InitiateEncounter() <- SpawnEncounterCreatures() <- SpawnEncounterSubgroup() <- ApplyDialogSkillEffect() <- EffectOffGuard() and EffectShaken().


Honestly, I don’t know if these functions are supposed to work with negative numbers. The documentation from Bioware doesn’t say anything about that.

I found also this in nw_i0_spells.nss:

effect GetScaledEffect(effect eStandard, object oTarget)
	int nDiff = GetGameDifficulty();
	effect eNew = eStandard;
	object oMaster = GetMaster(oTarget);
	if(GetIsPC(oTarget) || (GetIsObjectValid(oMaster) && GetIsPC(oMaster)))
		if(GetEffectType(eStandard) == EFFECT_TYPE_FRIGHTENED && nDiff == GAME_DIFFICULTY_VERY_EASY)
			eNew = EffectAttackDecrease(-2);
			return eNew;
		if(GetEffectType(eStandard) == EFFECT_TYPE_FRIGHTENED && nDiff == GAME_DIFFICULTY_EASY)
			eNew = EffectAttackDecrease(-4);
			return eNew;
			(GetEffectType(eStandard) == EFFECT_TYPE_PARALYZE ||
			 GetEffectType(eStandard) == EFFECT_TYPE_STUNNED ||
			 GetEffectType(eStandard) == EFFECT_TYPE_CONFUSED))
			eNew = EffectDazed();
			return eNew;
		else if(GetEffectType(eStandard) == EFFECT_TYPE_CHARMED || GetEffectType(eStandard) == EFFECT_TYPE_DOMINATED)
			eNew = EffectDazed();
			return eNew;
	return eNew;

Does EffectAttackDecrease(-4) produce a valid effect here? (sorry, I’m too busy to test it in the game by myself).


Hi Aqvilinius,

The “normal” usage would be to use positive numbers, which when applied would add a penalty to the attack. However, mathematically speaking, there is nothing wrong with using negative numbers to apply a negative negative effect. i.e. - (-4), which interprets to +4 … or a bonus to the attack and not a penalty as the function may imply.

In the example you give, it’s just an easy way to scale creatures in both directions using the same function according to the difficulty setting of the game - so quite normal I guess.

I have not tested this, but assume the working to be correct.

EDIT: The only “problem” I see is that I would have thought the -2 and -4 would have been the other way around for the difficulty settings. i.e. The “very easy” to be -4 (a bigger bonus for the player) than the -2 on “easy” setting.

EDIT 2: Having looked at its usage some more, I don’t think the function is used for those effects apart from “fixing” charmed or dominated type effects, which then returns the EffectDazed instead - Maybe there is a problem with these effects for the engine to do this with NWN2? Otherwise, it is just making the EffectStunned weaker effect for the “easier” setting by using EffectDazed instead. i.e. STUNNED: PC loses 2 dexterity, have -2 AC, and they can take no action whatsoever and are prone to attacks. DAZED: Dazed creatures have no inherent penalties but unable to attack, cast spells or use items, and only able to walk away from attackers. (So the easier game setting just makes a weaker effect for the spell cast.)

Cheers, Lance.


I agree, but when it comes to the programming, that’s not always an argument. If you pass a negative number to the EffectHeal function, for example, it’ll return an invalid effect.