Community expansion, what's your take?

[Legacy_MerricksDad]

               

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.

               
               

               
            

[Legacy_meaglyn]

               

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.

               
               

               
            

[Legacy_Gruftlord]

               

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.

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.

Anyway, here is a short list of the features i like the most about CPP:

For players:
-fix for light halos that should be covered
-fix for low res barkskin
-less brown bags as ground objects
-fix for circle kick (is a server side fix though)
-enemies use the abilities they were given
-smart enemies use spells smart to counter your buffs
-module switch (server side) for evasion in heavy armor (iirc)

For builders
-fixed walkmeshes on tiles
-module switches to enable/disable specific options
-spell scaling options for prestige classes, potions and scrolls
               
               

               
            

[Legacy_MerricksDad]

               

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.

               
               

               
            

[Legacy_MerricksDad]

               

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.

               
               

               
            

[Legacy_Gruftlord]

               

Except if I want CPP changes AND my changes

Yep, this is the one case that is labor intense. If you just install CPP without worrying to get all fixes, it works like this:
If you made a change to a script, it will work, even when compiling new (changed include scripts from CPP should make no trouble, include scripts you changed neither), irregardless of whether CPP changes the script or not.
if you didn't change a script but CPP did, you get CPP's benefit.
if neither of your mods changed something, you get vanilla.
...

So?
               
               

               
            

[Legacy_meaglyn]

               

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.

               
               

               
            

[Legacy_Shadooow]

               

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.

               
               

               
            

[Legacy_Proleric]

               

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 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.


As I think you appreciate, judging by your comments on AI, the scripting risk is much simpler than some posts here imply. For example, assume Bioware script A sets object property x to 1 or 2, and my custom script B is expecting that. Suppose that, for some good reason, the modified patch script A' sets x to 3. Now my script B is broken. Easy as that.


Professionals will recognise this as motherhood, but, hey, this is a community for everyone, so what the heck.


Ordinarily, I wouldn't bother to comment on a mod that's not for me. However, the issue with CPP is that it impacts us all, whether we like it or not. Also, the OP asked for opinions.


Fortunately, the remedy is simple. My stuff is certified for 1.69, so, if a player thinks they have a bug, I will ask them to reproduce it without CPP or other mods.
               
               

               
            

[Legacy_Shadooow]

               

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.

               
               

               
            

[Legacy_3RavensMore]

               

Well, at least nobody is arguing over which is better--Q or CEP.  That's always been so much fun.  /s

               
               

               
            

[Legacy_Ssythilac]

               

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.

               
               

               
            

[Legacy_MerricksDad]

               

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.

               
               

               
            

[Legacy_meaglyn]

               

@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 '>.  

               
               

               
            

[Legacy_KMdS!]

               

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.