Proleric, you are spreading FUD for no good reason. Who is trying to persuade you? You are not the OP. You have simply been called out for making bad claims which muddle the issue, and continue to do so.
I am not going to waste my time restating my posts above to you when you fail to grasp context, and obfuscate how NWN actually works with claims that I am wrong.
I don't have time for this.
Given that this seems to have boiled down to scripting, I'm not even sure why this conversation exists, because obviously, given just the first few comments, somebody could just report the name of all changed scripts that CPP has, and if you have custom scripts that call on those in any chain, simply decide to use it or not, and go from there. Bam. Problem solved. Post the list of scripts changed. Post exactly what was changed. Make a public posting of reasons why not to personally modify that script in your mods further, and/or show reasons why that very specific script causes an issue that is generally detrimental to the modding community. Do that and we never have to see this thread or another one like it again.
Oh if only that was the case. All that you mention has already been done more or less by Shadooow.
Given that this seems to have boiled down to scripting, I'm not even sure why this conversation exists, because obviously, given just the first few comments, somebody could just report the name of all changed scripts that CPP has, and if you have custom scripts that call on those in any chain, simply decide to use it or not, and go from there. Bam. Problem solved. Post the list of scripts changed. Post exactly what was changed. Make a public posting of reasons why not to personally modify that script in your mods further, and/or show reasons why that very specific script causes an issue that is generally detrimental to the modding community. Do that and we never have to see this thread or another one like it again.
That would take me year maybe more 
. No thats not possible to do, there are 1096 scripts and 36includes in CPP and 95% of them are modified vanilla scripts. Also there are some scripts that weren't modified themselves, but are included because they are recompiled with modified libraries (some of the AI scripts case).
Each script contains a comment summary of the changes done in CPP in top of the script, showcase:
/*
Patch 1.72
- stun vfx will no longer appear on target who has not been affected by this spell at all
Patch 1.71
- disabled self-stacking
- added duration scaling per game difficulty
*/
and contains as much comments inside script as was possible, usually they don't include the changes from summary though, example of the function in include:
int spellsIsTarget(object oTarget, int nTargetType, object oSource)
{
// * if dead, not a valid target
if (GetIsDead(oTarget) && (!GetIsPC(oTarget) || GetCurrentHitPoints(oTarget) < -10))//1.72: no spell immunity to dying players it makes no sense and looks weird
{
return FALSE;
}
int nReturnValue = FALSE;
switch (nTargetType)
{
// * this kind of spell will affect all friendlies and anyone in my
// * party, even if we are upset with each other currently.
case SPELL_TARGET_ALLALLIES:
{
if(GetIsReactionTypeFriendly(oTarget,oSource) || GetFactionEqual(oTarget,oSource))
{
nReturnValue = TRUE;
}
break;
} /*SPELL_TARGET_SINGLETARGET:*/
case 2://1.70: added new value now 2 == SPELL_TARGET_SINGLETARGET which is used for spells with single target, when these spells
{ //are cast at neutral target then they are supposed to hurt target which is not possible with SPELL_TARGET_STANDARDHOSTILE
if(!GetIsReactionTypeFriendly(oTarget,oSource))
{
if(oTarget == spell.Target)//1.72: this will allow to turn aoe spell into singletarget
{
nReturnValue = TRUE;
}
}
else
{
SendMessageToPCByStrRef(oSource,66245);
}
}
case SPELL_TARGET_STANDARDHOSTILE:
{
if(GetIsDM(oTarget))//1.71: fixed rare case when invisible dungeon master is targeted
{
return FALSE;
}
int bPC = GetIsPC(oTarget) || (GetIsPossessedFamiliar(oSource) && GetMaster(oSource) == oTarget);//1.70: PC is not recognized when controlling familiar
int bNotAFriend = FALSE; //attacking on self is allowed
int bReactionType = GetIsReactionTypeFriendly(oTarget, oSource);
if (!bReactionType)
{
bNotAFriend = TRUE;
}
// * Local Override is just an out for end users who want
// * the area effect spells to hurt 'neutrals'
if (GetLocalInt(GetModule(), "X0_G_ALLOWSPELLSTOHURT") == 10)
{
bPC = TRUE;
}
int bSelfTarget = FALSE;
object oMaster = GetMaster(oTarget);
// March 25 2003. The player itself can be harmed
// by their own area of effect spells if in Hardcore mode...
if (bPC && bNotAFriend && GetGameDifficulty() > GAME_DIFFICULTY_NORMAL)//1.70: only apply this for players!
{ //1.71: doesn't apply in no-pvp area
// Have I hit myself with my spell?
if (oTarget == oSource)
{
bSelfTarget = TRUE;
}
else
// * Is the target an associate of the spellcaster
if (oMaster == oSource)
{
bSelfTarget = TRUE;
}
}
// April 9 2003
// Hurt the associates of a hostile player
if (!bSelfTarget && GetIsObjectValid(oMaster))
{
// * I am an associate
// * of someone
if ( (!GetIsReactionTypeFriendly(oMaster,oSource) && GetIsPC(oMaster))
|| GetIsReactionTypeHostile(oMaster,oSource))
{
bSelfTarget = TRUE;
}
}
// Assumption: In Full PvP players, even if in same party, are Neutral
// * GZ: 2003-08-30: Patch to make creatures hurt each other in hardcore mode...
if (GetIsReactionTypeHostile(oTarget,oSource))
{
nReturnValue = TRUE; // Hostile creatures are always a target
}
else if (bSelfTarget)
{
nReturnValue = TRUE; // Targetting Self (set above)?
}
else if (bPC && bNotAFriend)
{
nReturnValue = TRUE; // Enemy PC
}
else if (bNotAFriend && (GetGameDifficulty() > GAME_DIFFICULTY_NORMAL))
{
if (GetModuleSwitchValue(MODULE_SWITCH_ENABLE_NPC_AOE_HURT_ALLIES) == TRUE)
{
nReturnValue = TRUE; // Hostile Creature and Difficulty > Normal
} // note that in hardcore mode any creature is hostile
}
break;
}
// * only harms enemies, ever
// * current list:call lightning, isaac missiles, firebrand, chain lightning, dirge, Nature's balance,
// * Word of Faith
case SPELL_TARGET_SELECTIVEHOSTILE:
{
if(GetGameDifficulty() == GAME_DIFFICULTY_DIFFICULT)
{
return oTarget != oSource && spellsIsTarget(oTarget,SPELL_TARGET_STANDARDHOSTILE,oSource);
}
else if(GetIsEnemy(oTarget,oSource))
{
nReturnValue = TRUE;
}
break;
}
}
// GZ: Creatures with the same master will never damage each other
if (GetMaster(oTarget) != OBJECT_INVALID && GetMaster(oSource) != OBJECT_INVALID)
{
if (GetMaster(oTarget) == GetMaster(oSource))
{
if (GetModuleSwitchValue(MODULE_SWITCH_ENABLE_MULTI_HENCH_AOE_DAMAGE) == 0)
{
nReturnValue = FALSE;
}
}
}
return nReturnValue;
}
This combined with a summary in patch notes / readme.
I can't do more than that. What you propose is actually not a task I should be doing but those who claims the things are wrong.
I don't think I am obligated to prove my patch will not break things, instead those who claim this should prove CPP break things or explain why some of the changes are wrong. I've made some changes to the features/fixes of CPP based on previous discussion.
Can no one articulate the top ten must-have fixes that this patch delivers?
I tried to write article like that, but never finished it. You can read it here, there are 3 points, 7 are missing 
. Imo, the greatest benefit of CPP is the whole collection of multiple unique fixes you won't get anywhere else. Some of the important bug-fixes can be afterall get separately on vault. But thats my opinion as a author so...
Anyway a good question and I would love to hear what the users of CPP would answer to that.
Well there's the answer for Proleric. 95% of those scripts are modified Vanilla scripts. I assume many of those were the base scripts used with include statements. So if Proleric has any scripts like mine, I could never use CPP with my own content, because I too modified a bunch of vanilla scripts. Except in my case, I rerouted the vanilla scripts and put all the new content in new scripts, only adding the include names for my own scripts, that way all the old functions remained 100% intact. Only the mechanics changed. This gave me vanilla and 4e, as well as non-standard varieties of certain functions. For me, when there is ever the case that vanilla includes were modified, that's a red flag, and I think that is what Proleric is saying. If we both modified the same scripts, then that's a serious problem.
But how many people actually do that? Almost nobody I guess. Meaning that for a quick "upgrade" from not-quite-right vanilla, to the CPP, most users would have zero issues at all.
I think you are seeing goblins where there are not any.
If you have modified vanilla includes then you must also have copies of any scripts which use those includes in your modules. None of that will change if you install CPP. You will still compile your files with your versions of the includes. Nothing will change even if CPP also modified the same include.
Any scripts which use those includes which you do not have in your module will get the cpp functionality but you won't be compiling them so it won't matter that you changed the include differently.
CPP is installed as a patch, underneath your module. The scripts do not go into your module or overwrite your changes.
The vast majority of the modified vanilla scripts are the spell and feat impact scripts. All of them have been touched to use the updated spell variable system.version.
Yes, there may be merge work involved, potentially, as there was with the 1.69 patch, if you want the fixed behavior. But that's not a reason not to use it, nor to recommend against it.
Still don't see why you would think your scripts break with CPP installed. The compiled scripts should work in any way (e.g. EMS has no problemd running with CPP) and even your scripts should compile without issues. The include scripts will answer back to yours without issue, and the ones you have overwrittn from CPP will behave just like before.Well there's the answer for Proleric. 95% of those scripts are modified Vanilla scripts. I assume many of those were the base scripts used with include statements. So if Proleric has any scripts like mine, I could never use CPP with my own content, because I too modified a bunch of vanilla scripts. Except in my case, I rerouted the vanilla scripts and put all the new content in new scripts, only adding the include names for my own scripts, that way all the old functions remained 100% intact. Only the mechanics changed. This gave me vanilla and 4e, as well as non-standard varieties of certain functions. For me, when there is ever the case that vanilla includes were modified, that's a red flag, and I think that is what Proleric is saying. If we both modified the same scripts, then that's a serious problem.
But how many people actually do that? Almost nobody I guess. Meaning that for a quick "upgrade" from not-quite-right vanilla, to the CPP, most users would have zero issues at all.
Not if my scripts are the same name as the scripts in the CPP. I'd have to add my includes and changes to the same named scripts to the CPP scripts to make mine work if I made changes or had to recompile, right? While that is not really a big deal, when I make changes to my scripts again, I'd have to keep them separate from the CPP scripts, and use a non-standard compiler instead of just using the one in the toolset, which would grab the CPP installed base scripts, right? Whereas if the CPP scripts were not loaded into the area of standard content, and were instead in some other hak/erf format, I could compile my scripts pulling only the original content into them without having to worry about if something had changed which is not documented. And then anything I wanted to be compiled with CPP changes I could import the erf/hak package and compile those scripts using the included CPP files. With those scripts being added to the base, I have to use outside programs or know the scripts that changed.
I think you are seeing goblins where there are not any.
If you have modified vanilla includes then you must also have copies of any scripts which use those includes in your modules. None of that will change if you install CPP. You will still compile your files with your versions of the includes. Nothing will change even if CPP also modified the same include.
Except if I want CPP changes AND my changes, but I don't know what script changed what.
Except if I want CPP changes AND my changes
That's a bit of a different story... But applying the patch really should not break your module at all. You will get all the 2da fixes for 2das you haven't overwritten in your haks, you will get all the tileset fixes you have not overwritten in your haks, you will get all the script fixes for all the spells and feats and any others that you have not modified in your module/haks.
Then you can merge in the rest as you have time. Personally I'd consider reworking your scripts to call the vanilla scripts with ExecuteScript when you want vanilla instead of modifying them directly to do your 4e code or vanilla. And have your events and creature script slots etc set to your new scripts which can determine if 4e or vanilla functionality is needed. But that's my professional software engineer hat. Modifying the base includes is a maintenance burden you've taken on already. But you can compare yours to 1.69 and CPP's to 1.69 and make the merges. The diff command (and windows equivalent?) is your friend 
But you don't have to do it all (or at all). Or all at once. The point is you get a lot of the benefit even without doing this.
Except if I want CPP changes AND my changes, but I don't know what script changed what.
If you made changes to vanilla (spell) scripts AND you want changes and fixes that CPP brings then you can:
1) either delete your script, open new script from core resources (which will bring new CPP version) and reimplement your changes to the script from scratch - provided you know what you did there this is definitely the easier way to do that especially for spell scripts which are rewritten significally since they use brand new structure
2) compare your temp0 with CPP scripts which you can get in 1.71/1.72 builder's resources folder (should be part of any distribution) or by using Ganymede bif exporter and you export patch171/172.bif (builders resources doesnt include few "system" scripts like nw_c2_default*). Personally I use Beyond Compare for comparing this and its reason why I try to keep original includes as much intact as possible and comment my changes as much possible.
3) if comparing CPP spell scripts with your spellscripts isn't option (too different from vanilla) and you want to get fixes from CPP to your spells, then you can read the Spell Changes readme, read what was changed in which spell and, if you want that fix/change, code it yourself into your version. To get the exact code, you need to compare CPP version from builder's resources with vanilla version which can be download here.
The more spell scripts you changed the less appealing is merging the spell fixes into them but as was said, it will work without doing that, you will just not get the CPP fixes/features and then its totally up to you whether you want them or not. There is no way to install particular script fix into custom script and if CPP used erf/haks this task would be even harder because scripts in haks will not only take precedence over your scripts in module, it will also prevent you to modify them in toolset since it will always open the version from hak (iirc). Erf is similar case because when speaking about vanilla scripts toolset is not able to distinguish and tell you which script will overwrite your modified scripts, when importing it will report you that all of those scripts will overwrite and thats it.
I don't make that claim. My point is only that the patch entails effort and risk. Given the outline of the benefits (for which thanks), on balance, I choose to do nothing. Remember, the obligation is on the seller to sell, not on the buyer to buy.I don't think I am obligated to prove my patch will not break things, instead those who claim this should prove CPP break things or explain why some of the changes are wrong.
Remember, the obligation is on the seller to sell, not on the buyer to buy.
But the situation here is like:
"buy this settopbox it will improve your tv"
-> "no it will break my tv controller and i wouldn't be able to swap channels"
"it won't try it and if you won't be satisfied I will return you money"
-> "i don't wan't to try it, i could break my tv controller..."
Seriously, I'm not sure what are you trying on me here.
Well, at least nobody is arguing over which is better--Q or CEP. That's always been so much fun. /s
This was a motive of discussion? Really? 
I mean, is brutally obvious that Q is so much better. Those two doesn`t even challenge in the same league. In the most equable mood you only could see that CEP is a cuantitative thing, while Q is cualitative.
But the situation here is like:
"buy this settopbox it will improve your tv"
-> "no it will break my tv controller and i wouldn't be able to swap channels"
"it won't try it and if you won't be satisfied I will return you money"
-> "i don't wan't to try it, i could break my tv controller..."
Seriously, I'm not sure what are you trying on me here.
The way I see it is that nobody is selling or buying. It's optional free content.
@Proleric, I understand your concern, it just seems a bit high. There are not really that many scripts changed other than the spells and traps, and the chance that you hit a script A'/script B case is pretty small. I'd think you could test those integration points pretty easily. But that said, I can totally see your desire not to take the risk, especially in SP story-focused modules like yours. In a PW setting I think all the fixes may have more value and more easily outweigh the theoretical risks and bit of work. As I said, I've been pleasantly surprised at how little broke (nothing really) and am happy with the improvements (as of 1.71 anyway .
I wasn't sure whether I should post here or not since I am biased as a creator of the CPP its clear what my advice will be.
Please do...I appreciate the time you have taken and the work you have done. That is why I started this thread. It would be a major adoption and I wanted to get a info from the members here who have had some experience with it. I only recently came back to NWN and am looking or ways to get up to date.
@henesuz....
I am aware of this, but on a mod you are actively creating, any patch could affect pre-existing work when recompiled as development continues as the includes then become a part of the compiled ncs file. This is to what I was alluding to. Any existing compiled work would be unaffected. The catch occurs if you should ever recompile using the patched version of NWN. This in not to say that there will be any problems, just to say that there CAN be problems and that they may not be readily found, just a possible head ache.
@meaglyn....Thanks for the info, I noted that you can back out easily, if on Linux. I wonder how easy for Windows? This could be the make point for me. This way I can test and see the effects of the patch on my work. Pulling CEP is a nightmare, if CPP could be pulled easily, that would be excellent should I find I preferred not to use it. Oh ya, the list of info for the CPP is not light reading, lol, there's a lot to read in that puppy.
Proleric makes a good point about reasons/benefits for adoption of any content. While I have seen what is essentially a change log for the CPP. Maybe a list of main benefits may be in order? Reading through a massive change log is a bit more work than desired and doesn't actually flesh out reasons to adopt.
I may be in the same situation Merriksdad and Proleric are in. I created my work from scratch and have modified much of the standard BW material over the lase 12 years with the specific intent to recreate the full pnp aspect pf AD&D. Tweaked this, Tweaked that, the work is a massive alteration, modification, and addition of scripts, and 2da's. Sometimes I regret the adoption of CEP for the work entailed to modify/merge some work, but the fact that I may be able to pull CPP should it excessively impact my existing work may be the selling point most impactful to me.....Ha! it IS a purchase after all, Seller sell that puppy, Buyer beware. 
I'll say one thing, it has been a pleasure seeing all the posts from so many of those I find serious denizens of these forums. I thank you all for the input.
Yes theoretically both Proleric and you are right. CPP can break things, even with just installing, if your custom content script relies on some unintentional vanilla script behavior/bug your script might not work correctly. And if you recompile all scripts after installing CPP its theoretically possible your scripts will behave differently.
Thats however only theory and while its possible to happen, chance that it happens is very very small. The former issue is to be expected - if you rely specifically on some bug (like it my example SignalEvent - Shield of Faith) then if CPP fixed that bug obviously your script stop working. I don't think anyone has a script like this. I don't even think anyone actually knew Shield of faith signals Camouflage spell ID and was relying on that. And if by any chance someone did, then is it such a big deal really?
As for recompiling scripts with CPP. As was said - CPP is designed to provide compatibility with custom content. If compiling your script with CPP includes will throw compile error or even change its functionality (which afaik nobody experienced yet) then its bug in CPP design and it will get fixed. If CPP was abadonware and there was no support, if you were ever hit some issue, I would understand the hesitation. But thats not the case I am around and I offer full support, especially for PWs.
But yes there will be changes, especially when regarding to AI as I informed already. If you don't want anything changed on your server/module, stay out of it. If you are willing to do some work for all those fixes/features CPP offers, CPP can be great resource. Due to the way it works its easy to disable anything. You don't like your AI being changed? Ok restore vanilla nw_c2_default* scripts. You don't like the new spell immunity/spell mantle mechanics? (spell mantle is now depleted only when the spell is not caught by spell immunity) use module switch to restore this functionality to the vanilla way. Etc.
@meaglyn....Thanks for the info, I noted that you can back out easily, if on Linux. I wonder how easy for Windows? This could be the make point for me. This way I can test and see the effects of the patch on my work. Pulling CEP is a nightmare, if CPP could be pulled easily, that would be excellent should I find I preferred not to use it. Oh ya, the list of info for the CPP is not light reading, lol, there's a lot to read in that puppy.
CPP can be removed by installing 1.69 critical rebuild or by replacing modifief xp2patch.key file in NWN folder with 1.69 version- If you install CPP with installer each overwrite file will be backuped (xp2patch.bak), if you install it using manual instalation you need to backup it yourself however the original xp2patch.key can be downloaded separately in CPP vault project page.
CPP overwrites 3 files only. xp2patch.key, dialog.lk and one of the texture packs in texturepack folder.
One more question....any module saved with 1.7x can only be opened by that version and not a prior version? Most likely he case I imagine.....
One more question....any module saved with 1.7x can only be opened by that version and not a prior version? Most likely he case I imagine.....
1.71 doesn't work as official patches in this regard, its fully compatible with 1.69, player with 1.69 can play on server with 1.71 and viceversa, same apply for singleplayer modules and savegames.
did you read this?
Only if builder of the module/you specifically want it to be playable only with 1.71 (for whatever reason), you can enforce this by adding patch171.hak into your module resources.e
edit: changed the link
You don't have to dig into all the details and do a full merge to try it out. I have a large number of scripts and systems and haks and changes to 2das and what not too. The merge does take some time and when you do that you do need to dig into it. But you can get a pretty good idea of what's going on by installing it and then opening and building and testing your module. It should "Just Work" ™.
And as was said before you'll get any fixes in 2das and scripts you don't have copies of. You can do all that fairly painlessly. Kick the tires etc. Then if you like it you start to merge it in. It is harder to back it out once you do that of course... When I did that I kept the 2das in a different top hak in my git tree so I could undo it if needed, but it turned out not to be an issue.
Retour en haut