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

Legacy_Shadooow

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


               

 


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 see. Misunderstood. Thats possible, though, do we really need gazilion of switches? At this moment, current switches includes things that "shouldn't be" but are highly desirable by players (multisummon, gloves boosts), things that "should be" but that wouldn't be well received (shifter merging improvements) and lastly things that are reverting behavior to 1.69 (spell immunity order). But do we really need a switch to revert every fix? In my opinion the only not-clearly-fix is the spell immunity order which is switchable, everything else is fix to me and a switch to unfix would be a cheat. I don't think that CPP should provide cheats, otherwise there would be, for example, a switch to ignore all prestige class prerequisities already.


 


But lets talk about the things that you would want to be switchable then.



 


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.



Little correction. Patch changes the core game, it doesn't changes modules directly. But since singleplayer modules are using client's core game resources, community patch of course applies to every single module you play. This is a patch and works the same as official patches in this regard - so I don't see why it is a bad thing, considering the CPP is designed specifically to keep default gaming experiences as much intact as possible. Its not House Rule package as some suggests and it doesn't cause any issues with older modules nor any custom content - it won't break any of the module feature/change.


 


Anyway, I am still not sure whether you understood current license - but that doesn't matter because it seems that the current licence will be, whether I like it or not removed ':crying:' .


 



 


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



Hmm you are right. And I think that builder definitely should make those settings known if he alters them!


 


Otherwise I can see a way how to disable player to override a module switch but there is a big issue. The 1.71 final is out and I dont think its wise to modify it and add anything to it except some high priority fix for issues that CPP caused (none yet - the one bug you found is very minor '<img'> ). It is possible to alter the switch system in a way that if builder sets a value to -1 it wont be possible to enable that switch. However, to make this possible I need to provide new scripts for players, so players with "vanilla" 1.71 will still ignore this and will be able to override the module settings. (Not to mention that this needs to update quite a great number of scripts and the addon is getting bigger and causes real mess in override folder - as scripts cannot be added to hak from compatibility reasons).


EDIT: even if this would be part of the CPP 1.72, anyone using 1.70/1.71 would be able to override it again. The only way would be to include the scripts in your module - which is no easy task itself as you have to locate them etc.



               
               

               


                     Modifié par Shadooow, 03 juillet 2014 - 05:43 .
                     
                  


            

Legacy_Shadooow

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


               


but keep the cpp itself as a centered project with a focused head




Which is an entire reason for that licence. I don't really mind that much that someone is using parts of the patch in his module. Its a bad manner as its something you wouldnt do if it was official but the current licence can't stop that anyway, those who wish to do that will do that.


 


EDIT: maybe I can change the licence so it allows using parts of it but to disallow fork the project itself. (Will need a help with wording that though...)



               
               

               


                     Modifié par Shadooow, 03 juillet 2014 - 05:45 .
                     
                  


            

Legacy_Gruftlord

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


               I think any major changes currently discussed would probably be outside the skope of a patch addon anyway. What we are talking about here sounds like potential plans for a cpp 1.


Edit regarding your reply above: then just state that they may do so in the license, so nobody has to feel bad for doing it in the first place. You know after all is said and done, the forces that keep the cpp together and moving forward are the people that contribute to and care about it. All the others play no role in the first place, be it positive or negative. I do not think that letting these do with the patch content whatever they like will affect those that do work and provide fixes for the cpp (however big or small) in any way. And thus will not affect the cpp as a centralized project in any form.


A valid concern may be that it may drive some people away from considering the cpp as a whole package in the first place, this is true. But i got two replys to that:

A: so what?

B: it may as well get some additional people to give the whole cpp package a try, after having experienced some of its goods in a module or two


Second edit: i'm totally liking the idea to allow repackaging/distribution but disallow forking. maybe add a line about that the project is open for suggestions in the forums if anything arises that requires clarification or if people would want to contribute their own changes/improvements to the project (as in: proactivelly encourage cooperation as the prefered method over people wishing to fork some parts)
               
               

               
            

Legacy_Shadooow

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


               


Sorry for sounding like a broken record, but it seems like I've been ignored. Is the source for the plugins never going to be disclosed? It seems you got some really nice stuff going on and such but unlike regular NWNX plugins the source does not seem to be available. There's so many more features that can be built on if this is public - such as doing the same thing with allowing items to be used while polymorphed with a 2da check. Heck, I didn't even know you can make it so that it reads an extra column in a 2da, much less fathom the method. There's so many things you can expand on now, without pretty much reinventing the wheel (or finding one, aka the pointers) - such as allowing a 2da check to see if you can cast spells while polymorphed or expand on something more elaborate like making new cursors, additional metamagic, etc...


 


And tbh, what I'm saying is it'd be nice to make it public because as far as I'm aware there's not a lot of NWNCX resources available. The only other one I know besides the original "online fix" is the Sinfar NWNCX one. I assume it's not public, but I have not yet registered on their forums to see (likely not worth it as google cache on their forums doesn't show any evidence of a source code). I'm sure I'm not the only one who's interested in the src.




Ok with a help of virusman, I finally learned how to use github.


 


Here is a NWNX_Patch source. (my working version, last release was 1.5 this has some more stuff inside)


 


Now you can help me to add disabling features via INI. (value 1 disable 0 enable)


 


I won't make source for NWNCX_Patch public because of security reasons. Yes, I could remove the risky content but I am really opposed to the idea of maintaining two versions and all the extra work to do this seems like waste of time to me. I will provide the NWNCX source on inquiry. Who wants it, drop me a PM and state what you want to do with it and possibly also where are you coming from (PW I mean).



               
               

               
            

Legacy_Bogdanov89

  • Full Member
  • ***
  • Posts: 155
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #454 on: July 03, 2014, 08:56:29 pm »


               

I honestly have no clue what you fellas are talking about over the past 3 pages, but i am very happy to see people wanting to help ShadoOow with the CPP '<img'>



               
               

               
            

Legacy_MannyJabrielle

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #455 on: July 04, 2014, 02:12:06 am »


               


I see. Misunderstood. Thats possible, though, do we really need gazilion of switches?




 


No, I would think that switches only for aspects which do have a particularly significant impact on gameplay.


 


I can give a list of my suggestions as I write up the docs for you, offhand however I could think of two things that I would consider, the bigbies hands spells in regards to 'incorporeal' creatures, and bard instruments.


 


Bard instruments already has a switch in regard to song use/perform skill check, but they still have a significant gameplay change from 1.69 with the instruments not being able to be used while the bard is silenced (bard might be mute, but why would his fingers suddenly be broken and not be able to strum a lute?).


 


For bigbies spells, incorporeal mechanics are not part of the base game in 1.69 or earlier, are they?  That's another change/tweak/fix I could see a player possibly not wanting.


 



 


 


Little correction. Patch changes the core game, it doesn't changes modules directly. But since singleplayer modules are using client's core game resources, community patch of course applies to every single module you play. This is a patch and works the same as official patches in this regard - so I don't see why it is a bad thing, considering the CPP is designed specifically to keep default gaming experiences as much intact as possible. Its not House Rule package as some suggests and it doesn't cause any issues with older modules nor any custom content - it won't break any of the module feature/change.


 


Yes, I understand the modules are affected indirectly, not directly.   And I would agree that a majoirty of the features are virtually invisible to he player.  It's the features that get the "but I wouldn't particularly like that" response when I've told friends about the patch and all the good stuff it has.


 


 



 


Anyway, I am still not sure whether you understood current license - but that doesn't matter because it seems that the current licence will be, whether I like it or not removed  ':crying:'



That could be... Perhaps a re-wording of the license for clarity is in order.  And don't misunderstand me... I agree with Gruftlord's and Hensua's opinion that since you are pretty much the only person maintaining the project, the decision is ultimately yours.  We might offer our opinions, sometimes very strongly (I have been known to do that), but the project IS ultimately your work and efforts '<img'>  If you really really want something, you're the one doing the work, you're not really obligated to make changes I or anyone else may want if you don't want to make such a change.


 


 



Hmm you are right. And I think that builder definitely should make those settings known if he alters them!


 


Otherwise I can see a way how to disable player to override a module switch but there is a big issue. The 1.71 final is out and I dont think its wise to modify it and add anything to it except some high priority fix for issues that CPP caused (none yet - the one bug you found is very minor  '<img'> ). It is possible to alter the switch system in a way that if builder sets a value to -1 it wont be possible to enable that switch. However, to make this possible I need to provide new scripts for players, so players with "vanilla" 1.71 will still ignore this and will be able to override the module settings. (Not to mention that this needs to update quite a great number of scripts and the addon is getting bigger and causes real mess in override folder - as scripts cannot be added to hak from compatibility reasons).


EDIT: even if this would be part of the CPP 1.72, anyone using 1.70/1.71 would be able to override it again. The only way would be to include the scripts in your module - which is no easy task itself as you have to locate them etc.



 


Yes, I like when module creators put pertinent info about gameplay changes into the module's description.  It's a great benefit for the player who can see important notes when they click on the module within the game.  Not mandatory, but nice.  And bug?  I still haven't had a chance to figure out if that glitch with circle against alignment was a bug or just a glitch yet '<img'>  Last bit of actual NWN playing I did was WCOC as a fighter type.  Been too busy as of late with modding stuff real life to do any more playing than that.


As for all these ideas for changes, after I get the stuff to you I already promised I'll add looking into how that third-party tool might be implemented and try to figure out how any of these ideas could be done without override clutter, ect, that is if it can be done at all '<img'>


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #456 on: July 04, 2014, 06:11:56 am »


               


No, I would think that switches only for aspects which do have a particularly significant impact on gameplay.


 


I can give a list of my suggestions as I write up the docs for you, offhand however I could think of two things that I would consider, the bigbies hands spells in regards to 'incorporeal' creatures, and bard instruments.


 


Bard instruments already has a switch in regard to song use/perform skill check, but they still have a significant gameplay change from 1.69 with the instruments not being able to be used while the bard is silenced (bard might be mute, but why would his fingers suddenly be broken and not be able to strum a lute?).




You are confusing silence with deafness. Character is mute under deafness effect where ge now got 20% chance to failure (even if he doesnt sing and only playing instrument) but silence prevents any sounds from the character no matter that they come from the mouth or instrument. Keep in mind that silence is usually not a character state but an area of effect and affect certain area, whether centered on a player or location - in this area, no sounds are possible and where there is no sound there are no bardic music benefits. Bardic music is completely dependant on the sound, but not voice. AFAIK there is not even a feat(mean in additional DnD books) that would let character to use bardic music in zone of silence.


 



 


For bigbies spells, incorporeal mechanics are not part of the base game in 1.69 or earlier, are they?  That's another change/tweak/fix I could see a player possibly not wanting.



Incorporeality is a character status that was already there. There was also already a code that handled it in certain spells such as entangle or web so these spells shouldnt affect incorporeal creatures. Though, due to the bug this never worked. CPP fixed those and expanded the spells and abilities where this has no effect.


 


Just to remind you, incorporeal creatures doesn't have a physical body and as such their are not solid. They can move through other objects (not implemented in NWN, though in CPP they can now move throught other creatures) and they cannot be grappled, held, knocked down (probably not even blown out).


 


From this reason I consider it to be a fix, though a little hardcore rule fix it makes sense.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #457 on: July 04, 2014, 12:11:13 pm »


               

it's a fix, no question. i think nobody here objected to it. the point is still: some people do object, and it doesn't matter if their reasons make any sense to us or not. it is things like these, that while they do fix some exploits, also do change the gameplay/balance a bit, that some people will object to, no matter what.


some people like their exploits/litte quirks in the game, and have been using them for over 10 year now. maybe their favourite character exploits them, maybe they just do not like change at all. it may be a fix for an obvious bug, or an exploit, or something that should adhere to PnP rules. the reasons may be sound, but this will still not convince them (i'm sure Manny brought up some vaild reasons to them as well).


 


here, you are preaching to the choir. we know why some things are changes, and we are ok with it. the suggestion is aimed at those who are not. if it is reasonably (time and complexity) possible to add a switch, for a select few issues, that some people object to, why not give them the freedom to chose which exploit they want to continue to use?


i think once Manny goes through the documentation and resturctures the fixes, the list he will come up with of fixed exploits will be reasonably short, and it might be worth considering adding a switch to them. not because they may be invalid fixes, but because some people will not like them (and not use the CPP with them) no matter what.


 


in other words, see those exploits/rule breaks as house rules, that people have been using for the last decade in NWN. the CPP should empower DMs to change the old rules (they couldn't before, now they can with CPP), but should not force them to change their house rules if they do not want to. we should not judge them for the selection of house rules they want to use.


added switches for such changes/fixes (and i think they are few), would speak that language pretty clearly.



               
               

               
            

Legacy_Shadooow

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


               

I know, but is this project suitable for these players? To add a module switch is quite easy to do and there are no other problems than the list of them getting way too big which makes deciding of what you want harder. With any new switch like this, those who don't mind this change will be confused by the switch presence and might misinterpret it and apply it even if they like it.


 


(Putting aside fact that silence effect is quite rare to obtain (generally) and musical instruments aren't common items at all. And that unless you play a module called "Attack of the spectres", you won't encounter incorporeal creatures very often and even if you do, there are other spells you can use on them, why would anyone tried to cast bigby is unknown to me, mainly because they have a damage reduction so the bigbies does no damage to them.)


 


Imo adding switches that restores fixes is not in scope of this project. Peoples who want to play this way will not be generally interested in this patch itself, only in certain new features - but they won't want to pay the price for them and thats allright I think. I don't think I can provide a:


- switch to remove metamagic exploit so they can double duration of potion buffs again


- switch to add bard class usage into scrolls that possess spells not castable by bard, so they can use it without UMD again


- switch to make aura AOEs dispellable again, so they will be able to dispell dragon fear aura again


- switch to restore old curse song behavior, so once they sing the curse song they will be immune to curse song of others


etc.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #459 on: July 04, 2014, 01:52:43 pm »


               

i see, you are right. that list might be longer than i expected.



               
               

               
            

Legacy_Shadooow

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


               


i see, you are right. that list might be longer than i expected.




Exactly. I don't think that CPP should be trying to gratify everyone. Players who want to play this way has a right reason not to use patch and thats fine. It doesn't mean the CPP is bad or wrong, it does exactly what it should and its a pity it doesn't suit everyone, but thats expected. Fortunately, it is optional so unless builder decide, you can play any module created with 1.71 with vanilla 1.69 as well which solves all potentional issues and builders are not losing an audience.


 


1.69 also didn't provided a switch to restore the original holy avenger dispel magic behavior (which could dispel everything even monster auras or petrification). Thats not the patch's resposibility - if someone doesn't like this he have to modify it afterwards - which CPP still allows. I even think that one persistant world stayed on 1.68 for this reason, was some kind of arena, its probably down for a long time since players with 1.69 didnt saw this server and I think they even couldnt log in.


               
               

               
            

Legacy_Shadooow

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


               

Anyway, when I was thinking about those musical instruments and silence and re-checking DnD rules and forums I get this idea to improve silence casting in AI.


 


At this moment, AI casts this spell targetted to PC - which gives him saving throw to avoid it completely and in case he fails, it grants him a benefit as the silence zone is centered on him and moving with him so he can reach the original caster and make him silenced and prevent him to cast spells (which is common tactic on PWs where player casts it on himself voluntary - usually because he has silent spell feat - AI is helpless under silence.).


 


Therefore I think that the AI should cast it on the PC position, granting him no save. Player will be able to escape the silence zone but it still make the spell more potent than normally.


 


Also, I realized that silence should probably remove the benefits of bard song and penalties of curse song. But thats probably too hardcore as it spoils the usual self-silenced tactics for bards.



               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #462 on: July 04, 2014, 04:13:10 pm »


               

re position casting: maybe a 50% chance for either option? then it would be a bit more unpredictable of what happens


 


re bard song: i'm not sure the bard is supposed to sing (or whatever it is interpreted as by a specific player) during the whole duration of the song. i allways thought the bard does something inspirational once, and motivational effect then lasts for a bit. so, it would have never come to my mind to drop the effect once silenced (after the song has already been sung)



               
               

               
            

Legacy_Shadooow

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


               


re position casting: maybe a 50% chance for either option? then it would be a bit more unpredictable of what happens


 


re bard song: i'm not sure the bard is supposed to sing (or whatever it is interpreted as by a specific player) during the whole duration of the song. i allways thought the bard does something inspirational once, and motivational effect then lasts for a bit. so, it would have never come to my mind to drop the effect once silenced (after the song has already been sung)




he is supposed to sing the whole duration, however bioware simplified the whol bard singing at minimum, in PnP this works completely differently:


- multiple songs, each doing something else and bard can sing only one at the time


- song as an area of effect that has a 5round (*2 with lingering) echo so even if you no longer hear the song you still has its benefits for some time (thus if bard cast song 1 then sing song 2 and after 5rounds he start sing song 1 again, he can keep both songs benefits on all his allies all the time


- no spellcasting during singing - casting a spell cancel current song - however attack and other actions is allowed (if there are exceptions I dont know them)


 


So removing the bard song benefits upon silence probably not fits the NWN song implementation. As per DnD, silence will interrupt character from singing (if he is the singer/instrumentalist) but there is the echo till you still get benefits.


 


Nah, not a good idea. Maybe someday I will release the PnP bard songs which I implemented for my module already...


               
               

               
            

Legacy_Bogdanov89

  • Full Member
  • ***
  • Posts: 155
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #464 on: July 04, 2014, 08:56:16 pm »


               

ShadoOow, i got some new save game files that i think might show some AI bugs - if you could please take a look at them, it would be awesome '<img'>


 


http://wikisend.com/...881892/possible bugs.rar


 


The zip file should be about 11 megabytes heavy - short description of saves:


 


If named "passive" then to me it looked like the AI was not trying to fight.


"No heal" means he did not heal me when he was supposed to.


"Bash stuck" means my henchmen got stuck when i tried bashing a chest - he did not move from that corner until i was almost the entire zone away.


"Missing henchmen" is a save in which my hench Lina (the cleric) died (i think it was from a trap) but she did not appear back in the temple (or anywhere else), and i never saw her again in that chapter.


 


 


Also, a few questions about the minimap in NWN:


 


1. Since i am playing NWN at a very high resolution (i think it is 1920x1080), the minimap is very small even when i zoom it fully.


Could you perhaps make the minimap bigger for higher resolutions, or perhaps allow us to make the minimap bigger by zooming in more?


 


2. When in full zoom, the minimap usually centers on your current location and "cuts off" (hides) areas/corners that it thinks are too far to matter.


However i find this extremely annoying, especially since the minimap is still too small for my high resolution - while it insists on hiding valuable map portions because it wants to be compact!!  ':angry:' 


 


3. Is there any way to prevent the minimap from automatically out-zooming when i change zones/places (after loading screen)?


I always want my minimap to be as big as possible and having to constantly zoom in after every zone loading is definitely annoying.


 


Overall i want my minimap to always be as big as possible, and i also want it to be forced to display every corner of the zone i am in.


The damn minimap keeps trying to hide big parts of it so that it is compact, but due to the resolution i need the exact opposite - i need a huge minimap that shows all corners...


 


Is there anything you can please do to improve the minimap?


I assume in the form of an optional (separate) file, so that people don't have to use the minimap changes if they don't want to?