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.