Not Used: Ray spell focus.... why not a ray improved crit?

Idea for a way to do an "imrpoved crit" feat for ray attacks:

The touchattackmelee and touchattackranged functions only return a "crit" for a 20 roll, and I have not found any function in nwnscript that will return the value of the attack roll...

So... why not do a custom touch-attack function, which would allow also a custom improved critical feat to be used?

This would only work for scripted stuff such as spells, grenade type weapons, and feat based abilities... so no ability to make custom Imp.Crit feats for the CEP weapons... but anyway...

Replace the function touchattackmelee/ranged with "Customtouchattackmelee/ranged.

The function would roll it's own d20, and then add relevant modifiers (add in str modifier for melee touch, dex for ranged touch, what ever other relevant bonuses, ect). It checks that number vs the target's relevant AC.

Same as with normal mechanics... 1 on that d20 is a miss, 20 is auto crit. It could also check, if it hits with the d20 rolling a 19... and caller ahs the imp crit feat... that crits as well.

Tada... imp.crit ray spells feat to accompany the weapon focus ray spells feat!

Great idea! Fantastic!

Unfortunately, there isn't a practical way of accomplishing this. In order to do it right, you'd need to have a way for the NWScript to get the "touch AC" of a target.

The game engine does this within the TouchAttackMelee and TouchAttackRanged functions (which also does the attack rolls), but only returns a value of 0 (miss), 1 (hit), or 2 (critical hit...aka a 20 + a critical confirmation roll).

NWScript has a function to GetAC, but that's total AC (base 10 + size modifier + dex mod + armor bonus + armor enhancements + shield + shield enhancements + natural armor bonuses + deflection bonuses + dodge bonuses + AC increasing effects + tumble bonuses + monk AC bonuses + expertise bonuses)...it doesn't have a way to separate out just the ones that affect touch AC.

It could possibly be done with a very long and complicated script (which checks through every property of every item worn by the target, checks the target's size, checks the target for class feats and levels, checks through all magical effects on the target, checks if target is using expertise, etc., then uses everything it gathered to calculate a touch AC), but isn't really worth the scripting time or cpu load of constant runs of such a script.

The ray focus feat was actually quite simple to implement right in the spell scripting:
1. check caster for ray focus feat
2. if feat is present, apply +1 attack bonus effect for a fraction of a second so it's there when TouchAttackRanged() is called on the next line of code

Pardon me for asking if this is totally ignorant... but... obviously, all those things you listed are needed in order to properly calculate Touch AC.... so how could the default touchattackranged possibly get the touch ac without doing the same things?

If the engine itself is doing that work and storing the value somewhere, then we need to discover how to call that value, methinks.

Just had a thought about this....

I think we might be looking at this from the wrong angle. Trying to reinvent the wheel, as it were.

You see.... we have the tool that we need to do most of the work already.... the GetAC function.

All that is truly needed to get a touch AC is to strip down the regular AC value of things that dont apply to touch attacks.

Use the GetAC function. Then with that value, subract:

1. Base Armor Value
2. Armor AC bonus
3. Natural Armor
4. Shield Base Value
5. Shield AC bonus

Unless I am missing something, this will result in the true Touch AC of the target.

Flatfooted +/- certain feats, flanked, held, entangled, KD'd etc. etc. There are a slew of variables that can affect AC, which is why almost all of the combat engine is hardcoded and inaccessible to scripting -- it'd be too slow if you could mess with the scripting of the calcs that are done many times per second for every combatant simultaneously in the PW.

Right. Thats why you use the function Bioware gave us, to take advantage of the work the engine is hardcoded to do. Then you just remove the stuff that would not apply.