Just a shot in the dark here with a couple questions:
I am playing NWN2 with Kaedrin’s content pack and none of his stuff which runs off the heartbeat event handler will run on companions. Everything else works fine on companions if it runs onequip or onlevelup, but not onheartbeat. Any ideas why? Does NWN2 run companion HBs differently than NWN1?
Also, I should note everything requiring event hooks runs fine on the player character.
Did Kaedrin ever release his NSS files? I am going through fixing bugs that I have run into in his stuff and Tome of Battle, but not being able to actually get eyes on it limits what I can do obviously.
1 - note that the AI scriptset for PC and/or Companions gets switched (automatically) depending on whether or not the PC/Companion is currently controlled by the player. The engine locks out most of the events (all except OnHeartbeat, OnDeath, OnUserdefined). So that’s probly not it … but thought id mention it
see Nwn2_Scriptsets.2da
There might be a condition preceding the call to run Kaedrin’s HB that stops it from running on anything other than the PC … (idk just a guess – there shouldn’t be, but note that the HB-handlers are different scripts for PC/Companion/Associate/etc – see Nwn2_Scriptsets.2da)
Thank you for the NSS files! Once I could actually look at them it only took a couple minutes to find the issue: everything runs through GetFirstPC/GetNextPC. Unless the PC list is composed differently than in NWN1, the companions won’t be evaluated at all. I’ll toss in a loop for henchmen and see if it fixes the issue.
I think the PC-list is composed differently than in Nwn1 … Nwn2 has Companions (not just henchmen). So there’s typically a parameter added to the Nwn2 functions
eg
object GetFirstPC(int bOwnedCharacter=TRUE);
An “owned character” in Nwn2 is a PC in the Nwn1 sense.
ps. This might help ya get a grip on the confusing mess of player-allied chars that nwn2 has C-info | The Neverwinter Vault
try GetFirst/NextPC(FALSE) and see what that does …
[edit] actually that cycles through PlayerControlledCharacters (which might not be OwnedCharacters)
usually this sort of loop is used to cycle through PC-faction →
object oPC = ; // define a partymember
object oParty = GetFirstFactionMember(oPC, FALSE);
while (GetIsObjectValid(oParty))
{
if (GetIsOwnedByPlayer(oParty)) // eg.
{
// these are Nwn1-style PCs
// but if this is what you want just use GetFirst/NextFactionMember(oPC, TRUE)
}
if (GetAssociateType(oParty) == ASSOCIATE_TYPE_NONE) // eg.
{
// these are PCs and Companions (without Associates, henchmen, familiars, etc)
}
// leave the checks off to handle the entire Party
oParty = GetNextFactionMember(oPC, FALSE);
}
remember that Henchmen are NOT Companions … nwn2 has henchmen (which are Associates) and Companions (which are, somewhat ironically, characters for which GetIsPC() returns true, when controlled/possessed by a player)
Rad! Well that last loop fixed all the broken HB feats for companions! Thanks sir.
Ironically, the feat I am interested in (Holy Warrior) did not end up being linked to the heartbeat, but now that I have the NSSs, it won’t take me long to GREP and find it.
Since you apparently know a thing or two about a thing or two, here is another NWN2 scripting question: does GetEffectInteger work with EffectDamageReduction?
that could be a can o’ worms, not sure. DamageReduction is implemented differently in Nwn2. Its kinda not an effect and its kinda not an IP yet it is kinda an effect and it is kinda an IP …
The rules for DR changed from 3e (nwn2) to 3.5e (nwn2) rulesets.
here’s one way of putting DR (on a creature or item)
That is awesome! I will use that and find out. The Tome of Battle scripted combat system is very similar to what we have in the PRC for NWN1. Problem is, overcoming DR is not even considered by the ToB system. Right now I have it ignoring DR, but that isn’t a good solution.
In our PRC scripted combat system we loop all the IPs (almost all DR are item props on the hide in NWN1) and check for relevant spell effects, and if the weapon should be able to overcome the DR, we pump up physical EffectDamage by an amount adequate to cancel out the DR and let the rest through.
When I look in the NWN2 toolset though, DR appears to be some independent thing (as you indicate, not an IP and not an effect) that exists on the creature. Not to mention it has the extra integer for type now for 3.5 rules. And passing a damage power through EffectDamage still appears to be bugged as it was in NWN1 and it won’t overcome DR.
they shouldn’t be equipped on PCs/Companions … because if the weapon/shield is swapped in/out multiple times the ACP (iirc) goes totally wonky. But they’re fine on NPCs/mobs who don’t do much if any weapon switching
(ill try to find the thread about it)
re. DR
the 2nd value changed from what the DR protects against to what pierces the DR … (unless im totally wonk on that)
probably ;) u really have to test things in nwn2, my advice is to take next to nothing for granted
I’ve never played around with the damagepower parameter. But a trick to get physical damage (not sure if you know this) is to sum the physical type bits →
int iDamageType = DAMAGE_TYPE_BLUDGEONING | DAMAGE_TYPE_PIERCING | DAMAGE_TYPE_SLASHING;
that is, don’t use
int DAMAGE_TYPE_ALL = 0; // AFW-OEI 06/07/2007: Deprecated. May function correctly for EffectDamage(); results are undefined for EffectDamageImmunity() and EffectDamageResistance().
The 4th integer is now what type of DR it is. So material, damage type, magical, epic, etc. The 2nd integer is still what pierces it, this is the same at NWN1, but it will look at a different set of values depending on what the 4th integer is. So if 4th param says material, 2nd param could be the value for a specific material, if 4th is magical, 2nd will work just like NWN1/3.0 rules.
At least that is what the entry in nwscript for NWN2 indicates. My own testing hasn’t been able to confirm that. Or even if you can grab DRs as effects and use GetEffectInteger on them.
For combining the damage types, can you actually pass that to EffectDamage as you wrote it with all those pipes in there?
So u could just use 7 but the constants make it explicit
It fixed an issue i was having with EffectDamageIncrease() and have seen it mentioned in notes of the stock scripts, so that’s what i go with …
// since DAMAGE_TYPE_ALL does not work in EffectDamageIncrease()
// try this ->
const int DAMAGE_TYPE_PHYSICAL = DAMAGE_TYPE_BLUDGEONING
| DAMAGE_TYPE_PIERCING
| DAMAGE_TYPE_SLASHING;
I read your comments related to skill increases effects leaving icons you didn’t want shown:
Thankfully, many of the ideas I had that involved using a skin can now be coded using new functions allowing us to directly alter attributes. One aspect that did still need consideration, however, was if a new feat altered a PC’s skills in some way. The problem is that while it is possible to alter PCs skills directly, the same process leaves small icons showing the changes as spell effects, which is not wanted.
I was able to remove the icons with the following code, you just need to find the icon number for skill increase:
what if the character has a SpellResistanceIncrease effect (eg) already, for which the icon should show to the player? Wouldn’t that code (potentially) remove a legit icon ?
