Community expansion, what's your take?

[Legacy_Proleric]

               I hear you speaking from the heart, but you're claiming something you can't possibly know.


Whenever a patch script changes an object or variable, it's altering the state of the system used by custom scripts in an unexpected way. So, there's no certain way of knowing what impact it will have. If the patch includes fixes that depend on changes to two scripts, it's even worse, because custom scripts might override one but not the other, leading to an unintended outcome.


Upgrading my modules from 1.68 to 1.69, I found many things that had to change. Why would CPP be different?


What you are saying amounts to


A(B(x)) = A(C(x))


for all functions A, B, C of x, which wasn't true when I was at school.


I hear talk of bugs and hobby horses introduced by CPP. That might or might not be true, but I don't have any incentive to find out as long as the selling pitch amounts to vague talk about fixing many unnamed bugs, without a single compelling example.
               
               

               
            

[Legacy_tobtor]

               

Did anyone actually experience scripts etc not working when CPP is installed? Or is it more theoretical issue?

 

If no-one have any problems, perhaps some testing is in order before people are discouraged to use it?

               
               

               
            

[Legacy_henesua]

               

Testing is not needed. Its a mix fabrication and confusion that was used at the beginning to malign the project because of personal grievances that have nothing to do with the project itself.

 

We all know that scripts and blueprints in your module take precedence over those in the patch, and that 2das and other resources in your HAKs take precedence over those in the patch.

 

Proleric, seriously? I know you have the technical chops so why muddy the waters with such a muddle?

 

Build a module without the patch. We'll call this state A. Run the module in state A.

- Every script and blueprint that you created in the module will behave as expected. ==> Result set A.

Install the patch. Run the module in State A.

- You still get Result set A. Only the scripts and blueprints that you did not touch will behave differently.

Uninstall the patch. Run the State A module.

- Result set A

 

Thats all that matters in this discussion. Installing the patch does not "break" a module that you are working on. It changes scripts that you do NOT touch.

 

Now you can get into the minutiae of how once you compile your State A module on a machine with the patch that you get a State B module. But the following still holds true:

 

State A: Compile a module without the patch.

State B: Take Module State A and compile it on a computer with the patch installed.

Restore to State A: Take the State B Module and compile it on a machine without the patch.

               
               

               
            

[Legacy_Gruftlord]

               

All changed scripts are done in a way to ensure backwards compatibility with other scripts made by you. should you encounter a case where this is not true, it is a bug per the CPP mission and will happily be fixed if you can report on it.

               
               

               
            

[Legacy_KMdS!]

               

Build a module without the patch. We'll call this state A. Run the module in state A.

- Every script and blueprint that you created in the module will behave as expected. ==> Result set A.

Install the patch. Run the module in State A.

- You still get Result set A. Only the scripts and blueprints that you did not touch will behave differently.

Uninstall the patch. Run the State A module.

- Result set A

 

Thats all that matters in this discussion. Installing the patch does not "break" a module that you are working on. It changes scripts that you do NOT touch.

 

I see one situation unaccounted for, the "including" of untouched scripts into custom work that might be modified. Being as no further updates were expected, much of the existing wonkyness of NWN went from bug to feature. AS such, it is possible that modifications to nwn 1.69 could break existing independent work ......that would be an unwelcome situation. I believe this is what Proleric is alluding to. This is what would most likely be a concern for me, but that is why I asked the question to start the thread. I wanted to get as much input as possible to help me decide whether I will adopt the project into my work.

 

While being able to work with Shadoow to fix any "caused bug" would be helpful, the possible of unintended consequences might not show up in your work till later and finding it can be a lot of undesired work. It may take months before the hiccup is found.

               
               

               
            

[Legacy_meaglyn]

               

This is covered by the statement intended to be backwards compatible.  I did not find any issues with modified include files. Call signatures were not changed. Implementations may have been but that should not effect a caller unless the caller is relying on some unintended side-effect of the previous implementation. 

 

I use a merge of Q and CEP and a total re-work of the spell system which patches about half of the spell scripts. The work I had to do was a bit of 2da merging and then visiting the new versions of all the spells to make sure my version had any fixes. That was painful but more my issue than a CPP issue.   I have not hit any cases where base includes changed in a way the effected anything I have (and I have a boat load of custom systems and code).

 

It may also take months to find the other bugs in your systems... believe me there are some '>   There are always bugs.

 

There's a rather large couple of lists of all the things fixed in the patch on the vault pages. You have to follow some of the links to get to them but it's quite a large number of fixes. I don't like all of what it does but to me the benefits of the not unnamed fixes outweighs any costs.  Plus many of the systems can be disabled with module flags (or require enablement with same).

 

Try it out. It's pretty easy to back out, at least on Linux.

               
               

               
            

[Legacy_henesua]

               

KMDS are you claiming that if you compile a module without the patch and then install the patch that a compiled script will alter behavior on the machine with the patch installed?

 

That is false.

 

Includes are only accessed when the script compiles, and pulled into the compiled script when it is compiled. #include is an instruction for the compiler. It is not used at run time. Therefore when you change an include it does not change the compiled scripts until you recompile.

               
               

               
            

[Legacy_Pstemarie]

               

KMDS are you claiming that if you compile a module without the patch and then install the patch that a compiled script will alter behavior on the machine with the patch installed?

 

That is false.

 

Includes are only accessed when the script compiles, and pulled into the compiled script when it is compiled. #include is an instruction for the compiler. It is not used at run time. Therefore when you change an include it does not change the compiled scripts until you recompile.

 

To put it more simply, all of the coding accessed from an include script that is referenced with the #include command is added to the .NCS version of the script (aka the compiled .NSS file).

 

I have added the CPP to several complex combinations of scripting included in my own modules, looking for ways to break something. I have never been able to. Indeed, the only issues with scripting have been updating my modules' custom spell scripts to use the updated spell engine from the CPP. 

               
               

               
            

[Legacy_Shadooow]

               

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.

 

Regardless, since the discussion went into the direction of how can CPP affect module I can provide some addional info on that.

 

First of all, CPP is designed in a way so it doesn't break any custom content. Not after installing and not after recompiling all scripts with includes modified by 1.71. In fact, if you install CPP on your machine and then you open your module in your toolset, every single script should get compiled without any errors. I specifically designed the changes in vanilla includes and new includes from CPP so this will be possible. Everytime I make new release, I make two tests:

1) I try to compile new spellscripts from CPP with vanilla untouched includes

2) I try to compile vanilla spellscripts with includes modified by CPP

In both cases it passes without errors and should work without any issues.

 

Nevertheless, everyone makes errors and so its possible that compiling your scripts with CPP includes throws error or will alter the spell/script functionality somehow. As far as I know the latter haven't happened yet, although I've seen some compile errors already.

 

Also, theoretically it is possible that installing CPP will alter your custom content. Henesua is right, installing CPP will not change your scripts that were already compiled, but there is one rare exception and thats "signal event". IIRC few spellscripts in CPP changes spell ID that is signaled to the creature because that ID was wrong. So theoretically, if you have a creature that has a special handling on when player casts Shield of faith spell on her and you check for the vanilla value that spells fires 421 (Camouflage), since CPP fixed that and now returns 450, your script will not fire if player casts Shield of faith on this creature under CPP installed.

 

But seriously, this is laughable case...

 

There is also exception of this concept with AI. Creature AI is very tricky and every change can have huge impact on gameplay. Obviously it is not possible to rettain vanilla creature behavior while fixing some of the AI issues. Creatures will be smarter and might cast spells in different order, might use spells they didn't and might be much stronger. It was either this or leave all those issues intact which makes no sense to me.

Afterall as I see it: in singleplayer, player has the option to lower difficulty if he finds the encounter too strong, in multiplayer builder can alter the creature and balance her if she went out of controll. And most builders actually don't mind the creatures are smarter (althought players have often different opinion especially when they play years on your server and suddently the creatures are casting spells they never cast...)

 

But generally, if you install CPP and it breaks something then its a bug in CPP and if you report it I will fix it. I don't know how many modules are using CPP, mosts downloads will be from players, but I helped to install CPP on two servers already and while there happened some issues after installing CPP I could count them on fingers of my hand and I provided a fix for these issues to the server admins so it was resolved immediately.

               
               

               
            

[Legacy_Proleric]

               

Testing is not needed. Its a mix fabrication and confusion that was used at the beginning to malign the project because of personal grievances that have nothing to do with the project itself.

I invite you to try that line out on any commercial IT Change Board anywhere in the world. They would falling about laughing before refusing your change request. Change - all change - risks breaking stuff. Period.


I'm open to influence on this - I did, for example, change my mind about CEP 1 Complete, which I now endorse. Why? Because important benefits were identified, that outweighed the risk.


What's missing here is the compelling case for CPP (maybe because it's not been clearly articulated).


If I were persuaded by that, I would still certainly test my stuff with it before endorsing it, because that's how professionals operate. Sorry.


Part of the problem is a misplaced sense of entitlement on the part of the CPP project. When something is made, its creator likes it, but it doesn't follow that potential users ought to like it. We have to be persuaded. The default is not "use every mod that comes along" but "do nothing". To abuse us as having "personal grievances" when we express reasonable doubts about the product is to entirely misunderstand the situation, and harden our resolve to do nothing.

Installing the patch does not "break" a module that you are working on. It changes scripts that you do NOT touch.

That's factually wrong. Not matter-of-opinion wrong, but flat-earth wrong, I completely understand that custom scripts take priority. However, the patch scripts that are not over-ridden change objects and variables, so the outcome of custom scripts that act on those objects and variables is NOT necessarily invariant.

All changed scripts are done in a way to ensure backwards compatibility with other scripts made by you. should you encounter a case where this is not true, it is a bug per the CPP mission and will happily be fixed if you can report on it.

Now that's more positive. It would help to make that disclaimer prominently on the project page.


The elephant in the room, though, is a simple, compelling benefits statement, that would persuade skeptics that the project has sufficient value to be worth the effort.


I've already learned from this thread where to find the patch documentation, but it's hard to see the wood for the trees.


Can no one articulate the top ten must-have fixes that this patch delivers?
               
               

               
            

[Legacy_henesua]

               

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.

               
               

               
            

[Legacy_MerricksDad]

               

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.

               
               

               
            

[Legacy_henesua]

               

Oh if only that was the case. All that you mention has already been done more or less by Shadooow.

               
               

               
            

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

               
               

               
            

[Legacy_Shadooow]

               

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.