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)
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?
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:
It appears that it removes the last effect icon effect created and leaves others in place. I think the icon shown on the screen shows only one effect icon per type. I have not noticed it failing in the AI routine added to work around the spell resistance bug. I also experimented with other effect types in unreleased code and that seemed to work.
Yes, a few years later, I think I finally grasped this as a way of resolving that issue too, as I have a number of places where I now also use the SetEffectSpellId and EffectEffectIcon combination with good effect. Although, I have not yet replaced the “Skill Book” system with such yet, as that serves me in other ways. However, it has certainly helped me in a number of other system setups where certain conditions need more flexibility. E.g. AI on and off, lycanthropy, etc. As an example …
And removed using similar function calls as you mention here.
This was one of those moments of discovery that helped out a great deal. I’m not sure when I learned of it, but it was somewhere between that post of 2010 and a few years back now. It’s good to mention that again here though, as I had forgotten about it. I have used this method in around a dozen places now, and it seems pretty solid.
Like you say, it appears to me to be a fairly robust way of us being able to build an effect that is “boxed” into its own identity which we can then add or remove reasonably easily.
At least, I assume this is what you mean …
(*) Edit: Actually, I just realized you were highlighting the removal of the icon here, so now I see what you meant. Good to know!
P.S. Every time I need to build a new one, I have to keep reminding myself how it is done. I.e. Edit the effecticons.2da etc. But once understood, it does add a great benefit for us as builders.
@kevL_s I thought this may have been something you helped me with once? I’ll see if I can find the original post where someone helped explain it to me. I mean I don’t recall it being something I figured myself.
Yes, I think it was here you helped me … Scroll down a few posts.
I have not found this one yet, but I do recall you doing that.
I suppose the icon removal is more useful for permanent effects anyway. For if the effect is only temporary, then the icon plays its part for the effect duration.
It’s good to know we can remove the icon on newly appointed permanent effects, as that effectively offers a new means to add “combined” permanent effects if I understand you correctly. Or does this only work if removing a single icon type at a time only? (See example where both an attribute and a skill boost icon may be present.)
So … just so I’m clear here, if it is only the icon that is removed by this method, and the effect otherwise left intact, is it still now possible to remove the new effect, or would the only way to remove it be to reverse the effect using a negative application?
E.g. We have a permanent “boon” effect we call “Lucky” that gives +1 to charisma and +1 to appraise. We apply the new “permanent” benefit and use this method to remove any icons.
Now can we still remove “Lucky” as its own single named group effect, or do we have to apply a new permanent negative effect with its own icon removal?
(Not at main computer.)
PS Are your “works” comments the right way around, as it sounds contradictory to your post?
EDIT: As you say … Pretty cool! I did a quick test with Spell Resistance, and casting the same spell between a permanent effect this method, and the icon did behave as desired. I.e. It appeared when the scroll was cast and remained when applying the additional permanent award, and disappeared when its time was up, leaving the appropriate permanent 2 points I had selected. (I’m going to try with a couple of other scenarios with multiple icons.)
“don’t work” means … using Tony’s code to keep a pre-existing icon when an effect-for-which-you-don’t-want-to-apply-an-icon is applied doesn’t work, if the pre-existing icon’s effect is PERMANENT – the pre-existing icon got removed.
“works” means … a pre-existing icon remains visible as desired when an effect-for-which-you-don’t-want-to-apply-an-icon is applied, if the pre-existing icon’s effect is TEMPORARY.
This idea works for removing multiple icons. I found the code that I worked on over a decade ago for multiple summons to rework how incorporeal effects are applied. I did various tests at the time dumping out all effects before and after and the effects were retained without the icons.
This year I started to rework this code to fix incorporeal creatures in their spawn script - fixing lack of move silently skill, defection bonus instead of natural AC, and the icons not showing. I might add it as an optional thing to download as part of the AI.
So basically, we can just link the effect icons and remove them as a a set of linked icons in a similar manner.
I just did some testing of my own, and I was pleasantly surprised to find that this does still appear to work even when a temporary version is applied after a combined permanent, even without using SetEffectSpellId.
I tested setup of the initial permanent effect with …
well, you see, i applied a permanent effect, for which I wanted to keep an icon visible. Then I applied another permanent effect (of the same type), for which I did not want to keep a visible icon. But unfortunately when the second effect was applied it wiped not only its own icon but the one I wanted to keep.
If, however, the first effect was applied as temporary, then applying the second effect indeed kept the original icon as desired.
none offhand. But it’s conceivable that an effect might be applied as permanent, but only be designed to be temporary. Such as if a builder applied a certain effect (as permanent) on entering an area, but for it to be removed on exiting that area. You might want the icon to stay visible (and not risk being removed) while in that area …