Community Patch discussion and development thread

[Legacy_Shadooow]

               

if this is something that shadooow can add via an nwnx.dll, then why not. afaik, adding new options for builders to set up new modules is something Shadooow wants to tackle with the project.

I can do that, the problem is many of these features were already done. For NWNX at least.

 

I dont think it would be right to steal other plugin's job. Unless the original author will specifically want to include his content under CPP but that has a downside that I would want to include it under single plugin not to ship the other plugins with it. And thats something that many nwnx developers wont accept.

 

Otherwise it would be nice to have an ability to change whether is weapon finessable, useable by monk with flurry or have extra module events such as OnToggleMode, OnCastSpell etc.

               
               

               
            

[Legacy_MannyJabrielle]

               

Well but  you know no spell in DnD breaks improved invisibility. And this is actually possible to implement in NWN - it has real improved invisibility that can be turned on, the current improved invisibility is a workaround as the real one was extremely powerful and AI couldnt react on it. The NWN ii is a combination of the normal ii + 50% concealment. And this normal invisibility is lost anytime you do something harmful to anyone - is curse song harmful? no odubt about that.

Yeah, that's why I only initially jotted it down as something to ask about.  I did remember tabletop improved invis acted much differently than NWN's version.  The tabletop version would be nice, but the AI would definitely be more important to maintain.  And yes, curse certainly is a harmful one '>

 

 

 

Clarification: NWN has an effect and duration scaling system. This is a script that reduces duration depending on a game difficulty and swap effects for less harmful ones. This triggers only if a PC is a target of such spell by default.

 

Ah, ok, that clears it up... just like how confuse (or whatever spell/effect is cited in the difficulty slider descrition) will give a daze effect at lower dificulties.

 

 

Anyway - it would be possible to rework this to require both, I understand that this would be a nice feature for some epic musical instruments. Will do.

That was the idea I had in mind for a later chapter in my campaign... a couple of high end musical instruments I wanted to restrict to not just bards, but very skilled ones '>

 

Clarification: Several 1.69 scripts has been affected and compiled with the x3_inc_skin library. Every spell that was recompiled with this library now creates a PC Skin on a caster or target and this skin then remains in loot. This is something that The Krit fixed, but I took different route to do that and I rewrote the mount check in a way it no longer needs a x3_inc_horse include which I therefore removed from the offended scripts to make it more clean. But basically, from a generic user this line means the only thing: fixed PC Skin issues.

Great, thanks.

 

txt would be nice

Will do.  Will get it to you as soon as I can, it's just been damn busy lately.  Parade season, so lots of truck prep '>  And I try to actually play the game now and then lol.

               
               

               
            

[Legacy_Shadooow]

               

 

Ah, ok, that clears it up... just like how confuse (or whatever spell/effect is cited in the difficulty slider descrition) will give a daze effect at lower dificulties.

Addendum:

CPP implement this feature into fear spells where it results in attack decrease penalty instead. This was already in the code of the effect scalling function just non-functional (which I found after 1.70, where it doesn't work) and unused - no actual fear spell/ability uses this in vanilla.

               
               

               
            

[Legacy_MannyJabrielle]

               

So the patch *does* implement scaling, vanilla non-patched was supposed to at one point, but for whatever reason, bioware never actually put it in?

               
               

               
            

[Legacy_Shadooow]

               

So the patch *does* implement scaling, vanilla non-patched was supposed to at one point, but for whatever reason, bioware never actually put it in?

yes

               
               

               
            

[Legacy_Shadooow]

               

I put together a page containing all non CPP specific content that CPP has/uses. LINK Maybe could be helpful.

 

Now, to the new 1.72 beta update:

 

Sorry bogdanov, but I decided not to add the auto mighty for sling and shuriken. I know these weapons would deserve it, but they are following the 3.0 DnD rules which NWN is based on. The change you want is in 3.5 which is basically a patch for 3.0 however CPP cannot act as a 3.5 ruleset.

 

Also, the switch for buffing ranged weapons doesn't seem promising. This is because some itemproperties works only on ammunition and some doesn't. In the end, the character would have to buff GMW on bow and Flame Weapon on arrows. This could also lead to unintented stacking (although properties from bow and arrows actually doesn't stack). Its weird and I don't know how to solve it.

 

As for new content:

I am adding the old cloaks into game for once again - they will occupy the line 90 in baseitems.2da - unless someone has better idea. This will be of course in a hak version (because client need this).

 

I would like to add IMProvments from _six but this file is not yet uploaded on new vault, does anyone have it? And possibly also Animated Inventory GUI Glow from _six though there are no screenshots and I voted 9 so not sure, what do you think? - but if anyone have this please upload on new vault. (Where is _six anyway?)

 

And I got a new idea how to handle ground item models. Current method isn't perfect because if a builder merge baseitems.2da from CPP and player without CPPwill play it he will experience weird behavior with inventory and possiblycrashes - to avoid that the ground item models must be added into hak as well which is explained several times across CPP documentation. However it is possible completely avoid this issue. Instead of using a base ground model, each item could have its own. So basically 255 copies of doa_boots, 255 copies of doa_belt and so on. Its a bit "ugly" method since this generates cca 5k files. But the size is not a problem and neither game/server loading will be. And it can act as a framework for anyone who would like to rework this and provide an unique model for each item (such as different buckle on various belts). The biggest problem of this approach is probably that any future modification in the ground model will be a hell to add into all these models... Opinions on this subject?

 

EDIT: completely forgot, I added a module switch to enforce "roll only once per target" devastating critical behavior. The question is - is this desired to add into PC Widget tool? to me it looks like 100% builder feature so...

               
               

               

                     Modifié par Shadooow, 20 juillet 2014 - 08:10 .
                     
                  

            

[Legacy_Gruftlord]

               Every builders feature should be on the widget imho. I do have a private monsters override hak file that includes all IMProvements with textures converted to dds. I can upload it and send you a link tomorrow. If you want tga textures, you can easily get them using nwnexplorer (reborn).


I do not know that glowing inventory mod, so i can not say anything about it.


Re groundmodels: this sounds horrible. If builders want to include the changes, they can as well just put the ground models in their haks. One more reason why the new permissions are a good thing
               
               

               
            

[Legacy_Shadooow]

               

 

Re groundmodels: this sounds horrible. If builders want to include the changes, they can as well just put the ground models in their haks. One more reason why the new permissions are a good thing

This was always approved. All the neccessary files are in builders resources in 'doa baseitems issue fix' folder.

 

It sounds horrible but this is basically how shields works. Other items just dont have the models. And as I said, it doesn't actually have any side effects,

               
               

               
            

[Legacy_Gruftlord]

               Well shield models do have a use as actual equipped objects, unlike the items you propose. If you are interested in going into this route, i know some modders have done precise ground models for potions and rings. I'd start there if this is something within the skope of cpp. As for boots and such, i think unless someone does make the varied models, you are overthinking things. I highly doubt the problem you try to fix with this has ever come up aside from your private testings.
               
               

               
            

[Legacy_MannyJabrielle]

               

I'm so-so about the inventory glow.  I was never fond of it.  Others may like it though, so I would only suggest having a "override" file for those of us who want to revert to a non-glow, much like how you had the default bioware spell icons available as a revert from the colored TAD spell icons.


Can't about the dev-crit beahvior toggle... at the moment I can't even think of any epic level SP modules besides HotU, and I rarely go for dev crit in SP.  I'm not sure I would even notice a 1 roll per enemy behavior anyway unless the module was built with non-crit immune enemies who had enough HP to last more than a few rounds against a high STR character and enough fortitude as well to make the save a decent amount of the time.

               
               

               
            

[Legacy_Shadooow]

               

Well shield models do have a use as actual equipped objects, unlike the items you propose. If you are interested in going into this route, i know some modders have done precise ground models for potions and rings. I'd start there if this is something within the skope of cpp. As for boots and such, i think unless someone does make the varied models, you are overthinking things. I highly doubt the problem you try to fix with this has ever come up aside from your private testings.

I realized that this would overwrote custom ground models like from Project Q so this cannot be done...

               
               

               
            

[Legacy_Shadooow]

               

Every builders feature should be on the widget imho.

Why? Builder should always set module switches by scripting or directly in Module properties. Though, now in 1.72 they will be persistant if DM sets them using PC Widget Tool - nevertheless I though that DM shouldn't need to modify rules ingame...

 

Can't about the dev-crit beahvior toggle... at the moment I can't even think of any epic level SP modules besides HotU, and I rarely go for dev crit in SP.  I'm not sure I would even notice a 1 roll per enemy behavior anyway unless the module was built with non-crit immune enemies who had enough HP to last more than a few rounds against a high STR character and enough fortitude as well to make the save a decent amount of the time.

This is problem on Persistant Worlds where builder basically cannot make an important or ultra tough creature such as boss not immune to critical hits. Otherwise she die on devast in three rounds no matter how high fortitude she has - also big problem in PvP where peoples were doing builds like monk sorc rdd only with the only intent - run, run, run, hit-run anything on the way and run again. Etc. In such environment the devast once per target should be the best way how to balance it and yet keep it still intact (DC etc.). Thus this is something a builder would want and builder can do that manually or via scripting. So he shouldn't need this option in PC Widget Tool and ordinary player has no intention to use this.

               
               

               
            

[Legacy_Shadooow]

               

working on new version I had another idea:

 

since CPP constantly adding a new AI improvements and fixes which needs to recompile nw_c2_default and nw_ch_ac* set of scripts I had two thoughts how to solve this so builder could modify these scripts and not have problem with newer updates. This can be easily fixed by recompiling all scripts but that can only builder not player playing SP module.

 

idea 1:

detach the combat AI into new script and change the creature event script to ExecutScript instead - this will allow to modify AI without need for recompiling creature event scripts - might be also bit more efficient, logically it makes the creature events lighter and the comabt AI will be now cached in new script - at any way it won't be worse

 

idea 2:

Implement a creature tag based scripting. So builder can make a script that will look like this

 

sh_firemental.nss (since creature tag is "sh_firemental")

void main()
{
int nEvent = GetUserDefinedEventNumber();
 if(nEvent == CPP_CREATURE_EVENT_ONSPAWN)
 {
 ApplyEffectToObject(DURATION_TYPE_PERMANENT,EffectDamageShield(1,DAMAGE_BONUS_1d6,DAMAGE_TYPE_FIRE),OBJECT_SELF));
 }
}

will apply a fire damage shield effect after creature spawns

               
               

               
            

[Legacy_Shadooow]

               

Another thing. Maybe you noticed I am using a prefix 70 for all scripts no matter of the CPP version they comes from. It seemed to me as easier to find and understand than having 70_ 71_ and 72_ - also I think its a bit too late now to rename scripts from 71 to 71_ prefix. But if that matter I can rename at least the 72 original scripts.

               
               

               
            

[Legacy_MannyJabrielle]

               

This is problem on Persistant Worlds where builder basically cannot make an important or ultra tough creature such as boss not immune to critical hits. Otherwise she die on devast in three rounds no matter how high fortitude she has - also big problem in PvP where peoples were doing builds like monk sorc rdd only with the only intent - run, run, run, hit-run anything on the way and run again. Etc. In such environment the devast once per target should be the best way how to balance it and yet keep it still intact (DC etc.). Thus this is something a builder would want and builder can do that manually or via scripting. So he shouldn't need this option in PC Widget Tool and ordinary player has no intention to use this.

Understandable.  And yeah, as I said I don't go for dev crit often in SP, but I just don't see a need for a switch for it... Definitely a PW thing which the player can't fuss with widget wise anyhow.


I was actually consider removing dev crit from my SP module's later epic level chapters.  On one hand it could really make certain encounters way too easy, on the other, the player's choice in taking it really.  The 1 roll per is a nice feature actually, will keep it in mind when I get to actually building the epic chapters.