50 réponses à ce sujet

[KMdS!]

Hi everyone,

I am thinking about the community expansion pack and am wondering what everyones take on it is as compared to the final 1.69 update? I would be very thank full if you all could fill me in on what it's advantages are....as well as any negatives you may have found. Should I adopt this expansion and why.

 

Thank you all for your time.

[Asymmetric]

I am thinking about the community expansion pack ...

Just to be sure: Do you mean the CEP = Community Expansion Pack or the Community Patch Project by Shadooow?

[MerricksDad]

I like a subset of the CEP, but I dislike using the whole thing. If you are savvy to pulling parts out and using them in your own haks, I greatly suggest it. That leaves room in your 2da files for your other content, as well as de-clutters everything for you on the builder panels. What CEP needs is a shopping guide for content, much like for Sims 1 & 2 clothing and furniture stores. But we're not there yet.

[KMdS!]

sorry, the patch project is what I was referring to...though I agree with MerricksDad about the CEP

[SHOVA]

I don't use either.

The patch, while it has some very needed fixes for NWN, also adds much of Shadooows personal preferences to class and game abilities, which I do not prefer for my games.

 

The CEP has become a bloated nightmare that contains broken and crash causing models.

[Proleric]

Funny... I'm using CEP 2.61 with no problems (bar a couple of trivial workarounds). It's far and away the biggest and best collection of custom content that you can add at a stroke. Just don't use the bits you don't need. Simple.

[SHOVA]

The CEP is not every ones cup of tea. Is it the most used set of haks on multiplayer, however there are, in my opinion, better looking models available. I use Q, as I Simply don't need any of the CEP.

[Drewskie]

The CEP is not every ones cup of tea. Is it the most used set of haks on multiplayer, however there are, in my opinion, better looking models available. I use Q, as I Simply don't need any of the CEP.

This.  Q has pretty much everything of quality that's in the CEP.  Plus a bunch of great content not in the CEP.

[Jedijax]

If you're making a clean install, and don't dabble much into mods, it's a good pick. Unfortunately, at this point in the game, most of us have done extensive changes to NWN that are simply not going to be compatible with the patch. Since it's not modular in its nature, you either take it all or leave it all.

Close

[Grymlorde]

It also overwrites some NWN files, so if you ever wish to remove it you have to wipe out NWN and do a fresh install. Personally I am very uncomfortable with overwriting any of NWN's files.

[Gruftlord]

I see there are still some misconceptions floating around about CPP.

 

@ Grymlorde: As the installer will let you know, it makes a backup of the one file it overwrites. If you want to disable CPP, just swap the two and you are set. aferwards you could savely delet every file from the CPP.

 

@Jedijax: Care to elaborate, what specifically you have issues with? AFAIK, if you use custom content that isn't built with CPP in mind, all that will hppen is that some of CPP's fixes will not work, but you get the custom content you created. If you did experience anything else, it might be best to let Shadoow know. 

[Jedijax]

As I said before, other hack packs and custom resources have already been added/used/implemented by builders. Say, for example, the merging of .2da tables, modification of added resources, game-wide conversation trees, access points to scripts etc. Many custom modules have their own resources already in place, and in order to work with other custom packages, some/a lot of work is needed on the user's side, provided the have the know how. That, aside of any personal modifications you may have done per module or globally. I use a set of custom packs that are specifically set to work in every module I still play. Finally, since the patch isn't modular, due to the way things work in NWN or the author's choice, you can't exactly choose what you want to implement and what you don't want, as you would between separate content releases, or other projects, unless you know exactly what resources affect what you like and maybe know how to merge/modify them to your needs. If you've modded other games you have an idea of how modular vs "whole" releases work.

Close

[Gruftlord]

Still i don't see why you think the cpp might break your custom content, even if you don't merge the 2das or the like. You simply don't get all the cpp fixes, but you to keep all your custom stuff, and it should be working correctly. Just to be clear: When you say not compatible, them this is what you are referring to, right?

[Proleric]

Scripts and other assets are tightly coupled in NWN, operating on the same system components, so if CPP modifies script A and I modify script B, there is no way to guarantee how the module will behave without testing it.

I'm not aware of a compelling reason to install CPP, so I take the view that if it ain't bust, don't fix it.

[henesua]

CPP doesn't break anything. Thats just the same old hogwash that people have been saying about the project since the beginning.

 

The CPP is full of fixes that would otherwise bloat your module, but as a patch to the game itself keeps it lean and reduces your workload. Its scripting framework changes are nifty as well opening up functionality you didn't have before.

 

Installing the CPP is a no brainer. There is very little if any downside at all. And it is full of fixes. The WOK fixes are also very useful.

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

[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?

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

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

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

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

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

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

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

[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?