923 réponses à ce sujet

[virusman]

Add me in the IM you're using and just ask whenever you need something. We can discuss security/distribution issues there as well.

[MannyJabrielle]

This is definitely a case where the builder should add the patch1.71 hak into module properties as he actually relies on that content. Playing such module without CPP will result into incomplete experiences. But it wont crash game, that I know for sure.

 

Ok, so for a point on clarity... builders who like to *play* with the CPP, but don't want their module to require it, should be sure to build *without* the CPP installed to ensure no CPP specific tweaks/contents get included into their module?

When I do get to writing up the documentation, I am thinking now it may be a good idea to have a "builder's section" that gives some cursory notice about how building/playing with the CPP installed may affected their module if they're intending a non-CPP finished product.

 

 

In this situation, all that actually manifest are client side graphical fixes and improvements, almost everything else is controlled by a server with a few exceptions:

- player will be able to take epic spells with the CPP manner (17lvl caster/18sorc).

- player will see Shou Disciple and Eye of Gruumsh in a class list when levelling up. I am not sure whether they will be selectable if conditions will be met, probably yes, but if player chooses any of the two, server will not allow to complete levelling up and player will have to redo levelling

- some NWNCX features such as possibility to select non standard base class and possibility to put counterspell into quickslot will be possible, other features are again controlled by server

A clarification on the casters and epic spells...  will a 17th level character (pure caster class) taking epic spells cause the same failure to level up as it does with characters taking the PrCs?

NWNCX will definitely be the next topic I'll be asking about (not any time soon though).  I have used nwncx, but only a few times, I'm not familiar with everything it does/can do in general, so I'll wait to ask whatever questions I may have until I have questions that won't be absolutely noobish
 

 

Player cannot interfere with server files - it doesnt matter what player got in override/haks/anywhere, all that player is able to modify is a visual appearance. You can make all creatures looks like chickens but only you will see this. And so on. So, safety speaking there are no issues.

 

That answers a lot of my questions right there Thanks.  Looking back through this thread I see that has been said before, but I missed it.  It clarifies a lot of the things about the patch I wasn't too sure about.

 

 

Well, they would still needed it. I mean, by incorporating the patch171.hak files into your own haks, you will be able to use the hidden appearances or new baseitems (stackable miscs) without risking that player without CPP wont see them. But the hak still doesnt contain classes.2da and itemproperty 2das that are handling those two problematic features that player without CPP wont see. You would have to put those 2das into your haks as well (which is minor licence/permission abuse but I dont care). Same for adjustable traps or swinging blade traps - wont work unless you add also scripts for them into your haks/module (again a licensed)

As a builder... that point on the license caught my attention, at least 2da wise.... Yes, you did say it was a minor issue you didn't care about, but to keep thinks simple, I might actually suggest making the license clear about 2da's and not covering them.  It made me think of how if I were to want the module I'm working on to be a CPP module, I would *have* to merge the 2da's as I have a custom class of my own in my module, and made some minor edits to default classes (name changes mostly, non FR setting, no champions of "Torm").... Yeah, you said you don't particularly mind, and it's a minor issue, but still something to keep in mind for builders who are mindful of abiding by a license agreement

[Shadooow]

 

Ok, so for a point on clarity... builders who like to *play* with the CPP, but don't want their module to require it, should be sure to build *without* the CPP installed to ensure no CPP specific tweaks/contents get included into their module?

Hmm. Should he? It might be a little inconvinient to switch patch in and out. Imo better to learn what the new features are and dont use them or playtest it without CPP prior to release. Most of the times the missing content wont be a gamebreaker.

 

A clarification on the casters and epic spells...  will a 17th level character (pure caster class) taking epic spells cause the same failure to level up as it does with characters taking the PrCs?

It should but it wont...

 

 

As a builder... that point on the license caught my attention, at least 2da wise.... Yes, you did say it was a minor issue you didn't care about, but to keep thinks simple, I might actually suggest making the license clear about 2da's and not covering them.  It made me think of how if I were to want the module I'm working on to be a CPP module, I would *have* to merge the 2da's as I have a custom class of my own in my module, and made some minor edits to default classes (name changes mostly, non FR setting, no champions of "Torm").... Yeah, you said you don't particularly mind, and it's a minor issue, but still something to keep in mind for builders who are mindful of abiding by a license agreement

Hmm Im not sure you undestood the licence. What is not allowed is to taking CPP content and adding it to your module without any actual modification only in order to get CPP features without need to use CPP itself. As long as you take the content and modify its perfectly fine. The intent is that if you are building a module with CPP and you want CPP features you should either force players to use CPP or leave it on their own responsibility. The only abuse of the licence comes in play if you add for example all the 1.71 spell, feat, trap etc. scripts and perhaps also all 2DAs without any modification to ensure the player gets these features while playing your module even if he doesnt have CPP installed.

[Gruftlord]

Shadooow/Henesua: i'll try to write a few lines during the weekend about the patch content. i suggested before, that the differenciation between client side, server side and builder activatable fixes would be something that deserves clarification in the patch description and would help people understand the inner workings and the "controversy" part of the CPP much more (specifically why some things about the controversy are due to misinformation/miscommunication).

 

Shadooow, i know CPP is basically your project, and you most all credit for it (and as the recent discussion has shown, your NWNX/NWNCX fixes and knowledge are reasons to think highly of you by now alone, on top of the project as a whole). BUT, this is and was always meant to be a community project. yes, few people wanted to contribute, yes, even fewer did and also yes, many still try to steer away from it (and i have the impression those numbers have dropped with time and revisions of CPP, it is showing it's benefits for the cummuity after all).

But despite this, and in my oppinion actually especially because of this, i would drop the licencing stuff. just make CPP open source, allow people to rip it apart and use whatever they like. you know, those people open to use the CPP do use it by now (about 100 people). losening the restictions will only widen the audience for the CPP.

yes, in some cases, it won't lead to people using the cpp but people using PW haks that contain the or part of the fixes. so what? it just means you got one more builder on CPPs side, that (while maybe not using all of CPPs content) does make use and in some way supports the fixes that have been collected for and in CPP. it will get more people to consider CPP, if only (initially) to rip out some parts of it. it will get people involved in and look into the CPP; and who knows, some may decide they DO like the whole package after all. especially since updates are continuing, some may then decide it is better for them to just use the latest version of CPP, and no longer bother with ripping things out of it. Also, builder support will get regular player to download and use it as a whole package as well.

in the end, what i'm trying to say is: lower the barrier to get people involved with and look at the CPP, and you may convice more people of the projects qualities, which in return will get more people to enjoy the CPP fixes (be it all or just part of them).

 

these are my thoughts on the topic, that's what i see in a cummunity project. these are mere suggestions, but maybe you can think about it.

[Bogdanov89]

ShadoOow, i have the latest 1.71 CPP (installer version) and the latest "Patch 1.71 Add-on" - but i have not yet installed the NWNX_Patch and NWNCX_Patch.

 

Where can i get the latest NWNX_Patch and NWNCX_Patch from, and how to make it work properly with the 1.71 CPP and it's latest Add-ons?

 

Also do i need to do anything special to make it all work when i am hosting online through the nwn game (playing original campaigns with my brother)?

 

Thanks for helping out

 

edit: i also got a bit confused when i downloaded the 1.71 Add-ons from the Neverwinter Vault website, because there are two different versions linked:

 

"patch171_addonv2_0" and "patch171_addonv3"

 

One of them is on "http://neverwinterva...y-patch-project" while the other is on "http://neverwinterva...s/patch-171-add" .

 

I guess that one of those webpages still has the old addon file instead of the newest one?

[Shadooow]

 

Shadooow/Henesua: i'll try to write a few lines during the weekend about the patch content. i suggested before, that the differenciation between client side, server side and builder activatable fixes would be something that deserves clarification in the patch description and would help people understand the inner workings and the "controversy" part of the CPP much more (specifically why some things about the controversy are due to misinformation/miscommunication).

That would be perfect. Even better would be if you get an access to the editing that descriptions on new vault, but this feature is not  there yet. Wiki-style editing fits this project imo.

 

 

Shadooow, i know CPP is basically your project, and you most all credit for it (and as the recent discussion has shown, your NWNX/NWNCX fixes and knowledge are reasons to think highly of you by now alone, on top of the project as a whole). BUT, this is and was always meant to be a community project. yes, few people wanted to contribute, yes, even fewer did and also yes, many still try to steer away from it (and i have the impression those numbers have dropped with time and revisions of CPP, it is showing it's benefits for the cummuity after all).

But despite this, and in my oppinion actually especially because of this, i would drop the licencing stuff. just make CPP open source, allow people to rip it apart and use whatever they like. you know, those people open to use the CPP do use it by now (about 100 people). losening the restictions will only widen the audience for the CPP.

yes, in some cases, it won't lead to people using the cpp but people using PW haks that contain the or part of the fixes. so what? it just means you got one more builder on CPPs side, that (while maybe not using all of CPPs content) does make use and in some way supports the fixes that have been collected for and in CPP. it will get more people to consider CPP, if only (initially) to rip out some parts of it. it will get people involved in and look into the CPP; and who knows, some may decide they DO like the whole package after all. especially since updates are continuing, some may then decide it is better for them to just use the latest version of CPP, and no longer bother with ripping things out of it. Also, builder support will get regular player to download and use it as a whole package as well.

in the end, what i'm trying to say is: lower the barrier to get people involved with and look at the CPP, and you may convice more people of the projects qualities, which in return will get more people to enjoy the CPP fixes (be it all or just part of them).

 

these are my thoughts on the topic, that's what i see in a cummunity project. these are mere suggestions, but maybe you can think about it.

Hmm you got a strong argument there, I must agree with what you said, though I still don't like it and don't want to do that. But ok. Gather 5more likes, or start a poll and if other peoples has a same opinion (which I think they have but I want to hear it), then I will remove the "licence" and edit permissions.

 

ShadoOow, i have the latest 1.71 CPP (installer version) and the latest "Patch 1.71 Add-on" - but i have not yet installed the NWNX_Patch and NWNCX_Patch.

 

Where can i get the latest NWNX_Patch and NWNCX_Patch from, and how to make it work properly with the 1.71 CPP and it's latest Add-ons?

 

Also do i need to do anything special to make it all work when i am hosting online through the nwn game (playing original campaigns with my brother)?

 

Thanks for helping out

 

edit: i also got a bit confused when i downloaded the 1.71 Add-ons from the Neverwinter Vault website, because there are two different versions linked:

 

"patch171_addonv2_0" and "patch171_addonv3"

 

One of them is on "http://neverwinterva...y-patch-project" while the other is on "http://neverwinterva...s/patch-171-add" .

 

I guess that one of those webpages still has the old addon file instead of the newest one?

You dont need to download it standalone, NWNX_Patch plugins are included in the 1.71 addon, you just need NWNX/NWNCX main package to use it. Read here.

No there are no extra steps to get it work other than executing NWNCX.exe to start a game and your brother neither anyone else dont need this - it will work because you are hosting and act like a server.
 

Seems I forgot to update links, the v3 is what you want of course. EDIT: link updated and corrected.

[MannyJabrielle]

I'll have to read over the license myself to see exactly what it says before I could say either way...  I'm fine with it however it is as long as builders can reasonably build their modules AND proper credit for CPP work is given where credit is rightly due.

[Pstemarie]

Liking Grufflord's comments about licensing simply for the fact that the Community is getting much smaller and I'll all about open source these days. 

[Shadooow]

Hm, I forgot I rewrote the licence/permission before I released 1.71.

 

Please do not repackage or redistribute patch content without permission. For any permission issue, treat the Community Patch content as it would be created by Bioware - you would not ripped files from Patch 1.69 to be used with patch 1.68 so please do not rip files from CP to be used without CP. Distributing a patch content for building purposes is allowed, but should be redundant because all 2DAs, spell scripts and include scripts are available for download on this page. Do not post all spell scripts from CP within your project if you only changed spellhook etc. - of course if you modified all spell scripts you are allowed to distribute them.

Only if you or specifically those large CC compilations comply with these rules only then it could be the true patch. So please respect this, you wouldn't do it with any official patch in past and just because this patch doesn't force you to upgrade is not a reason to do it.

(That last sentence sound awful but I dont know how to write it grammary correct so I kept it )

 

This is the only restriction that I feel neccessary. And now I have a question. Is the project itself not open because of this? I didn't checked the "Open - Free & open only if project also open" because I wasn't sure. To allow conversion to other games could be allowed - I thought its nonsense but I guess someone might try to use my spell engine in NWN2 which I don't mind at all. And what "Allow distribute in others work" means is also uknown to me therefore I haven't checked it. Again, including any content from CPP that you modified (and thus need to include it in your work) is absolutely fine with me.

[Bannor Bloodfist]

Hm, I forgot I rewrote the licence/permission before I released 1.71.

(That last sentence sound awful but I dont know how to write it grammary correct so I kept it )

 

This is the only restriction that I feel neccessary. And now I have a question. Is the project itself not open because of this? I didn't checked the "Open - Free & open only if project also open" because I wasn't sure. To allow conversion to other games could be allowed - I thought its nonsense but I guess someone might try to use my spell engine in NWN2 which I don't mind at all. And what "Allow distribute in others work" means is also uknown to me therefore I haven't checked it. Again, including any content from CPP that you modified (and thus need to include it in your work) is absolutely fine with me.

 

Actually, the way you have all of that worded, no one could use any part of your stuff at all, unless they installed the entire package.  It is an either/or type of thing, if you allow part to be used for some other purpose, then you in effect allow all parts to be used or not for any purpose.

 

You would be better off just adding a line that states "Contact me if you have a specific need for a specific piece of this patch, and we can discuss it."

 

Otherwise you are making it much too confusing.

 

Open and Free means no restrictions at all.  Meaning you would allow someone to take any part of your patch and do what they want, including adding that piece to their own release.  So, currently, your patch does NOT qualify in anyway as open and free.

[MannyJabrielle]

That either/or aspect is a dilemma for me as a builder, especially given how comprehensive the CPP is with what it changes/tweaks/ect.  It is not easy to understand all those changes/tweaks without studying them closely.  And as a builder, I may want to include some highly visible features such as the PrCs, how epic magic is tweaked, tweaks the spells, or the changes to traps ect... BUT... I don't want to lock potential players for my module to have to install the CPP.

 

The same could apply to say, Project Q or CEP or other such large packages, if I want to use the content from those packages, my players will have to download them as well, BUT, those packages are almost all graphical in nature and must be intentionally added to the module to take effect.

 

If I am understanding how the CPP works, it's the opposite, it's gameplay (not visual) changes that affect the OCs and all the single-player modules I have unless the module's contents override the CPP content by including it's own 2DAs or spellscripts, ect to revert to non-CPP functionality.  That all-or-nothing aspect may be a discouragement to players who don't have the technical knowledge to understand all the changes and don't want to have to run the CPP installer or critical rebuild just to enjoy one given module out of their collection.

 

That's a big reason of why I am helping with the documentation... to present information that the average player can read and understand without needing any technical modding and/or scripting knowledge.  And even with a "CPP For Dummies" style documentation... it will *still* be a very comprehensive body of information to process because of just how massive the project is.

I am wondering if a more 'modular' approach may be a good development for the CPP future.  Take for example NWNCQ and ProjectQ.... Chico's override version of CQ had the option to disable certain tilesets, and then I think it was Hensua who uploaded a modular hak version of CQ (chico's hak version was an all or nothing deal BUT it was a hak that had to be intentionally added to a specific module).... the player and builder could both choose what parts they wanted or didn't want.  With ProjectQ, there is also a bit of modular functionality as almost all the separate haks in the project are stand-alones (you can attach the creatures hak without having to attach the placeables hak for example).  We have to download the packages as a whole, but it's left to the player and/or builder's discretion as to if they use the entire package or not.

 

As I'm understanding it, it would be incredibly difficult to split the CPP into a similarly modular project because of how it works and HAS to be implemented, but giving some modular options may be something to think about... it may be very good for the CPP's popularity in the long term.

 

The CPP uses a number of switches the player can set on or off.... But something I noticed when I did an OC play-through recently.... I had to reset the switch on each chapter.  It has me thinking now.... would it be possible to redo the CPP all major systems/changes/tweaks as switches the player can set one time for their single-player modules?

Example... install this hypothetical CPP with everything set via switches... At install, I can set what defaults I want for my SP modules.  If I want the custom classes, but not any change to magic spells, I can choose.  If I then play a CPP built module where the builder decided to set a given switch differently from my defaults, the switch they choose for their module would take precedence.  I still have to download the entire CPP package, BUT, I have more choices in what aspects I want for my SP modules, and it would allow builders to select their own choices for their modules.

I know it would be incredibly difficult to change the implentation of the CPP to do this, and may not necessarily even be possible with certain changes/tweaks, but it would give more power of choice to the player.

[Gruftlord]

some thoughts on that: i'm against a modular CPP, since all this modularity of the projects we have seen in the past are aimed mostly at builders, but give players very little chance to add something for themselves, without knowledge of the toolset, or cluttering the override folder with thousands of files. this has become better in recent years, with override compilations, increasing popularity of patch haks (and information about how to do them) and projects like this CPP. Im mostly a player and i appreciate that shift very much.

 

however, i like the idea to make the switchable CPP content more prominent and visible. might it be possible to hook an CPP ini file to the nwncx plugins, and allow users to enable and disable certain features there? for starters, let all things currently switchable by the player widget be defined globally in an ini. allow a separate option to either override module/builder chosen options or not, and allow the widget to change the settings for the current save game only.

 

then maybe later, this can be expanded to a full scale switch system, where more contents may be switchable, than currently possible.

i think i'd like that option more. not chosing what to install, keep all install base the same. but allow features to be turned off and on much more easily and much more prominently than currently.

 

in short: i think i prefer the cpp to be kept as a whole (it's easier and less confusing for the regular player), but maybe have easier access and persistance of chosen switches. as for builders, that only want to incorporate certain features, i stand by my point of losing the redistribution restrictions. that should hopefully cover their needs, without clustering the CPP too much.

[Shadooow]

I am wondering if a more 'modular' approach may be a good development for the CPP future.  Take for example NWNCQ and ProjectQ.... Chico's override version of CQ had the option to disable certain tilesets, and then I think it was Hensua who uploaded a modular hak version of CQ (chico's hak version was an all or nothing deal BUT it was a hak that had to be intentionally added to a specific module).... the player and builder could both choose what parts they wanted or didn't want.  With ProjectQ, there is also a bit of modular functionality as almost all the separate haks in the project are stand-alones (you can attach the creatures hak without having to attach the placeables hak for example).  We have to download the packages as a whole, but it's left to the player and/or builder's discretion as to if they use the entire package or not.

I am strongly opposed to this as then it wouldn't be a patch but a collection of fixes. Community patches are common and they are all "all in one" packages imitating an official patches which are the same. I still don't understand why would player want to install every single fix separately the way its done in BG2 in Weidu. Nice concept but it totally ruined my gameplay experience and forced me to stop playing that game. Because I was changing the each mod options all the time instead of actually playing the game, all because the mods themselves weren't playing alone with others and because there was often 5choices I could take and some choices was dependant on others or not working when other choice was applied, real mess. Also from this reasons, CPP is providing coherent selection of fixes and features that are working together and are designed to keep the standard gaming experience intact as much as possible.

 

But really, make it modular and its no longer a patch and I can cancel this project. Too late for that anyway, it seems to me that players are those who has least issues with the project scope/decisions/choices/whatever. And builders are free to change any part of the patch afterwards.

 

 

 

 

The CPP uses a number of switches the player can set on or off.... But something I noticed when I did an OC play-through recently.... I had to reset the switch on each chapter.  It has me thinking now.... would it be possible to redo the CPP all major systems/changes/tweaks as switches the player can set one time for their single-player modules?

Example... install this hypothetical CPP with everything set via switches... At install, I can set what defaults I want for my SP modules.  If I want the custom classes, but not any change to magic spells, I can choose.  If I then play a CPP built module where the builder decided to set a given switch differently from my defaults, the switch they choose for their module would take precedence.  I still have to download the entire CPP package, BUT, I have more choices in what aspects I want for my SP modules, and it would allow builders to select their own choices for their modules.

I know it would be incredibly difficult to change the implentation of the CPP to do this, and may not necessarily even be possible with certain changes/tweaks, but it would give more power of choice to the player.

Hmm interesting, I didn't realized this. This is obvious though as each campaign is a new module. And I used a HotU module switch system which simply works this way.

 

But your idea with a player selection applied for every module is very good. Due to the number of switches, this is quite reasonable though I havent expected that someone would enabled more than two at once. I can see this doable via database, but I don't see that possible within CPP installation, mainly because I am not author of the installer and the support I have for this product is a bit limited by the creators time frame. It might be possible to make a 3rd party tool to modify this settings before playing game, however I don't really have a resources and knowledge to make it myself.

 

Also keep in mind that the PC Widget tool currently allows to change the module switches too as its player responsibility how would he play the module. So if the module that player opens will have some switch set to different value, how will he find this out? I can't see a way how to notify him that the module switch overrided his choice, and would you even want to allow him to do that?

[Shadooow]

however, i like the idea to make the switchable CPP content more prominent and visible. might it be possible to hook an CPP ini file to the nwncx plugins, and allow users to enable and disable certain features there. for starters, let all things currently switchable by the player widget be defined globally in an ini. allow a separate option to either override module/builder chosen options or not, and allow the widget to change the settings for the current save game only.

 

then maybe later, this can be expanded to a full scale switch system, where more contents may be switchable, than currently possible.

i think i'd like that option more. not chosing what to install, keep all install base the same. but allow features to be turned off and on much more easily and much more prominently than currently.

INI wont work. Vanilla NWN doesn't allow to read/write into INI from NWScript - this is doable with NWNX but this is, and must be, optional to use so this is a no go.

2DA has similar limitation, you can read it but not write it so the only way to do that is database which player has no access. The only way is therefore a 3rd party tool that I am not able to provide.

 

Anyway, what I am very curious about is what features/changes would player want to disable (since they are enabled by default except the switches). I understand why builders doesn't like fixes such as Circle Kick fix, but why would player want to disable it?

[Pstemarie]

As a Builder I really like the CPP. The nonscript-related resources are solid (e.g. tile fixes) and the script engine is easy enough to override if needed because it sits below all other resources - override, hak, and module. The script base is also pretty easy to understand once you dive into it - although I'm not overly found of the NWNX stuff, but that's only because I have NO clue how to use that or modify it to suit my needs. Therefore, I'd rather not have to mess with it - which, with CPP installed, I don't really HAVE to because ShaDoOw already set it up.

[Gruftlord]

INI wont work. Vanilla NWN doesn't allow to read/write into INI from NWScript - this is doable with NWNX but this is, and must be, optional to use so this is a no go.

2DA has similar limitation, you can read it but not write it so the only way to do that is database which player has no access. The only way is therefore a 3rd party tool that I am not able to provide.

 

Anyway, what I am very curious about is what features/changes would player want to disable (since they are enabled by default except the switches). I understand why builders doesn't like fixes such as Circle Kick fix, but why would player want to disable it?

 

why is it a no go? you could have an ini, that is read by NWN(C?)X. players can modify it with note pad. if players do not use/modify it, or do not use NWN©X, then simply the standard settings are loaded. if within the module the widget is used, then the settings will be overwritten (so order of strength is: widget > module/builder setting > ini). then allow a separate ini line to make that widget > ini > module/builder settings.

if it is possible to make the ini system disable/ignore itself, as long as no NWN©X and ini are used, then i can only see this as a benefit. anyway, yes, i agree, it should be optional. but i see no reason why it has to be writable from ingame. i can do this outside of the game, the same way i change many other ini settings.

i personally have not looked too deep into which options are switchable and which are not yet, so i couldn't tell you which i would or would not disable and why. certainly Circle kick fix sounds like something few people would want to disable. but maybe a builder will want to for whatever reason, and having an ini that lets me easily override his choice is something i do indeed want to have :-D

[Shadooow]

What it would be good for if it wouldnt work without running NWN via NWNCX?

 

It is doable without NWNCX just with the drawback of not beiing able to change it outside of game. Imo this drawback is lesser than the INI drawback.

 

Why it has to be writeable? Because all of this is about keeping the selection you make while you are in game, thus if you havent set the options into INI and then you do this ingame, the selection would needed to be written into INI so it applies for next module you will play.

 

Still no idea how to inform player that module overwritten his selection. At this moment, this is not a prolem because you have to set all the options you want again for each module via PC Widget Tool. And when doing that - you will see that the given switch is enabled already. But if I make it global then it will become a problem because - damn scrap it. I forget on one important thing.

 

These options are disabled by default and builder has no way to find out whether they are enabled (because at this moment they arent) and how to disable them if player enabled them. Builder is only enabling them, not disabling - because they are normall disabled. So there will be a problem if I enable the global player settings. That would force builder to think about each option and forced him to disable those that he dont want (not to mention that builder wont be able to do that without this additional change which is not incorporated in "official" 1.71 release).

 

Also speaking of NWNCX (which the Circle Kick feature is from) even if I would allow disable any of its features - which I dont see a reason from a client version, builder wouldnt be able to control the player settings - which is another INI disadvantage. Builder has his own INI and player his own there is no way around. I dont really think that is sane to disable these features, I know there are PW admins that do not wish to incorporate NWNX_Patch because they dont want to improve the circle kick but I dont really think its rational.

EDIT: just for clarification, I am talking about NWNCX, ie. the client version of NWNX and a single player module builder. Server uses NWNX_Patch where I do plan to allow disabling any feature.

Modifié par Shadooow, 03 juillet 2014 - 03:14 .

[MannyJabrielle]

some thoughts on that: i'm against a modular CPP, since all this modularity of the projects we have seen in the past are aimed mostly at builders, but give players very little chance to add something for themselves, without knowledge of the toolset, or cluttering the override folder with thousands of files. this has become better in recent years, with override compilations, increasing popularity of patch haks (and information about how to do them) and projects like this CPP. Im mostly a player and i appreciate that shift very much.

 

however, i like the idea to make the switchable CPP content more prominent and visible. might it be possible to hook an CPP ini file to the nwncx plugins, and allow users to enable and disable certain features there. for starters, let all things currently switchable by the player widget be defined globally in an ini. allow a separate option to either override module/builder chosen options or not, and allow the widget to change the settings for the current save game only.

 

then maybe later, this can be expanded to a full scale switch system, where more contents may be switchable, than currently possible.

i think i'd like that option more. not chosing what to install, keep all install base the same. but allow features to be turned off and on much more easily and much more prominently than currently.

 

in short: i think i prefer the cpp to be kept as a whole (it's easier and less confusing for the regular player), but maybe have easier access and persistance of chosen switches. as for builders, that only want to incorporate certain features, i stand by my point of losing the redistribution restrictions. that should hopefully cover their needs, without clustering the CPP too much.

 

That's what I was trying to get at by suggesting modularity.... not make the package an actual collection of modular packets to clutter up the override or have a gabillion different things to install, but have a wider ranger of switches allowing greater amount of choice for the players.  The entire CPP would still have to be downloaded and installed as one package, but the player could turn off whatever parts they don't want for whatever reason and not be precluded from the other CPP content they DO want.

 

 

I am strongly opposed to this as then it would be a patch but a collection of fixes. Community patches are common and they are all "all in one" packages imitating an official patches which are the same. I still don't understand why would player want to install every single fix separately the way its done in BG2 in Weidu.

Not all.  Granted most are all-or-nothing packages, but they are almost all a convenience package of fixes that ARE available separately.  A few community patches made package specific tweaks for when two particular fixes required a little tweaking, but it was still an option up to the player who could obtain the individual fixes separately.

 

As I'm reading the CPP license right now and given your wish that specific parts of the CPP not be available apart from the entire package, the project name of *community" patch is I think perhaps a bit misleading if you want it to be presented rather as an individual proprietary project.  And I'm not saying there's anything wrong with that.  I do think you deserve the same credit and creative control over your work as a CC maker who puts out new creature models or tilesets or such, and I wouldn't ever want to see anyone deny you that.  I'm only saying perhaps that less "all or nothing" and more end user choice would be a good thing, especially given HOW the the project affects the game as whole and the general expectations of a 'community' project over a individual propiety project.

 

NWN is also *very* different from many other games.  The elder scroll games for example... Morrowind and Oblivion both have 'unofficial patches", but those games are essentially one single module/adventure and the changes the patches do are often available as individual packages. NWN isn't just the OC/SOU/HOTU modules, but dozens if not hundreds of player modules and PWs with a massive variety of rule implementations.  the NWN community patch really cannot be compared to community patches from other fundamentally different game clients/implementations.

 

I like the patch a lot, and I do tell other players I know about it and try to get them interested in it.  I wouldn't be in this thread if I didn't like the project  I think more end user control over what they are installing into their game would get more players to download it and keep it installed/updated.

 

 

Because I was changing the each mod options all the time instead of actually playing the game, all because the mods themselves weren't playing alone with others and because there was often 5choices I could take and some choices was dependant on others or not working when other choice was applied, real mess. Also from this reasons, CPP is providing coherent selection of fixes and features that are working together and are designed to keep the standard gaming experience intact as much as possible.

 

But really, make it modular and its no longer a patch and I can cancel this project. Too late for that anyway, it seems to me that players are those who has least issues with the project scope/decisions/choices/whatever. And builders are free to change any part of the patch afterwards.

 

From the players I've talked to about the patch, they are interested in given aspects, but not all-or-nothing aspect or how it would affect *every* module they played.

For better or worse, the patch DOES change ALL modules the player has, not just ones where the builders set whatever switches... and to set those switches in the first place, the player has to have the CPP installed, which affects, however directly or indirectly, modules that specific builder does NOT set switches on.

 

And I can completely understand your frustration with mods that require constant changing of options/tweaking, and yes, the CPP as a whole is intended as a single simple application of multiple options/mods/fixes... but I simply think it should be up to the end users when all is said and done.  With the license and how you don't want individual parts of the CPP distributed outside of the CPP as a whole (which is totally your right, don't get me wrong on that)... the end user does not have a choice.  And this original point of the discussion was about how "open" the project was, and if specific parts could/should be open for use without taking the entire package as a whole.

 

Hmm interesting, I didn't realized this. This is obvious though as each campaign is a new module. And I used a HotU module switch system which simply works this way.

Yes, but you and I know how and why NWN works they way it does with switches.  Not every player mods like us.  It's not necessarily obvious to a player who sees the OC's as 'one package' and would expect a setting they applied at the start would apply through the entire package even though it is reality a series of several separate packages strung together by a script command at the end of each consecutive package in the series.  Sort of like how one doesn't have to set shadow/skybox/environmental mapping options every chapter.  I completely understand WHY the CPP switches are different, but perhaps a method which only requires setting a switch once would be a good improvement overall.

 

 

But your idea with a player selection applied for every module is very good. Due to the number of switches, this is quite reasonable though I havent expected that someone would enabled more than two at once.

Wizard/Monk/PM  I set the unlimited summons, glove spell boosts, polymorphing merge options, as well as the SR on AoE switches.  That's one of the things I love about the CPP, it already does have a good number of gameplay options I have control over as a player even more would rock

 

 

 I can see this doable via database, but I don't see that possible within CPP installation, mainly because I am not author of the installer and the support I have for this product is a bit limited by the creators time frame. It might be possible to make a 3rd party tool to modify this settings before playing game, however I don't really have a resources and knowledge to make it myself.

 

No promises, but I may be able to help with that.  I need to become more familiar with the inner workings of the CPP as a whole first.  And I still got the documentation to write up for you  You mentioned that the installer was made by somebody else?  The most simple method I can think of for allowing a player to set their switch choices once and be done with it would be with the installer being able to edit which ever files required prior to actually installing them into the game.

 

Also keep in mind that the PC Widget tool currently allows to change the module switches too as its player responsibility how would he play the module. So if the module that player opens will have some switch set to different value, how will he find this out? I can't see a way how to notify him that the module switch overrided his choice, and would you even want to allow him to do that?

 

Good question.  Perhaps it would be like any other in-game system like death/respawning, resting, ect?  the builder could make the settings known at the start of the module or in a journal entry, or not, and the player finds out on their own?  Same with if the player can override or not.... builder could decide. If he doesn't want unlimited resting and no unlimited summons (or no summons at all), he can make those decisions.

 

It's not unheard of for a builder to make specific game-changing modifications to his or her module... Like say, evasion not working in leather armor as per PnP rules (the guy who made that mod deserves many dragon-hordes worth of treasure ).

 

 

 

Anyway, what I am very curious about is what features/changes would player want to disable (since they are enabled by default except the switches). I understand why builders doesn't like fixes such as Circle Kick fix, but why would player want to disable it?

 

Same reason as the builder.  Some players may prefer wand-crafting to make wands with 50 charges as the default.  Other players may prefer random number of charges. Some players may want the CPP so they can correctly play a specific CPP built module or PW without any issues, but not want all or any CPP changes for another non CPP module.

The builder can attach the CPP haks to their module and make the CPP a requirement, but as I said earlier.... installing the CPP affects more than just that one specific module with one specific change.  That's why it's so fundamentally different than any other project.  It changes all modules with a massive variety of changes.

If I install a GUI mod, that changes all modules as well, however, I can download a package like say, TAD's transparent gui overhaul and I am free to install only the colored icons not the entire package. There is no license saying one has to use the entire package or none of it at all.

[henesua]

Shadooow/Henesua: i'll try to write a few lines during the weekend about the patch content. i suggested before, that the differenciation between client side, server side and builder activatable fixes would be something that deserves clarification in the patch description and would help people understand the inner workings and the "controversy" part of the CPP much more (specifically why some things about the controversy are due to misinformation/miscommunication).

 

While I use the Community Patch I haven't contributed to it, so I am unclear why I am being included here.

 

As far as other stuff raised in thread:

I agree that the patch is well applied as a monolithic package to an NWN install. If its in pieces - a collection of fixes - its more something that you inject into a module rather than into NWN's Data. I like that this modifies NWN's Data in one cohesive piece and that I can edit a module to override specific changes when I want. There is very little in the patch that is problematic from my perspective, and when looking at criticisms of it I've often found the arguments against it entirely overblown - more emotional than rational. So all that to say… all in one for a package like this is a boon.

 

As far as going fully open as suggested above. I think that would be a good way for this project to go. But it probably shouldn't until others step up to help developing it. I obviously think this way because I think putting the whole project in open sourced version control (like Git or something) would be good for its long term viability. BUT given how small the community is , and ShaDoOoW's dedication to keep it going… maybe its fine to remain his baby for now just so long as it keeps him interested and excited about it. Anyway those are the two sides to it that I see: (1) right now ShaDoOoW seems quite motivated to maintain this project and he does a ton of good work. (2) when fully open source there is the potential that more people will get involved and push it toward community owned and operated.

 

While I like community owned and operated as an ideal, I think the transition to such a state needs to be realistic and result in a better outcome than the current state of affairs. And when I think about that, I think ShaDoOoW is doing a good job and am not excited about rocking the boat.

[Gruftlord]

I thought that new description will be interesting to you because i hope to clarify a few of the things you addressed in your questions in the post before mine.

[henesua]

sounds good, Gruftlord. Thanks.

[MannyJabrielle]

As a Builder I really like the CPP. The nonscript-related resources are solid (e.g. tile fixes) and the script engine is easy enough to override if needed because it sits below all other resources - override, hak, and module.

 

Yes, it's very easy as a builder to override.  That's not my issue with the license or implementation of the patch though.

My issue is, to override the scripts in the first place the CPP has to be installed on the end user's client, and being installed on the end user's client means the CPP will be affecting, for better or worse, every other module in their collection, not just the one I build for them and choose to override XYor Z setting with my own scripts/switches.

 

As a builder, that is pushing me towards NOT using the patch.  I have no issue with making any given bit of custom content a requirement for MY work, but I won't use a given bit of CC as a requirement for my module if it will affect modules by other builders, no matter how great or rational it would be for the player to have.

[Shadooow]

As far as going fully open as suggested above. I think that would be a good way for this project to go. But it probably shouldn't until others step up to help developing it. I obviously think this way because I think putting the whole project in open sourced version control (like Git or something) would be good for its long term viability. BUT given how small the community is , and ShaDoOoW's dedication to keep it going… maybe its fine to remain his baby for now just so long as it keeps him interested and excited about it. Anyway those are the two sides to it that I see: (1) right now ShaDoOoW seems quite motivated to maintain this project and he does a ton of good work. (2) when fully open source there is the potential that more people will get involved and push it toward community owned and operated.

 

While I like community owned and operated as an ideal, I think the transition to such a state needs to be realistic and result in a better outcome than the current state of affairs. And when I think about that, I think ShaDoOoW is doing a good job and am not excited about rocking the boat.

Two more likes for the Gruftlord post (thats you and MannyJabrielle) and I will do this.

[henesua]

Shadooow. While I like the idea of open source. I don't want you to lose interest in the project. I really just want what is best for the project. and if no one else is going to join with you it might as well just be yours and remain vibrant.

[Gruftlord]

I got to agree that henesua does raise some valid points here. And i think that whatever decision might be found for the redistribution licence after this whole discussion, that the cpp at it's core should remain under Shadooows trusted leadership. Let those who wish to package parts of cpp with their modules do as they please, but keep the cpp itself as a centered project with a focused head (which is what i have been suggesting in the first place, even if my words were focused at other aspects of this)