324 réponses à ce sujet

[Shadooow]

Yes it is pointless. Your responses are perfect, you basically confirmed all I wrote in previous post, thanks. Let everyone make his own opinion on this.

I wrote enough on the CPP, I stopped the edvertisement because I was told its embarrasing and nobody cares. First time I tried to advertise this project in general forum it took only one hour before someone confronted me about abusing the general forum - because no way this project would be accepted by the community and thus as a any custom content the right place is in custom content forum so I had to move there. Later, when someone asked about some issue I wrote that this issue was fixed in CPP. Was told by PM this is wrong and abusive too so I stopped this entirely.

Im actually sick about this community, but I believe in this project and I already devoted to its development more than 2 thousands hours so I am still working on it with hope that at least someone appreacite my effort.

Of course, then there are peoples like you who do believe that they are better fixing everything themselves when they find that issue. Or that they already have everything and don't need anything from CPP at all.

I can say only a good luck and have fun with reinventing the wheel. If you rather spend dozens hours on a balancing rules and fixing stuff instead of actually creating the world, its only your choice.

Modifié par ShaDoOoW, 17 février 2014 - 02:54 .

[WhiZard]

You might have placed too high of hopes in this project as well. From its outset it was supposed to be a useful tool for new developers trying to create their PW. It served to counter many exploits, as well as give a framework that easily allows a new PW author to make changes fluidly without having to understand the constraints of the BioWare Toolset. As a result, there were many workarounds that fell short of the direct fixes that acaos and others could make with plugins.

As advertised on the custom content forums, you have presented it as a panacea for most problems that posters have had, even if there was just a single thing they were concentrating on fixing. The way it was implemented, the CPP could not be seen as a compilation of changes because it there was little support for partial implementation of the CPP for one change and not another, instead the CPP ended up being a combination of changes which may or may not produce beneficial or unwanted results in areas that a builder might not expect.

Your hopes here are in direct recommendation for users (module players) to download to enhance their experience. But users are those who probably need it the least. The changes made may or may not be applicable in the modules they play, and the extra functionality for builders, really doesn't mean a whole lot to them.

[Pstemarie]

Yeah, what Whiz said. Doesn't mean it's a bad project, just that its usefulness to some might not be what you'd expect. I personally prefer to "reinvent the wheel" cause I learn more that way. 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.

Modifié par Pstemarie, 17 février 2014 - 06:49 .

[Bogdanov89]

I got no clue about private servers and user made content, but to me as a player of the original NWN campaigns i find the CPP very useful.

All the bugfixes are awesome, and the only thing i wanted to change ShaDoOoW was kind to provide an alternative mini-mod for CPP (empower 50%/maximize 75%).

Overall i am very satisfied with CPP - so thank you ShaDoOoW for all the content and the advices you have shared with us

[Shadooow]

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.

CPP is not just backwards compatible but also forwards (its possible to compile old scripts with new includes).

Despite what MM said there are no issues with haks or custom content (except the DOA baseitem issue - which is crash that happen to the players without patch if builder merges DOA base items into his 2DAs but dont include the models - which can be avoided and its described how in the readme). And the fact it has the lowest priority is the biggest advantage of the approach that CPP works.

[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 .

[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.

[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.

[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 .

[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.

[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.

[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 .

[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.

[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 .

[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.

[WebShaman]

Choice is good! Switches are good.

Everything good.

[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. 

[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.

[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".

[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 .

[Elhanan]

I know little of mod crafting, but based as a frequent mod user in NWN and Skyrim, mods (especially those that perform some type of overhaul )generally appear to be better received when designed as modular. In Skyrim, the SkyRe design allows the indv Player to choose which of the alterations they desire to activate, as opposed to some other mods which only allow for the author's vision.

Neither are wrong, but allowing the indv Player to better customize their own experience appears to be the more popular and useful choice.

[Shadooow]

Elhanan wrote...

Neither are wrong, but allowing the indv Player to better customize their own experience appears to be the more popular and useful choice.

Well I got different experiences with the Jagged Alliance 2 where community made a new unofficial patch and allowed to set absolutely everything from the speed of how characters progress in abilities and levels, through mine income up to adding zombies to the game.

In my opinion it completely broke the game. Nobody played the same game anymore, everyone was playing by different rules and comparing the game progression become impossible and pointless. Futhermore, and this is something I experienced myself, players suddenly restarting the game because they found that zombies are quite stupid option or that the change they have done resulted in too easy or too harsh gameplay.

I don't really want to end up as they did. Actually, I was already tempted to remove some of the switches I added from my own iniciative or on a player requests into CPP such as multisummoning or allowing spells to boost gloves from this exact reason. CPP should not provide an overwhelming option set for each rule. Thats up to the custom content - of course nobody is making custom content for CPP but thats not the obstacle.

This should be a patch not a custom modification. I know many peoples out there never accept it, but thats the way how project like this should look like.

I think you will agree with me that making things like the "Familiar fixes" optional is just nonsense. So point me specifically what should be optional and we can talk about it, but this cannot be applied globally on this project.

Also, due to the fact that the patch content will never overwrite anything that builder already did in module I dont see a need to make things like the Dusty Rose Ioun stone optional anymore.

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

[Shadooow]

BTW. I was making an adjustion into spells in my module to allow spells to deal critical hit.

This is something that was already presented in PRC, but their scripting become obsolete for me as Im now building on the spellscripts from CPP.

Anyway, I stroke on the Empower issue again! And it gets even more riddiculous if I apply whats written in the SRD and multiply the spell outcome by 2. Suddenly the advantage of the empower vs maximize is twice as big in those spells with bonus per caster level. But rules are clear .

[Elhanan]

I do not use overhauls; have only seen them in use, and know of their popularity. Perhaps taking a look at total downloads and endorsements of mods, and then comparing designs will grant some kind of info on what folks most want and utilize. While total overhauls are quite valid and are popular, these do not seem to be the ones at the top of these lists.

[Shadooow]

Elhanan wrote...

While total overhauls are quite valid and are popular, these do not seem to be the ones at the top of these lists.

Yes the most popular and downoaded are nudity packages. And what? Should I perhaps add it into my project to get some more popularity ? 

This project has a certain scope. This scope is defined by the things that Bioware made in official patches, by the things that a generic Community Patch usually does in other games and what is technically possible and impossible to do in NWN given by the compatibility issues etc.

There are peoples who will never use it even if it would be perfect and endorsed by the "community". Those are peoples who are not even willing to try it. And there is nothing I can do about it. But modifying the project per the suggestion of these peoples is something I found out to be pointless.

Modifié par ShaDoOoW, 21 février 2014 - 12:37 .