Author Topic: Community Patch discussion and development thread  (Read 21114 times)

Legacy_MannyJabrielle

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #435 on: July 03, 2014, 01:35:11 pm »


               

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.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #436 on: July 03, 2014, 02:00:40 pm »


               

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.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #437 on: July 03, 2014, 02:14:02 pm »


               


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?



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #438 on: July 03, 2014, 02:17:07 pm »


               


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?



               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #439 on: July 03, 2014, 02:24:48 pm »


               

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.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #440 on: July 03, 2014, 03:35:20 pm »


               


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



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #441 on: July 03, 2014, 04:11:00 pm »


               

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 .
                     
                  


            

Legacy_MannyJabrielle

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #442 on: July 03, 2014, 04:47:51 pm »


               


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 '<img'>  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 '<img'>  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 '<img'> 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 '<img'>  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 '<img'> ).


 



 


 


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.


               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #443 on: July 03, 2014, 05:16:03 pm »


               


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.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #444 on: July 03, 2014, 05:19:37 pm »


               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.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #445 on: July 03, 2014, 05:26:36 pm »


               

sounds good, Gruftlord. Thanks.



               
               

               
            

Legacy_MannyJabrielle

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #446 on: July 03, 2014, 05:50:43 pm »


               


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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #447 on: July 03, 2014, 05:59:28 pm »


               


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.



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #448 on: July 03, 2014, 06:13:12 pm »


               

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.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #449 on: July 03, 2014, 06:30:26 pm »


               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)