919 réponses à ce sujet

[Shadooow]

looks very nice - no problem with moss, the moss actually fits the CPP scope - keep standard look but improve (yes I realize that few new spell icons are breaking this rule]

[Shadooow]

Both me and my brother are huge fans of the shapeshifting - but the weird item/feat scaling always kept us from actually being good at it xD

 

If you could please make it so that regular players (like myself) can "switch" it so that all shapeshift/polymorph forms 100% scale from all items and feats (even in the original bioware campaigns/expansions) - THAT WOULD BE AMAZING!!!

I can do almost everything. Turn this game to 3.5 DnD ruleset, Pathfinder ruleset or even Diablo2 ruleset. Modify every game asset as I want.

 

But thats not what I do - this project has a given scope and theme. So every modification I am going to implement I must ask and clarify whether its in the patch scope and theme or not. Additionally, I don't think I can steal other projects focus - for example I don't think this project should be attempting to include every NWNX features that are publicly available such as new scripting events, new scripting functions, extended weapon modifications (such as setting which weapon is finessable etc.) or database connectivity. I could put all this into single plugin, but I believe that it would only ****** all these peoples who made these features - or anyone who prefer have everything detached (see the whole issue about peoples who want to use CPP features and content but do not want to use patch itself).

 

Furthermore - speaking of optional game features like switches - there are other things that needs to be taken into consideration.

 

First - the number of switches itself - it is not appealing to give one hundred switches. Will only make a mess and confusion and bother most players and lead into all those issues that similar modifications like NWN CPP (Homam3 WoG, Jagged Alliance 1.13, Baldurs Gate WEIDU mods to be specific) all suffer - too many options and player is more changing them then playing game - especially in all these three games many options persist in savegames and requires new replay to disable them if you find you don't like it. I want definitely avoid this.

 

Second - if its in patch scope again and also, what is a relative effort needed to make this feature externally. Which is the case of the "all items merging for all shapes" modification. The question is whether this should be part of the CPP itself or should I make it externally as an override that player downloads? Because this feature can be accomplished easily by polymorph.2da edit. This is the reason why I hesitate with making this feature inside CPP - need suggestion/opinions which are not coming...

[Bogdanov89]

I do not have any experience building modules or playing on PW, so i really have no suggestions to share with you

 

My honest opinion is that the "vanilla" druid/shifter/wizard shape-shift/polymorph is rather bad, overcomplicated and weak.

There are some useful forms but 90% of them are just flat out baaaaad.

 

I think the "all items and all feats merged into all shapes/forms/polymorphs" should be inside the CPP - it is bioware's fault for not designing the class like that from the beginning.

 

To me it makes absolutely no sense for most of those forms/shapes/polymorphs to be so damn weak and overcomplicated for no benefit what so ever...

[Gruftlord]

new files here:

http://www.file-uplo...-140713.7z.html
 

new barkskin in 512 (original texture resolution) with color fixes by me, alternatives included: 1024 and 64 (vanilla barkskin resolution, lol. 64 version os without moss, because it would just be a green blob anyway).

improved belt texture

key grondmodel mdl file with new texture

 

regarding polymorph merge: i think bioware had a reason why they only merged certain  items, there seems to be a guideline behind it. it might be a nice addition or separate mod, but i do not see it as a clear "must have" for CPP, since while the shifting abilities are weak, they are not necessarily broken. like most abilities in NWN their usefulness varies with the magic level of the setting, and there are servers, that ban the shifter class, because it would be too owerfull for PWs with magic level <= +3

[MannyJabrielle]

I agree with Gruft that credit should be given... it should be a matter habit even.  In my module, I have several bits which I cannot remember where I got them (although I do remember I pulled them from open projects), and in my credits text, that's made clear and a "please tell me who the creator was" line added in lieu of creator name... It's really no trouble for a module/cc maker to give proper credit whenever possible.  A txt with the download or packaged within a hak never harmed anybody.

 

And as for switches, I agree that hundreds are a bad thing.  So far I think we only touched on 2, maybe 3 things considered for a switch?  IMO switches should be for things which make a definitive change from the norm for gameplay in SP mode for the non-modding player/DM benefit, but not bug related changes (example, spell X was bugged and didn't work right/as intended, CPP fixes that, not a switch candidate).  I think I've scrounged through every item listed in the current readme, and gone through the patch key looking for anything that wasn't mentioned in the readme.... (which is a lot of content) I think I found only 2 or 3 items I initially considered good candidates for switches.  Certainly not hundreds though

[NWN_baba yaga]

Hey Shadooow,

 

have you changed the waypoint system too or can i use an advanced waypoint system i found and think will use in the future?

[Shadooow]

Hey Shadooow,

 

have you changed the waypoint system too or can i use an advanced waypoint system i found and think will use in the future?

I added a new flag to allow circular path but thats it. It has no new features except that so try either NPC Activities 6.0 or meaglyns Advanced Walk Waypoints.

 

I dont have in plan adding such features into patch as I think its out of its scope.

[NWN_baba yaga]

Yes meaglyns system is what i use. Great stuff btw!

 

So thanks for the answer and will use your patch then

[Shadooow]

I agree with Gruft that credit should be given... it should be a matter habit even.  In my module, I have several bits which I cannot remember where I got them (although I do remember I pulled them from open projects), and in my credits text, that's made clear and a "please tell me who the creator was" line added in lieu of creator name... It's really no trouble for a module/cc maker to give proper credit whenever possible.  A txt with the download or packaged within a hak never harmed anybody.

 

And as for switches, I agree that hundreds are a bad thing.  So far I think we only touched on 2, maybe 3 things considered for a switch?  IMO switches should be for things which make a definitive change from the norm for gameplay in SP mode for the non-modding player/DM benefit, but not bug related changes (example, spell X was bugged and didn't work right/as intended, CPP fixes that, not a switch candidate).  I think I've scrounged through every item listed in the current readme, and gone through the patch key looking for anything that wasn't mentioned in the readme.... (which is a lot of content) I think I found only 2 or 3 items I initially considered good candidates for switches.  Certainly not hundreds though

Cool I want to hear what are those.

 

btw - you still didn't answer my question about the continuous flame - what functionality is desired from player's perpective? should this spell be used to increase cost of the loot you are selling or not? Cos now when I made the possibility to use Item Cost Parameter itemproperty in NWScript - I realized how to decrease cost easily and dynamically (well it will be ugly code but will work). If a player didnt had CPP nothing happens and the cost won't be altered. (desired ? not?)

[MannyJabrielle]

I'm thinking leave it raising price of sold loot and without the flag change.  Builders can edit their 2da or spell scripts or merchants for their modules to address their module's economy issues.  Any given 'player' might have modding ability, but I think it would be safer to assume the average player doesn't script or edit 2das.  If the flag could cover black market merchants as well, that would be great a new switch for DM's setting up a quick OC run over lan or net.

 

Clunky for dynamic price shifting?  The dynamic part sounds intriguing, the clunky code sounds worrisome.

And I"ll dig up the other item later tonight when I get home  This CF item was one, the other I gotta look over again and decide if it was something that was worthy to bring up or if it was an initial impression that it could be.  Been a bit busy for me lately, sorry for the delay

[Bogdanov89]

I am a bit confused about this Continual Flame spell... it just adds a permanent light effect to your current weapon?

 

Honestly, to me that spell looks more like just flavor and esthetics than an actual useful spell...

Overall seems utterly useless for any combat purposes.

 

You can just as well completely delete that spell and no one would notice.

 

Actually, the only players who would notice are the ones that were using it to make pretty much infinite gold.

 

And making infinite gold through an unlimited low level spell was definitely not the intention of Bioware - it makes gold and losing gold completely irrelevant.

 

Just make it so that it can not be used for the unlimited money abuse... that spell has no other purpose anyway.

[MannyJabrielle]

I'd have to disagree.

 

I actually do use the spell with my non-elf/halforc/dwarf casters.  In SP, I find it incredibly useful to add permanent light to my favorite armor and free up a ring slot which would hold a ring of cyan/crimson/ect.  Plus, I prefer white light to any of the other shades.  It's just easier for me to see.  Plus, I actually use lv-0 spells for combat, so I prefer permanent lightsources over recasting light over and over again.

 

As for online, the PW I play on has tweaked the spell to add an extremly long lasting temp property which persists through rests rather than a permanent property.  I would vote for that same method with the spell in the CPP, but Shadooow said that was a route he didn't want to take, and it's 100% understandable.

 

As for it only being used by money horders to generate money, not it's actual purpose.... you can't have it both ways.  The spell adds light to a worn object.  That is it's actual intended purpose.

What wasn't intended probably was the by product of the OC's where players could if they chose to, buy loads of plain items, sell them back enchanted for money.  However, you are ignoring the fact that the sheer amount of GP you can get in the OC's is *not* because of the spell, and it's blatantly obvious when even a barbarian with 0 appraisal, no UMD or casting ability can walk of of NWN chapter 4 with around 1,000,000 GP.  That's shitty module design on bioware's part.  And it's not required builders follow that design of massively uber loot coupled with unrestricted resting and unlimited GP merchants who sell unlimited copper rings.

 

Bioware made gold irrelevant in the OCs WELL before they introduced the spell with the first expansion pack

The really troublesome thing about making a statement such as "no player does X" or "the only players who do X are this" because you don't do it or you aren't this or that kind of player is is well, fallacious.  Even if you don't do it and the people you regularly play with don't do it, you really can't make such a confident claim about *all* players.

And as Shadooow mentioned earlier in the discussion.... really, if someone wanted infinite GP, DebugMode 1, dm_givegold, DebugMode 0.

 

And let's be honest, if you're going to insinuate something negative about the character of other players, at least don't double down and make the implication that they're too dumb to use the console command to get infinite gold as well.  The player looking for the "easy route" is going to use the console for infinite gold, even the stupid ones.  So is it that you don't like the spell because you think of it as easy money?  Module design easily takes care of that.  Mods with restricted rest solve it, mods with material spell components solve it (and even make it a LOSS to enchant your copper rings given the price of the CF material component), mod which don't have merchants with unlimited gold solve that.... half a thought into module balance will solve it.

 

And those wanting easy money are not going to waste hours of their time raking in millions of gold 150 to 200 GP at a time selling a couple of lit up copper rings, resting between on average 2 to 6 casts per rest, maybe more if they take the time and effort to use metamagic slots.... and if a player DOES want to waste hours of their time doing that instead of console.... so what?  Honestly, so what?

But yeah... please stop making baseless insinuations against players who do use the spell as intended, who aren't "shitty players farming unlimited effortless gold and abusing stuff" by using a few spell slots to get a few extra GP out of the loot they actually yes, put effort into getting.  It tends to get rather tiresome sometimes.  Speaking as a player, a DM and a builder, especially for the latter two, I have found that what appeals to me does not necessarily appeal to others, and vise versa, and knowing what the rules of the game actually are helps in having fun with the game, not annoying others with the game.

[MannyJabrielle]

Yes, sorry, long winded, I just type a lot sometimes

And yes, I'm one of those rare players who actually plays PDK's too, so <raspberries>

[Bogdanov89]

Text changed (irrelevant to CPP), as requested by ShadoOow.

[Shadooow]

But yeah... please stop making baseless insinuations against players who do use the spell as intended, who aren't "shitty players farming unlimited effortless gold and abusing stuff" by using a few spell slots to get a few extra GP out of the loot they actually yes, put effort into getting.  It tends to get rather tiresome sometimes.

Yea, one player that was caught duping items on a PW I used to play used the same excuse. Really not good one .

 

Anyway. I introduced this because I was always playing and even building PWs and this was something that players always abused, the PW admins solved that usually by banning, changing spell do nothing, adding chance 50% of destroying the item, adding stolen flag or even plot flag or making the spell temporary. Everyone building a PW sooner or later run into this issue and I wanted to CPP provided a solution for those who will yet start building so they can skip this proccess. Seriously - if you do not know this gold trick, and you build a module without that in mind it can be later quite difficult and time expensive to balance that (by the techniques you speak MannyJabrielle). I don't think that what is bad design is not the stores in the official campaigns but the spell itself.

 

Got possible solution btw. It is easy to distinguish a multiplayer environment in script so I can reduce the cost only in multiplayer environment. That will solve the issue on PWs and let players freely abuse it when playing OC or any other SP modules. Because yes, we cannot expect a player has modding abilities and if this is something that players would seek a restore switch - it seems better to me not to change it for them.

[Bogdanov89]

Good morning (or good evening) ShadoOoW

 

Great news that the deadly Continuous Flame spell is going to be under control!

 

 

On a serious note, did you perhaps decide about the "all items/feats merging for all shapes/polymorphs/forms"?

 

It would probably be better off as a switch for the reasons other people mentioned earlier in the thread - but i am really looking forward to switching that ON for my games!

[Shadooow]

On a serious note, did you perhaps decide about the "all items/feats merging for all shapes/polymorphs/forms"?

 

It would probably be better off as a switch for the reasons other people mentioned earlier in the thread - but i am really looking forward to switching that ON for my games!

Yes, I am going to include this as a module switch inside PC Widget Tool. To add this doesn't harm anything and while players could get this externally and put this into override - that way if anything changed in polymorph.2da in future CPP versions, the version they added into override would overwrote that.

 

Also, when trying this I added also a new feature (which is automatical) to merge weapon item properties onto skin if weapon is allowed to merge. This issue raised when I allowed to merge everything since most shapes are unarmed. While the combat abilities wont be of course functional, it will merge every defensive properties from the weapon such as ability bonuses, bonus feats, spell slots etc. - simply the properties that are expected on a magic staff for example.

[Bogdanov89]

Okay, how about an enhancement on a weapon (greatsword +5, for example)?

Would that +5 work in shape/polymoprh even if your current form is unarmed?

 

I do not understand what the phrase "merge onto skin if weapon is allowed to merge" means.

 

First, what does merging with the skin mean?

 

Second, which weapons are allowed to merge? I thought all weapons would be able to merge?

 

I do not fully understand the shapeshift/polymorph mechanics, but in your future update of the CPP (with the "all merge" switch on) how would a druid/shifter (or wizard) increase his damage/attack and damage-reduction penetration while in a form that is "unarmed"?

[Shadooow]

Okay, how about an enhancement on a weapon (greatsword +5, for example)?

Would that +5 work in shape/polymoprh even if your current form is unarmed?

 

I do not understand what the phrase "merge onto skin if weapon is allowed to merge".

 

First, what does merging with the skin mean?

 

Second, which weapons are allowed to merge? I thought all weapons would be able to merge?

 

I do not fully understand the shapeshift/polymorph mechanics, but in your future update of the CPP (with the "all merge" switch on) how would a druid/shifter (or wizard) increase his damage/attack and damage-reduction penetration while in a form that is "unarmed"?

no

 

Okay. By default every shape has a creature skin that you receive. This is just like an armor but its not visible to player, but it might have some properties such as elemental immunities. And the merging process is copying the normal item properties onto this skin. Weapon is however different, weapon item properties are merged onto new shape weapon which unarmed shapes doesnt have so it fails. There is where I applied my adjustion - if the shape doesnt possess weapon, then weapon is merged onto skin just as any other items.

 

Not sure what you mean, by default the weapon is allowed to merge only on a shapes that has a new weapon (minotaur, cobold, drow... but not tenser (tenser is magical polymorph that is not that advanced as druids so it shouldnt merge anything)). So the issue above doesnt happen. Now, with the switch I am going to include, weapon will be allowed to merge even for shapes without weapon.

Or if you ask on what type of weapon etc. its actually any object you are holding in right hand except that if its ranged weapon then it will be allowed to merge only if new weapon from shape is also ranged (which is none by default so this fails with ranged weapons - standard feature and intent). Off-hand weapon is never merged and CPP didnt changed this.

 

Well, the damage reduction is the part which is very weird concepted on polymorph. The unarmed shapes aren't actually unarmed, they possess a creature weapon(s) - invisible weapons which might have some properties such as damage. But creature weapons do not function in regards to damage reduction as their normal counterparts. Instead the creature (or sometimes called natural) weapon's penetration ability is determined by the character's own damage reduction.

 

In other words. You are druid without any items or buffs and you polymorph into bear - your attacks are treated as +0. Now, you cast a stoneskin spell on yourself and repolymorph into bear - suddently your attacks are treated as +5!!! This is especially weird with Epic Warding and mages' polymorphs (its one of the tricks how to kill demilich btw). To increase damage, only spell buffs and itemproperties adding strength will help. And I don't plan to allow gloves/weapon to merge onto creature weapons - that would need a new switch because this could bring some balance issues - the damage of the unarmed shapes really aint that bad - as long as you haver a damage reduction on your gear or as buff so your attacks penetrate enemies' damage reduction.

[Shadooow]

BTW, White Tiger posted me a shifter system he is using to me to find out if CPP can replace it. Thought I share this observation to everyone following this thread.

 

Its named Improved Shifter and Druid Wildshape by Iznoghoud

 

it has several features, will dismantle all:

 

1. fix for damage calculation in wyrmling breaths (outdated, 1.69 fixed that, the script in there actually has its own issue as it doesnt apply "versus" part for the save)

2. fix for damage calculation in azer stream ability (fixed in 1.70)

3. stacking merged ability bonuses, skill bonuses, saving throw bonuses, damage immunity bonuses and penalties (first added in 1.71, skills and saving throwns added recently in 1.72beta, damage immunity missing in CPP - didnt know about this if this doesnt really stack I will add this in next 1.72beta)

Though, got to say that CPP does that in better fashion - this system adds everything as a effect together with polymorph so player see all those effects in effect list - CPP doest this invisibly.

4. stacking AC bonuses, that is every AC bonus applies with its original type, this is normally transfered all to deflection so only highest applies (CPP doesn't offer this feature)

5. merging offensive weapon (or gloves) properties onto creature weapons, disabled by default toggleable (CPP doesn't offer this feature)

6. merging PC skin properties into polymorph (CPP doesn't have this feature but I will add this into next 1.72beta, very nice idea)

7. remerging item properties after character is saved. - this is very bad, cannot recommend, the way it works it needs builder to incorporate code into every script using ExportSingleCharacter function, then it reapply the polymorph completely = cancel all current actions, cast polymorph spell again (even if player no longer has it), reinitiate attack action. Very very bad, for example, player can (unintentionally cancel this).The new polymorph engine offers this feature, is partially independant on module scripting (works as long as module uses default module event scripts), automatic and doesn't recast polymorph (which prolongs the duration). Except that it actually solves the prolonged duration and works also anytime a player initiate saving character on his own (where this package does nothing).

8. A message is given to PC as which items merged (CPP doesn't offer this feature).

9. Some ranged weapon support for custom polymorph. Haven't tried to make such polymorph so I don't know what issues they suffer. Will look into that and it its real I add it into CPP.

 

BTW this system is a it outdated as it doesn't have a horse mount check to disallow polymorphing - which is the reason that White Tiger contacted me in first place - resulted in issues with "permanent horse".

 

Anyway, overally this system is nice and was probably the top back then, but the new polymorph engine I made outshines this even without the extra merging features. The additional CPP polymorph features:

- better re-merging handling

- fixing prolonged duration after repolymorph

- fixing temp HP stacking and replenish

- fixes losing spell slots from ability bonuses

- fixes the casting in polymorph exploit

- dying after unpolymorph (but this is something this system solves - couldnt verify but probably yes)

- OnPolymorph event for builders

 

Conclusion: as long as you don't want to merge weapon properties into unarmed shapes and don't want to stack AC, you are better using new polymorph system from 1.72beta.

If you do need these features, well take this. Or convince someone to modify CPP polymorphing and add these features for you so you can have the best from both worlds.

[Gruftlord]

I do think 4 and 5 are really nice options. The non propper merging/stacking of ac is one of the most annoying things with shifters. (Ac is still way too high because of monk exploit, but that is a separate question)

I am not sure immunities stack at all when unpolymorphed, so i do not know if it is needed for polymorph.

PC skin is sometimes used for subrace systems to apply racial features. It would be illogical to have them merge into other shapes (because they include a race change). Something to keep in mind.

Creature weapon damage penetration being linked to creatures own damage resistance: that one sounds like a bug to me. Or maybe it was something done on purpose because they didn't want to or couldn't merge weapon features. Not sure about it.

[Shadooow]

I do think 4 and 5 are really nice options. The non propper merging/stacking of ac is one of the most annoying things with shifters. (Ac is still way too high because of monk exploit, but that is a separate question)

I didnt included these because I personally feel they are not needed and are overpowered. AC sucks, but if you add one level of monk you are at 50 with cobold, 70 with rakshasa and 85 with dragon. If you get even shield ac on top of that... But whatever you or I think about monk ac in polymorph this is something a CPP mustnt touch. Any kind of monk ac decrease in polymorph would seriously affected already existing characters and their gameplay.

 

Weapon properties onto creature weapons are similar case, this is even something I cannot justify personally - how would such flame fangs look like? enhancement is one thing but elemental bonuses on claws/bite weapon other.

 

As for PC skin. Yes custom subrace bonuses are what I though of, though I though its actually logical to add them to polymorph. But you are right its nonsense the more I think about it the more I realize this.

 

Well its very weird but its correct per the DnD manual. Whether spell buffs should also count towards this is a question but otherwise speaking of the items - the main reason might be to avoid making dozens of weapon version 1d6 +1 / +2 /+3 / +4 when it can inherit the penetration from the damage reduction on skin. Otherwise they are allowed to have the enhancement bonus and other properties and it is possible to merge them, and to change this behavior is not possible without NWNX at all. The damage reduction buffs will always work this way.

[MannyJabrielle]

Non direct CPP content edited as per request. 

[MannyJabrielle]

Yea, one player that was caught duping items on a PW I used to play used the same excuse. Really not good one .

Really not the same thing  Selling items and duping them just are not in the same category, even if the CF spell was used in the process of duping somehow.

 

 

 

Got possible solution btw. It is easy to distinguish a multiplayer environment in script so I can reduce the cost only in multiplayer environment.

That sounds brilliant.  How's that work?

 

 

And I found my notes on the other item I considered as a switch candidate.  It was the curse song with invis/GS change.  Reason I considered it was in tabletop, I don't think bard songs break invisibility, or improved invis (at least imp.invis...), but I can't find my DnD books at the moment.  But then again, NWN doesn't implement imp.invis quite like tabletop anyway, so probbaly not worth considering whatsoever.

 

And another couple documentation questions...

 

On the notes on changes to fear aura and other misc. fear effects, says that the effects scale.  What does that mean exactly, those lines in the documentation could probably be clarified a bit.

 

The gt.neverwinter.cz version of the readme.... "Artist feat adds a +2 bonus to the persuade skill as well. Also, prerequisities now list need for a perform skill."  What does that mean about prerequisite for a perform skill?  In-game, it says "perform skill" under the pre-reqs, BUT, it's still selectable with 0 perform skill.

If it's supposed to actually check for perform skill, that might be a bit odd.  It would be the only +2 skill type feat with a requirement.  All the other level 1 only feats with +2 don't have a skill requirement, nor does the stealthy feat (+2 hide/ms).  Plus, making perform a requirement would block non-bard PCs who take artist for the +2 spot bonus.

 

Had another question on UMD style perform check for musical instruments.  Is the switch either one of the possibilities, or could both be set if a builder wanted to really make bards have a rough time?  I haven't quite had time to build a test module with the switches on to test it out.

 

And a polymorph related question... "cured from horse include while retaining the shape shifting horse check"  What does this one mean exactly?  Could be cleared up a bit.

 

And lastly.... Nearly done with the documentation re-write.  You want it in txt form first to look it over before I put it into the PDF format as well, or would you be able to edit PDFs for any possible errors I made in the text?  Not much as changed really, mostly just re-wording of some parts to make it a bit clearer to the average reader, will be adding screenshots as I take them.

[Shadooow]

 

That sounds brilliant.  How's that work?

GetPCCDKey returns FALSE is SP - so if that happens I will reduce the cost of the item - making itemproperty temporary cannot be used globally since it could be easily removed as part of the "remove all temp properties" script on PW/SP module.

 

 

And I found my notes on the other item I considered as a switch candidate.  It was the curse song with invis/GS change.  Reason I considered it was in tabletop, I don't think bard songs break invisibility, or improved invis (at least imp.invis...), but I can't find my DnD books at the moment.  But then again, NWN doesn't implement imp.invis quite like tabletop anyway, so probbaly not worth considering whatsoever.

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.

 

On the notes on changes to fear aura and other misc. fear effects, says that the effects scale.  What does that mean exactly, those lines in the documentation could probably be clarified a bit.

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. This feature however wasnt brought into every spells - which I correctted. Also the feature had several issues which I fixed, see here (from 170scriptfixes.txt - i think this is not online anymore unfortunately)

GetScaledDuration - removed check if duration is higher than 3, reason is that npc
with 3caster levels had longer spells than npc with 4caster levels
values in parenthesis means how it was before this change
duration / easy / very easy / normal
1        / 1 (1)/ 1 (1)     / 1 (1)
2        / 1 (2)/ 2 (2)     / 1 (2)
3        / 1 (3)/ 3 (3)     / 1 (3)
4        / 1 (1)/ 1 (1)     / 2 (2)
5        / 1 (1)/ 1 (1)     / 2 (2)
6        / 1 (1)/ 1 (1)     / 3 (3)
7        / 1 (1)/ 1 (1)     / 3 (3)
8        / 2 (2)/ 2 (2)     / 4 (4)
9        / 2 (2)/ 2 (2)     / 4 (4)

GetScaledEffect - added immunity check for fear effect, previously at low
difficulty, fear/mind immune PC that should been struck with fear was struct with
attack penalty which bypassed the immunity

In 1.71 I fixed the substitue for fear effect which was coded incorrectly (negative value in the argument resulte in invalid effect) and added a new feature to overwrite the default duration scaling by 3 rounds based on a module switch (which I do personally use every time btw).

 

 

The gt.neverwinter.cz version of the readme.... "Artist feat adds a +2 bonus to the persuade skill as well. Also, prerequisities now list need for a perform skill."  What does that mean about prerequisite for a perform skill?  In-game, it says "perform skill" under the pre-reqs, BUT, it's still selectable with 0 perform skill.

I took this info and exact wording from NWNWiki: http://nwn.wikia.com/wiki/Artist . Yes 0 rank is enough, but nonbards doesnt  possess any rank because this skill is by default available only to bards.

 

Had another question on UMD style perform check for musical instruments.  Is the switch either one of the possibilities, or could both be set if a builder wanted to really make bards have a rough time?  I haven't quite had time to build a test module with the switches on to test it out.

Only one of the option can be active at the same time. Just a note - I wouldnt used the perform check without 3.5 perform skill change that makes this skill available to everyone - ie. no longer needs training. Because normally anyone other than bard can use it via UMD. But once you make such change this feature fits perfecty. The second choice is even worse and I included it only because there is an vanilla item that is dependant on a bard song feature (Lich lyrics). 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.

 

 

And a polymorph related question... "cured from horse include while retaining the shape shifting horse check"  What does this one mean exactly?  Could be cleared up a bit.

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.

 

 

And lastly.... Nearly done with the documentation re-write.  You want it in txt form first to look it over before I put it into the PDF format as well, or would you be able to edit PDFs for any possible errors I made in the text?  Not much as changed really, mostly just re-wording of some parts to make it a bit clearer to the average reader, will be adding screenshots as I take them.

txt would be nice