Great!
It would be absolutely amazing if you could implement a "Mighty/Strength Archery" feat!
I always liked the "Zen Archery" feat on my Strength Cleric - but a full strength archer would be even more awesome!!!
All I can do is to provide a way for builders to make this feat. I cannot add any new feat in CPP at all as its not in the scope of this project. But I can provide a way to do that so someone else might make a mod that will add such feat.
Its been a while, get disrupted by the LoL 
.
So far I have only several fixes to illithid interior fixing visibility issues, polygon gaps and door issues, all that was reported here and some more.
REQUEST: the cell tile group has still some polygon gaps. I wasnt able to fix all of them because the tile is badly designed and the meshes are not connected but overlayed. Much like in beholder tileset which has the same issue. I need help with this one.
Was thinking about some more features I might add:
1) dynamic crafting levels, ie. the max level of the spells you can brew/wand-alize could be overriden by a variable on module and even on player (that would allowed to make a custom feat say "Alchemist +1" that would allowed to brew potions of level 4 etc. etc. many possibilities there
2) add event handling into my nwn©x_patch plugin. While this is handled by the nwnx_events or nwnx_cool it would be better choice for those who dont want to solve conflicts in these plugins and nwnx_patch (they are not working properly together), also it would allow to use this in singleplayer modules (no client version for nwnx_events yet)
3) another improvement into spell engine, rewrite RoundsToSeconds / TurnsToSeconds and HoursToSeconds by a new function which would look like this:
"ApplyEffectToObject(oTarget,eEffect,CalculateSpellDuration(nDuration,spell.Time));"
not sure about the function and ".Time" names but the point and advantage of this is that it would allowed to dynamically modify the duration of the spells. For example it would allow to make a metamagic like feat that would changed 1round/level into 1turn/level or to add +1round into duration of all spells. All dynamically from the spellhook without need to modify any spell script.
4) same with range ie.:
object oTarget = GetFirstObjectInShape(SHAPE_SPHERE, spell.Range, spell.Loc, TRUE, OBJECT_TYPE_CREATURE | OBJECT_TYPE_DOOR | OBJECT_TYPE_PLACEABLE);
that would allowed to dynamically change the radius range for spells, for example a meta-magic like feat that would turn RADIUS_SIZE_HUGE into RADIUS_SIZE_COLOSSAL etc.
Okay, I think I abadon the idea. For interest the spellscripts would then look like this: http://pastebin.com/VURiGY0J (modified color spray spell script)
ir. defining spell.Range and spell.Shape at top (and must be above spellsDeclareMajorVariables();
and using DuarionToSeconds(int nDuration, object oTarget, int nDurationType) instead of RoundsToSeconds
As much positives it has, CPP also aim for readability and easy to (re)use which this kind of feature makes much harder, also while this method should work on all default spellscripts, there is a flaw in the concept and thats if the spell does two different area of effects like a spell that harm everyone in a line but if it hits five targets then it bursts into shere area of effect. In such case this concept would fail to modify one or another aoe. I dont recally anything like this in vanilla spells nor even PRC but its not globally applicable, so I guess that those who would want this should rather replace all GetFirst/NextObjectInShape by custom calls instead - just like PRC does that.
btw in my list of unsolved issues there is still this:
- nonverbal spells shouldn't have existed at all, all these spells: clarity, ethereal visage, lesser dispel, and ray of enfeeblement should either have verbal component by rules, or they are non-existant in any srd manual - logically, if the caster speaking some words when casting (and this is true for all these spells except lesser dispell) there should be verbal component
Problem is that while these spells provide a chants, they do have correct metamagic set, ie. not possible to use silent metamagic which implies it is intented. Also in NWN2 this has not been fixed (except Lesser Dispel). On the contrary except of the Ray of Enfeeblement, these spells doesn't exists in DnD and are "invented" by Bioware. So its possible they just badly designed it because they didn't have time to study the reasons behind, assumption but we dont get any official clarification anymore.
So far, I decided to add verbal component and chants into Lesser Dispel Magic which appeared this way in NWN2. I am not so certain about the rest, specifically when both clarity and ethereal visage are on bard's list who can therefore cast them silenced now (common tactic of silence yourself), so changing this might be treated negatively by those who uses these spells in this way - on the other way, if I change this both spells will be possible to cast with silent metamagic...
Not sure if its worth it.
Something i saw brought up on a pw forum recently was death-attack duration of assassin. Npcs. A party managed to kill the assassin quickly but lacking the appropriate spells and potions had to wait ten minutes for the paralysis of one of their team mates to run out. And it repeated a lot during a dungeon crawl.
Is there an option to add a toggle to shorten the duration for npcs, or better yet make it so the effect wears off quickly only after an encounter is finished?
This is already there in 1.72beta but it requires NWN©X_Patch. With nwnx_patch, death attack now triggers 70_s2_dthattk spellscript which defines the duration of the paralyse to 1round/assassin level instead 1minute/assassin level (and where builder can modify this). And IIRC this is further modified by the Effect Duration Scaling nwn feature - which shortens duration based on game difficulty (and in CPP this can be used to toggle 3-rounds duration).
but it needs the nwnx_patch from 1.72beta to work.
Maybe alternatively, PWs could solve that differently using (pseudo)heartbeat on a PC which would loop all effects and remove those whose creator is not valid (but this solution has one side effect, sometimes desired sometimes not) - not a solution that CPP can use though.
Hello ShadoOoW 
The improvements in the last few 1.72 betas are awesome!
Any idea when the 1.72 final would be released?
I would like to do it in december, but no promises. I need especially peoples playtesting and buildtesting the new beta with the NWN©X in use.
Unlike other packages I cannot afford to release a product with even single bug.
I searched this topic for "swift spell" to see if it has been discussed at all. Spells like Wraithstrike and Blade of Blood are almost useless when they take up a full combat turn, so I have a poooossible suggestion for how to implement spells: Why not have the spell in it's root description use the Quicken feat without checking if the player has it? Just activate it silently as part of casting the spell, or copy the Quicken script and rename it Swift to allow the differences. If something like this is implemented, something like an ATB gauge would be nice with tic-marks for when your attacks or spells will take place in order to make timing things easier.
I searched this topic for "swift spell" to see if it has been discussed at all. Spells like Wraithstrike and Blade of Blood are almost useless when they take up a full combat turn, so I have a poooossible suggestion for how to implement spells: Why not have the spell in it's root description use the Quicken feat without checking if the player has it? Just activate it silently as part of casting the spell, or copy the Quicken script and rename it Swift to allow the differences. If something like this is implemented, something like an ATB gauge would be nice with tic-marks for when your attacks or spells will take place in order to make timing things easier.
It should be possible to do it with NWNX.
Ingredients: nwnx_events plugin (unfortunately I think only linux version has this) and nwnx_funcs (for adding feats)
Plan: in OnSpellCast (which trigger before you actually cast, check for spell id and if matches your spell then add autoquickspell III feat on character. Next spell remove that feat before cast.
A few more things I'm surprised big patchers haven't 'fixed.. Chain Shirt should be light armor, objects should be immune to critical hits, and undead shouldn't be able to heal with various 'cure wounds' potions.
Edit: And scythes are martial weapons..
A few more things I'm surprised big patchers haven't 'fixed.. Chain Shirt should be light armor, objects should be immune to critical hits, and undead shouldn't be able to heal with various 'cure wounds' potions.
Edit: And scythes are martial weapons..
because this project is not allowed to do any of this
Many players believe that what Bioware implemented is set in the stone and cannot be changed. And that is even better that way. Changing these things would be by the opinion of most gamers too big balance change. Some dislike CPP already because a few changed like this but I think there is minimum of them.
The issues you mention are 3.0 / 3.5 differences, while I personaloly agree that 3.0 is broken ruleset and 3.5 is a patch, majority peoples from NWN community disagree and they want 3.0 instead. Or just what Bioware decided.
Other than that, there are laos technical difficulties to make some things, like the mentioned immunity to critical hits for objects. But I think that even this would be a big issue for most peoples.
And undeads., they are not healed by cure wound spells, neither heal or mass heal, only greater restoration and healers kits (which in 1.72 you can modify in script actually but I havent changed that again because of the issue I mentioned).
Anyway, the mentioned critical/sneak immunity for objects (attackable placeables) is doable with NWNX_Patch plugin.
Question is, do you want it? Is it worth it, I mean doesnt this turn into another reason why other ppls dont want this patch? Of course, since its NWNX its optional and I will provide a way to deactivate it but it will be by default turned on.
I've just recently decided to update from 1.70 to 1.71, but I've encountered some compilation problems due to this.
First of all, when I tried to modify Epic Warding script, a compilation error popped out in nw_i0_spells.nss on line 552 (variable type error):
int clOverride = spell.Level;
The whole section of the script is as follows:
Retour en haut
//1.70: caster level override workaround, since ResistSpell function uses its own values
//and its hardcoded I apply a spell resistance decrease in the appropriate ammount in order to cheat
//this hardcoded function. This works pretty well for non-monks. Unfortunately 12+ lvl monks are immune to this solution.
int clOverride = spell.Level;
int clDefault = GetCasterLevel(oCaster);
if(GetLastSpellCastClass() == CLASS_TYPE_INVALID && GetSpellCastItem() == OBJECT_INVALID)//fix for bug in SR check formula
{//internal SR calculates with CL = innate level*2-1, and yes -1 for cantrips
int clSR = StringToInt(Get2DAString("spells","Innate",GetEffectSpellId(EffectDazed())))*2-1;
if(clDefault != clSR)//if default CL accidentaly matches CL for SR then its fine
{
if(!clOverride) clOverride = clDefault;
clDefault = clSR;
}
}
int SR = GetSpellResistance(oTarget);
effect eWorkaround;
if(bAOE)//AOE workaround to fix various exploits
{
int nResisted = 0;
if(SR > 0)
{
if(d20()+(clOverride > 0 ? clOverride : clDefault) < SR)//resisted
{
nResisted = 1;
DelayCommand(fDelay,ApplyEffectToObject(DURATION_TYPE_INSTANT,EffectVisualEffect(VFX_IMP_MAGIC_RESISTANCE_USE),oTarget));
}
string sFeedback = GetStringByStrRef(8342);
sFeedback = GetStringLeft(sFeedback,GetStringLength(sFeedback)-10);
sFeedback = GetStringRight(sFeedback,GetStringLength(sFeedback)-10);
sFeedback = "<c›ţţ>"+GetName(oTarget)+"</c> <cÍţ>"+sFeedback+" "+GetStringByStrRef(nResisted == 1 ? 8343 : 5353)+"</c>";
SendMessageToPC(oTarget,sFeedback);
SendMessageToPC(oCaster,sFeedback);
}
return nResisted;
}
else if(clOverride > 0 && SR > 0)//spell penetration correction
{
//if overriden above default caster level we must alter spell resistance of our target...
if(clOverride > clDefault && clOverride+20 >= SR)
{ //do nothing if there is no chance to penetrate SR anyway
eWorkaround = EffectSpellResistanceDecrease(clOverride-clDefault);
ApplyEffectToObject(DURATION_TYPE_TEMPORARY,eWorkaround,oTarget,0.01);//temporary workaround to force game use correct values
SR = -255;
}
else if(clOverride < clDefault && clDefault+20 >= SR)
{ //do nothing if the default CL has no chance to penetrate SR anyway
eWorkaround = EffectSpellResistanceIncrease(SR+clDefault-clOverride);
ApplyEffectToObject(DURATION_TYPE_TEMPORARY,eWorkaround,oTarget,0.01);//temporary workaround to force game use correct values
SR = -255;
}
}//end of caster level workaround
I tried to build my module and check for any other compilation errors I might find and more of them popped out.
zep_o0_death.nss returned a compilation error in nw_i0_generic.nss, line 857 (lack of right bracket error):
if (GetLocalInt(OBJECT_SELF,"70_ALLOW_SHAPECHANGE") && TalentShapechange(oIntruder)) return 99;
As far as I've found out, these two scripts are the culprits, but there might be more. I only got compilation errors on scripts I modified, after all, and if there are any unmodified ones, like some other spell scripts, then they might not compile without letting me know.
Any idea what I should do?
Edit: I've also tried opening my modified missile storm scripts. And I couldn't, a message appeared saying that 70_inc_spellfunc content could not be found. Which makes me wonder, is 1.71 compatible with modules made with 1.70? Especially if some of scripts have been modified?
I've tried creating a whole new module and checking things there. When it comes to compilation, it's all the same problems, when I try to compile a spell or something else that caused problems in my module, I get an error in one of these two scripts. The only difference is that it lets me open missile storm scripts (no message about 70_inc_spellfunc content missing), but I still can't compile them.
I've just recently decided to update from 1.70 to 1.71, but I've encountered some compilation problems due to this.
First of all, when I tried to modify Epic Warding script, a compilation error popped out in nw_i0_spells.nss on line 552 (variable type error):
int clOverride = spell.Level;
The whole section of the script is as follows:
well I changed some of the functions and includes over 70 and 71 so exactly these kind of issues wont happen in future, the scripts and includes from 1.71 are not just backwards compatible but also forwards (ie. you can compile new spellscript from 1.71 with old includes and also compile old spellscript with new includes).
Unfortunately, if you built on 1.70 and modified some of the scripts and includes, specifically nw_i0_spells, 70_inc_spells etc. you get this kind of error.
If you send me full module (without areas if you dont trust me) I can merge it and fix it for you. Otherwise if you want to do this yourself you need to:
1. isolate includes/spellscripts you modified in your module
2. compare them with vanilla 1.70 includes/spellscripts (to see what have you changed there)
3. take version of the include/spellscript from 1.71 and add the changes youve made into the old versions
4. replace old for new one
5. recompile module
It would be really best if you could just send me the module so I can take a closer look and not just guess. PM me.
EDIT: oh and yes, 70_inc_spellfuncs no longer exists in 1.71
On the subject of compile errors... I wonder if you might consider renaming the struct spell definition to say struct spell_st or something? My external compiler (nwnnsscomp) seems handle that poorly. It does not let me have the struct definition and a variable of that type in the same scope. It's a very small change to 70_inc_spells to get around this, but a fairly major rework of the compiler to make it handle this right. I can just pull 70_inc_spells into my code base but I'd prefer not to have to carry
that around forever if possible. Just thought I'd ask while 72 is still pending
On the subject of compile errors... I wonder if you might consider renaming the struct spell definition to say struct spell_st or something? My external compiler (nwnnsscomp) seems handle that poorly. It does not let me have the struct definition and a variable of that type in the same scope. It's a very small change to 70_inc_spells to get around this, but a fairly major rework of the compiler to make it handle this right. I can just pull 70_inc_spells into my code base but I'd prefer not to have to carry
that around forever if possible. Just thought I'd ask while 72 is still pending
This alredy happened in 1.71.
In 1.70 first cpp version the struct was named struct spell spell; which external PRC compiler wasne able to handle
in 1.71 the struct is named struct spells spell; which PRC compiler handles correctly. Also snce 1.71 spell structure is global.
So - check for the definition, it might be possible you have outdated 70_inc_spells? if not and you get error even with this then whats your compiler?
I pulled the scripts from 1.71. The md5sum of the bif I used is here:
6998535f96ef94878c8d6b3b8ca1dc34 patch171.bif
The spell struct variable _is_ global but the struct definition and variable are both named spell. Maybe I accidentally got one of the last RCs?
I'll try to download the latest 1.71 and see if it's different from what I currently have.
Drat. Okay. I seem to have just merged in an old version of 1.71 "final" from dec 2013 called NWNPatch171_EN.zip. The new final version does have the spells change you mentioned (and is 7zipped and has some nwnx files in it). Time to go see what else is different 
Edit: Also the 1.71 builder resources have a lot of script changes including the x3_inc_horse file which I thought was a 1.72 thing. Is 1.71 still changing?
Drat. Okay. I seem to have just merged in an old version of 1.71 "final" from dec 2013 called NWNPatch171_EN.zip. The new final version does have the spells change you mentioned (and is 7zipped and has some nwnx files in it). Time to go see what else is different
Edit: Also the 1.71 builder resources have a lot of script changes including the x3_inc_horse file which I thought was a 1.72 thing. Is 1.71 still changing?
1.72 extended upon this, some of the fixes specifically not losing skin under ELC/ILR was already in 1.71
final 1.71 was released in march 2014 i think or month later, after that there were few updates: first update one day later because of a bug I dont recall now, then there were several updates for language translations which needed to repack the installerversion but there were no changes to any other files
My bad... I seem to have used the wrong bits Doesn't seem to be that much to re-merge at least. Still, 1.71 bif does not have x3_inc_horse while 1.71 builders resources does. Seemed odd.
My bad... I seem to have used the wrong bits
i will check this, its possible i messed 1.72beta with 1.71final for builders recources
My bad... I seem to have used the wrong bits
in my local copy there is no x3_inc_horse in builders resources for 1.71 nor is this include present in community patch v. 1.71. I checked the downloads on new vault but the 1.71 builders resources matches with my local copy -> no x3_inc_horse in them.
x3_inc_horse was changed in 1.72 beta but afaik I havent actually published builders resources for this version, so its quite weird 
in my local copy there is no x3_inc_horse in builders resources for 1.71 nor is this include present in community patch v. 1.71. I checked the downloads on new vault but the 1.71 builders resources matches with my local copy -> no x3_inc_horse in them.
x3_inc_horse was changed in 1.72 beta but afaik I havent actually published builders resources for this version, so its quite weird
Unfortunately I did not keep the thing I downloaded. Fairly certain it was the stand alone 1.71 builders resources zip. But whatever, its not there now, so no worries.
Btw, I'm working through merging your spell fixes into the ones I have already modified (about 190 ) but there's a lot of good fixes there. Thanks for all the work on those (and the rest of it)!
