A few questions for the experienced NWN players :)

[Legacy_Pstemarie]

               

ShaDoOoW wrote...

Pstemarie wrote...
There are also a lot of systems I use that I integrated long before CPP came out. It took awhile to get them working. I'd rather not go through that again.

Can you point me any scripting system that is CPP supposed to mess with? Due to its nature its almost impossible this could happen, maybe it does but so far I haven't see such case and I spent a long time making sure this won't happen.

The systems I use are:

The Krit's Alternate Horse Scripts - several spells are heavily modified. Using the CPP, I would have to go back and adjust these spells to use the new spell system you introduced. 

HR DM Tools - probably not an issue since nothing in CPP seems to clash with this.

Axe's Killer Death System (KDS) - probably not an issue since nothing in CPP seems to clash with this.

Bleed System - heavily modified from original work by Tom Banjo and Scott Thorne to work with KDS. Some spells have been altered so that their function more resembles PnP. Using the CPP, I would have to go back and rewrite these modifications to use the new spell system.

Spell Components and Spell Overrides - this is a rather large spellhook system that I developed shortly after 1.69 was released. It modifies numerous spells, several of which are completely rewritten. Using the CPP, I would have to go back and rewrite these modifications to use the new spell system.

Screw Tape's Simple XP - probably not an issue as I modified the functions to be self contained and only two scripts are affected and it would be simple enough to add the one line of code where needed.

AI Modifications - probably the most significant area. I have tweaked the AI over several years so that it behaves according to how I want it to behave on my LAN server. While the CPP changes to the AI are excellant for experienced players, my players aren't the brightest when it comes to tactics and get obliterated. They're learning, but just not there yet.

Other Things in CPP that Mess with my Work (or Just aren't needed):

Sticking to CPP 1.70 because that's what I tried out way back when...

Familiar and Companion Fixes - Included in Project Q
Any Creature Template - I use all custom templates, even for summons, except familiars (too lazy to make new ones)
Tile Fixes - Most of these already included Project Q 
Item Property Changes - Conflicts with work I've done, although could easily be merged
Iprp_spells.2da - I don't agree with all the changes here.
Spells.2da - I don't agree with all the changes here. I also have modfiied several spells and added new ones.
Etc....

It would be far easier for me to pull what I do want to use from your scripts and inject it into my module, but you clearly indicate in the User License you attached to the CPP that you're not kosher with that...

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.

Such a license is your perogative and I respect its terms. I probably doesn't apply in my particular case, but since there is a chance I might one day release the actual module, I don't want to violate your terms.

Perhaps you stated it best in 2009, when you condemned my original NWN 3.0 SRD project on the Vault for essentially doing the same thing you went on to do with CPP...

This was quite good in first stages, but then you screwed it up! Why everyone wants to make a package like CEP? Or package to be considere as new patch ? The prefix x4, you used looks like you want this to be a new patch or what. I don't think it's a good idea. I really don't like that this project included creature and cloak models an whatelse...

...Also, changing standard dialog.tlk is very, very bad and evil idea.

If you're a player and wish to confine your game play to the OC, SoU, HotU, and modules that rely solely on that content, the CPP is a good choice. If you're a Builder or a player that wishes to extend the game beyond what Bioware released, the CPP is still a good choice but, for pre-existing content, you're going to find that the alterations in CPP might alter the module from what the author originally intended. 
               
               

               

                     Modifié par Pstemarie, 18 février 2014 - 11:44 .
                     
                  

            

[Legacy_Shadooow]

               

Pstemarie wrote...

Using the CPP, I would have to go back and adjust these spells to use the new spell system you introduced.

First I will reply to this. You are not forced to "go back and rewrite old spell scripts". Its something I would recommend and it is needed if you wish to use some of the CPP features such as overriden caster level in those spells. But if you dont plan using this its not needed, and if you do plan this, then you cant really complain you have to rewrite spellscripts when its your decision. CPP doesnt force you to do this, you can install it and keep your old spellscripts with no issue.

The systems I use are:

The Krit's Alternate Horse Scripts - several spells are heavily modified.

HR DM Tools - probably not an issue since nothing in CPP seems to clash with this.

Axe's Killer Death System (KDS) - probably not an issue since nothing in CPP seems to clash with this.

Bleed System - heavily modified from original work by Tom Banjo and Scott Thorne to work with KDS. Some spells have been altered so that their function more resembles PnP. Using the CPP, I would have to go back and rewrite these modifications to use the new spell system.

Spell Components and Spell Overrides - this is a rather large spellhook system that I developed shortly after 1.69 was released. It modifies numerous spells, several of which are completely rewritten. Using the CPP, I would have to go back and rewrite these modifications to use the new spell system.

Screw Tape's Simple XP - probably not an issue as I modified the functions to be self contained and only two scripts are affected and it would be simple enough to add the one line of code where needed.

AI Modifications - probably the most significant area. I have tweaked the AI over several years so that it behaves according to how I want it to behave on my LAN server. While the CPP changes to the AI are excellant for experienced players, my players aren't the brightest when it comes to tactics and get obliterated. They're learning, but just not there yet.

And you really experiences any issues? Because none of this scripting system should have caused any. CPP acts as a true patch everything has a low priority.If you changed 2das with your own modifications, CPP will not override it and its up to you whether and how will you merge the new 2das from CPP with your own. You are definitely not forced to do this in a first place.

If you tinkered with AI yourself, then CPP is not going to change your modifications and due to the way how AI works, CPP AI features are there not expected to work at all in your case.

Other Things in CPP that Mess with my Work (or Just aren't needed):

Sticking to CPP 1.70 because that's what I tried out way back when...

Familiar and Companion Fixes - Included in Project Q
Any Creature Template - I use all custom templates, even for summons, except familiars (too lazy to make new ones)
Tile Fixes - Most of these already included Project Q 
Item Property Changes - Conflicts with work I've done, although could easily be merged
Iprp_spells.2da - I don't agree with all the changes here.
Spells.2da - I don't agree with all the changes here. I also have modfiied several spells and added new ones.
Etc....

Again, when something is in CPP and also in your module/override/patch-hak/hak, it is not going to replace your version. I don't understand why is this wrong. Yes some of the content is there suddenly twice, and what? Some content such as 2das are in core game files fourt times already. I calculated it and there is around 300mb of duplicate content in a core game files. And suddenly its a problem.

Speaking of Project Q and tile fixes, I wasn't aware that you are doing the same as I. Last time I checked there were only two fixes in a TNI interior. Anyway - why you haven't cooperated with me on this? Why you were making and adding a fixes for default bioware tileset into your project if you could help me and add them into my project that has this in its scope. If its true what you are saying then you willingly let me working on the same pointlessly.

And this is a great showcase how NWN community treats this project. Yes I understand that someone doesnt want to use it because he believe he is better to stockpile various fixes one by one when he finds that issue. But why you are not support this project at all? Project Q, CEP2, intentionally ignores this project and refuse to merge 2DAs or use some features from it (such as the creature variables like FLYING). I don't understand this.

Perhaps you stated it best in 2009, when you condemned my original NWN 3.0 SRD project on the Vault for essentially doing the same thing you went on to do with CPP...

This was quite good in first stages, but then you screwed it up! Why everyone wants to make a package like CEP? Or package to be considere as new patch ? The prefix x4, you used looks like you want this to be a new patch or what. I don't think it's a good idea. I really don't like that this project included creature and cloak models an whatelse...

...Also, changing standard dialog.tlk is very, very bad and evil idea.

If you're a player and wish to confine your game play to the OC, SoU, HotU, and modules that rely solely on that content, the CPP is a good choice. If you're a Builder or a player that wishes to extend the game beyond what Bioware released, the CPP is still a good choice but, for pre-existing content, you're going to find that the alterations in CPP might alter the module from what the author originally intended.

Nice find. But these are apples and oranges. Unlike CPP which acts as a true patch, your project will override builders' stuff and builder have to merge everything. This was reason why I have waited so long with this and made this yet when ElgarL made a way how to edit bioware BIF files.
               
               

               
            

[Legacy_Shadooow]

               Except that, today I wouldnt rated your project(s) so harsh. In that time I, same as you believed that only I have a right vision of what should be and what shouldnt be and I can do everything better than the original author. In that time I needlessly spent so much time making my own version of SIMTools, my own version of 3.5 changes, my own version of the NPC Activities and list continues.

Later, I found this was waste a time and my self-confidence naive.
               
               

               
            

[Legacy_Pstemarie]

               

ShaDoOoW wrote...

Speaking of Project Q and tile fixes, I wasn't aware that you are doing the same as I. Last time I checked there were only two fixes in a TNI interior. Anyway - why you haven't cooperated with me on this? Why you were making and adding a fixes for default bioware tileset into your project if you could help me and add them into my project that has this in its scope. If its true what you are saying then you willingly let me working on the same pointlessly.

ShaDoOoW, the tile fixes I was referring to YOU incorporated into CPP using work that was done by Project Q. Project Q from its inception incorporated numerous tile fixes and upgrades into it. Since Project Q is older than CPP, it made NO sense for Project Q to go back and remove something just because someone else included it in their project. Such a removal would have made projects built using older versions of Q suddenly dependant upon CPP to get those tile fixes. I have no problem with the CPP including the Q tiles but for someone that uses Project Q, it makes the files included in Q redeundant if they are also using CPP. Granted, its a small number of files.

Given, the above, I'm not sure why you seem angry that Project Q didn't coordinate with CPP about what we included in Q. Frankly, its more than a little presumptuous of you to expect any project to coordinate anything with you. I certainly don't expect authors to coordinate with Project Q. It'd be nice, but if I want something to work with Q then its up to me to see that it does so.

Your response to the rest of my post certainly merits that I take a second look at CPP - when I have more time. I like a LOT of what you have done with it, but some of the coding you've placed in their is, quite honestly, above my head. I'm sure I could figure it out, but time is, as you know, in short supply. I know you say that I don't have to integrate my script changes to yours, but if I'm going to use something, I'd much rather use ALL of it.

No, I'm not mad at you because I have to go in and figure this stuff out myself. However, you asked why people don't use CPP and I responded. However, now it seems like my initial assessment, based upon the reading I've done about CPP in other threads and on other forums, is jaded by my own fear that I'll mess my module up if I use it. I understand now that my fear may be unfounded.

So in the spirit of the salemanship you've shown in the last thread, I'm going to test drive my module over CPP on my laptop and see what happens.

I also apologize for blocking you and unfriending you. At the time I had taken you to be mean-spirited and didn't want to be associated with such a person. After looking through the reams of forum posts, its plain for anyone that wishes to look that MANY people have unfairly treated you like a piece of crap, and for what - all because you wanted to make the game a little better for the people playing it (a goal shared by CEP, Q, and all those other projects out there).
               
               

               

                     Modifié par Pstemarie, 18 février 2014 - 01:35 .
                     
                  

            

[Legacy_Shadooow]

               

Pstemarie wrote...
Given, the above, I'm not sure why you seem angry that Project Q didn't coordinate with CPP about what we included in Q. Frankly, its more than a little presumptuous of you to expect any project to coordinate anything with you. I certainly don't expect authors to coordinate with Project Q. It'd be nice, but if I want something to work with Q then its up to me to see that it does so.

Hmm good point. I misunderstoo you, thought that member of the Q team was doing more tile fixes recently. Which as you can see here I am doing simultaneously thorought last two years. Shame I cant add a new screenshots there becuase I made around 30 more tile fixes for last 6 months. Mostly tilefading related, yes.
               
               

               
            

[Legacy_Pstemarie]

               

ShaDoOoW wrote...

Pstemarie wrote...
Given, the above, I'm not sure why you seem angry that Project Q didn't coordinate with CPP about what we included in Q. Frankly, its more than a little presumptuous of you to expect any project to coordinate anything with you. I certainly don't expect authors to coordinate with Project Q. It'd be nice, but if I want something to work with Q then its up to me to see that it does so.

Hmm good point. I misunderstoo you, thought that member of the Q team was doing more tile fixes recently. Which as you can see here I am doing simultaneously thorought last two years. Shame I cant add a new screenshots there becuase I made around 30 more tile fixes for last 6 months. Mostly tilefading related, yes.

I beginning to see most of what went down between you and I firmly lies in the realm of misunderstanding. Damn my pig-headedness and penchant to try to read between the lines when there are no lines to read between.
               
               

               
            

[Legacy_Pstemarie]

               Well a flat tire has given me some opportunity to work on merging scripts while I'm waiting for the garage to bring my car back. So far, I'm happy to report...

1. Installation of CPP 1.70 was painless.

2. None of the scripts or systems in my module failed to work after installing CPP. I still have some work to do integrating my spell modifications with what ShaDoOoW has done, but so far I'm quite happy to report that I have been able to remove several scripts. The CPP spell system really proved quite simple to comprehend - I was over-analyzing it - and is a definite improvement to the way in which spells are implemented.

3. I played the first quest and it played out exactly as I had intended. No unforseen issues because of CPP. The fighting wasn't any easier or harder, although the creatures did seem to use better tactics.

4. Integration of scripts is fairly easy to do. For spell modifications I have made prior to adding CPP, it comes down to simply changing some variable names. Other scripts are even simpler.

To sum it all up - I'm sold and I stand firmly behind the 9.75 rating I gave it on the Vault when it first came out and I test drove it in single player. 
               
               

               

                     Modifié par Pstemarie, 18 février 2014 - 04:05 .
                     
                  

            

[Legacy_WebShaman]

               Yup!

This is the same conclusion I came to when I tried out CPP 1.70 for ShaDoOoW.  Thank you, Pstemarie, for being so kind, generous and understanding.
               
               

               
            

[Legacy_Pstemarie]

               

WebShaman wrote...

Yup!

This is the same conclusion I came to when I tried out CPP 1.70 for ShaDoOoW.  Thank you, Pstemarie, for being so kind, generous and understanding.

I made a huge mistake and I'm not afraid to own it - I wouldn't consider myself much of a person if I couldn't admit when I was wrong.

I'm about 50% through integration and so far I've only found a few things I've had to alter in a few CPP scripts to suit implementation on my LAN server. I certainly wouldn't change any CPP scripts if playing in SP, which my son is doing and having a great time (he says the OC is much better). These changes - MY house rules - have been quick and easy and certainly don't reflect on the CPP. You can use it out of the box and build a pretty balanced module. I've got the following systems working flawlessly with it...

1. Axe's Killer Death System by Axe
2. HR DM Tools by ShadowM
3. Screwtape's Simple XP
4. Dynamic Cursed Items (Item looks normal until you equip it then its true properties come out) by me
5. Spell Components and Spell Foci by me
6. PHB Bleedsystem by Tom Banjo and Scott Thorne
7. PHB Rest System by me
8. Expendable Torches and Lanterns by me
9. Alternate Horse Scripts by TheKrit

As you can see from the above list, its pretty easy to integrate stuff with CPP and in fact most everything listed (except the Horse Scripts) didn't require any work beyond importing the ERF.
               
               

               

                     Modifié par Pstemarie, 19 février 2014 - 02:16 .
                     
                  

            

[Legacy_Shadooow]

               BTW after arguments Ive heard there about it, after some PMs with peoples I know they uses CPP I came to the conclusion that I should restore the OC empower behavior to be the default.

All spells now uses the same mechanic so its not possible to restore the vanilla behavior where some spells does empower everything and some just dice, but the NWN description is clear about this and the implementation shoul match it by default.

Still, due to the fact that I still believe the dice/only empower behavior is more balanced and preffered, I will add a new module switch that enforces it without need to recompile spellscripts and adding them into module/override/hak. That way I think the both camps will be satisfied.
               
               

               
            

[Legacy_WebShaman]

               Choice is good!  Switches are good.

Everything good.
               
               

               
            

[Legacy_Pstemarie]

               

ShaDoOoW wrote...

Still, due to the fact that I still believe the dice/only empower behavior is more balanced and preffered, I will add a new module switch that enforces it without need to recompile spellscripts and adding them into module/override/hak. That way I think the both camps will be satisfied.

That's an excellent compromise. You could almost do the same thing with any change you've made that has caused controversy, but I'd understand if you didn't given the amount of scripting involved. That being said, I'm quite happy with what I've got right now. 
               
               

               
            

[Legacy_Shadooow]

               

Pstemarie wrote...
You could almost do the same thing with any change you've made that has caused controversy, but I'd understand if you didn't given the amount of scripting involved.

This. Its definitely not preffered to have switch on everything namely on real fixes such as regeneration stacking fix. That might be controversy due to the fact that some players and perhaps even builder like it that way but the issue itself is imo clear bug.

I don't think there is more controversy changes in scripting. Empower - ok solved and will change it in next CPP 1.71 release. Then there is the spell mantle order which I changed but this is already switchable in 1.71, though default behavior is the new one for now.

If there is something else, then I don't know about it and never heard about it from anyone. Builders like MM doesnt like Ive did that at all rather how I did that.

Non-scripting related, the colored icons are something I know about, but its something that although might not be preffered by the few very conservative oldplayers I believe it is good choice and improves feel from this game especially for new/er players to NWN who arent so tied to the vanilla gray icons yet. What Amethyst Dragon done is really a great job and while I personally didnt liked the decision he made about replace several icons at first, when I tried to play with it, I soon get used to them and I must say they are better and I like them very much now.
               
               

               
            

[Legacy_WebShaman]

               ShaDoOoW, I really hope that you follow the lead that the PRC began, by incorporating switches into your patches.

By doing so, you really remove any and ALL dissent towards the changes that you make, by providing others a way to choose for themselves what they want.

It is a really good argument tool as well - you can shut up your detractors merely by saying "there is a switch for it".
               
               

               
            

[Legacy_Shadooow]

               

WebShaman wrote...

ShaDoOoW, I really hope that you follow the lead that the PRC began, by incorporating switches into your patches.

By doing so, you really remove any and ALL dissent towards the changes that you make, by providing others a way to choose for themselves what they want
It is a really good argument tool as well - you can shut up your detractors merely by saying "there is a switch for it".

I understand this point of view, but there wasn't a switch for the UEF dodge stacking in 1.68 was it? That change made this spell suddenly unusable and builders was forced to deal with it, but nobody had problem with the change itself, because it was official, right?

This is a patch in the first place, there are a switches but only for things that are not fixes but rather design desicions or new features such as "ALLOW_BOOST_GLOVES" or "STACK_MERGED_ABILITY_BONUSES" switches.

Also, when its something that affect a single (spell)script, the switch is there redundant, this is something I actually didn't liked on the PRC, there was switches needlesly for too many things, when I could change them myself if I wanted to. This made code of those scripts needlessly complicated and too many switches imo hurt the project itself.

Thats why I removed in the 1.71 two switches that were proposed in the 1.70. Switch for dusty rose ioun stone ac type and switch for the continuous light stolen flag. Single spell, which isnt preffered to change by a player and if the builder doesnt like it he can modify it (if he didnt already in which case he doesnt need to do anything)
               
               

               

                     Modifié par ShaDoOoW, 20 février 2014 - 08:00 .