919 réponses à ce sujet

[Shadooow]

R-TEAM wrote...

Hi,

NWN Grimoire V3 -> http://nwvault.ign.c...r.Detail&id=729

Regards
R-TEAM

oh this! Well there might be same problem  as on wiki, the Community Patch isn't accepted by majority of the custom content part of the NWN community. Have you tried to contact the original author? If the original author is gone from NWN your best chance to see this happen is to do it yourself. I cannot do this. My english is not good enough and it would be also conflict of interest.

[Bogdanov89]

About the spell Find Trap in NWN 1.71 RC3.

First, it actually has a pretty damn small range, which is nowhere near "Colossal".
The other Colossal spell, Knock, has at least 3 times bigger radius than Find Trap - so either the spell's range needs to be increased, or the tooltip is incorrect about the range.

Second, i have never actually seen this spell disarm traps.
It does MARK the traps with the usual red color, but it never removed a single trap in NWN original campaign (chapter 2).
Text says "... and are disarmed." - but that just never happens, and i am not sure what is it all about.

[Shadooow]

Find traps
- innate level was incorrectly set to 3
- won't reveal undetectable traps anymore, won't disable undisarmable traps anymore; at DnD rules and higher difficulty setting, the spell no longer disarm traps at all

[/list]Normally it does disarm traps indeed, but this is what CP changed. You have to play on lower difficulty if you want this behavior. Since it still might disarm them I havent changed the description, do you think its better to change it? (And no it is not a good idea to write there about the difficulty difference so either it disarms traps or not anymore.)

Range is actually way greater than colossal and CP didnt changed it, its 30.0 units of nwn distance while colossal is 10.0.

Modifié par ShaDoOoW, 28 janvier 2014 - 03:47 .

[Bogdanov89]

ShaDoOoW wrote...

Find traps
- innate level was incorrectly set to 3
- won't reveal undetectable traps anymore, won't disable undisarmable traps anymore; at DnD rules and higher difficulty setting, the spell no longer disarm traps at all

[/list]Normally it does disarm traps indeed, but this is what CP changed. You have to play on lower difficulty if you want this behavior. Since it still might disarm them I havent changed the description, do you think its better to change it? (And no it is not a good idea to write there about the difficulty difference so either it disarms traps or not anymore.)
Range is actually way greater than colossal and CP didnt changed it, its 30.0 units of nwn distance while colossal is 10.0.

I did not know that, also i thought all the Colossal spells had the same range - seems the "Find Trap Colossal" is not the same as the "Knock Colossal" ^^

Wikia says that the spell Cloudkill suffers from the following bug:
"Creatures that block the death effect (from immunity to death magic) will not suffer the movement speed decrease nor the initial acid damage. This is likely an oversight."
Has the Community Patch fixed that bug?

Modifié par Bogdanov89, 28 janvier 2014 - 04:59 .

[Shadooow]

Bogdanov89 wrote...

Wikia says that the spell Cloudkill suffers from the following bug:
"Creatures that block the death effect (from immunity to death magic) will not suffer the movement speed decrease nor the initial acid damage. This is likely an oversight."
Has the Community Patch fixed that bug?

yes

[Bogdanov89]

About the Defensive Stance (dwarven defender class):
http://nwn.wikia.com...efensive_stance

On that page there are a lot of notes about the Defensive Stance bugging, stopping, breaking and failing due to various circumstances.

Have those issues been fixed in the community patch?

Addition:

"Evard's black tentacles" also suffer from a number of bugs, as listed on the:
http://nwn.wikia.com...black_tentacles

Have those bugs been fixed in the community patch?

Addition 2:

Since i installed NWN (patch 1.71 RC3) the companion's AI has been really unreliable.
Has the community patch done any changes to the AI of the companions?
Anything that might have caused companion AI to become extremely unreliable?

I wrote a detailed description of the AI issues i am encountering in a different thread, so i will copy/paste them here for refference:

"Sometimes companions will charge far far ahead and attack without any command from me.

Sometimes they will not attack until i give the "Attack Nearest" command, even if I or they are being attacked by enemies.

Sometimes they refuse to follow and just stand in one place, regardless of the follow distance agreed to in the conversation.

Sometimes they will simply stand still and not do anything during combat (they
are not stunned/dazed/paralyzed) - they will even ignore my Attack
Nearest command, they will ignore all enemies attacking them or me...

Quite often the Cleric companion will actually "forget" to cast her healing
spells when my health drops below the "agreed threshold" that i set up
by talking to her.

Quite often the cleric/bard companions will
cast buffs as soon as they see enemies, which usually means no one else is
close enough to be affected by those buffs.

I tried ALL the
options and distance settings available through the conversation with
companions - but it just does not help at all."

Modifié par Bogdanov89, 29 janvier 2014 - 06:02 .

[Shadooow]

Short answer, CPP fixes 99% of NWN bugs you ever heard of, quite a lot of them wasn't described on wiki when first CP version came and many still aren't up today. Has been defensive stance fixed? No - thats hardcoded, has been evard tentacles fixed? Yes of course.

Here is a list of known and still unresolved issues in NWN with CPP: http://social.biowar...scussion/80024/

As far as companions: CPP didn't caused this behavior, actually fixed lot of serious issues with them. I also noticed some of the problems you pointed but it is hard to fix this, or rather it is hard to determine how they should behave. I also noticed they often attack if I tell them Stay and Hold but is it a good idea to change AI so when you say *stay* they wont move at all? What if they are attacked? Etc.

This could be adressed by CPP but I need someone who has experience with this to help me. Until then I suggest you Tony K's companion's AI. Which should offer a lot of new choices and features that might help you with this.

Modifié par ShaDoOoW, 29 janvier 2014 - 06:50 .

[Shadooow]

ShaDoOoW wrote...

Bogdanov89 wrote...

I noticed the NWN wiki mentions quite a few bugs in Arcane Archer's special arrow abilities, like Imbue Arrow and Seeker Arrow and Hail of Arrows and Arrow of Death.

The exact wikia quote is: "This damage is intended to penetrate damage reduction according to the arcane archer's enchant arrow bonus, but a bug in the game (not the script) prevents this."

Have these bugs been fixed in the Community Patch?

Nope the damage reduction bug within the EffectDamage (which is technical name of the issue wiki describes and affect few other spells and abilites) wasn't fixed in CPP yet. Reason is that this is hardcoded into engine and not possible to fix, only workaround. And the workarounds for this are quite ugly. But I will look into this more closely.

Actually this ability should also add the damage from arrows and destroy correct ammount of arrows. But that would be balance change again and those are very hard to add/reason why they had to be added since many peoples complaints against them.

What Ive done for my PW is that Ive changed the ddamage type from piercing to magical which effectively "fix" this issue. This is not a fix in a true sense since monster can be immune to magic or mabe vulnerable which makes this problem again. But its often seen solution on many PWs.

Ok looked closely. This is impossible to fix without NWNX, only workaround I managed has a disadvantage that it doesn't work properly if module builder changes spells and their values or when he adds new spell. For those who can read scripts there is almost finished function for this workaroud:

int DamageReductionWorkaround(int nDamage, object oTarget, int nDamagePower)
{
 if(nDamagePower < 1) return nDamage;
int n,nReductionUnder,nReductionAbove,nSlot;
object oItem;
itemproperty ip;
 for(;nSlot < NUM_INVENTORY_SLOTS;nSlot++)
 {
 oItem = GetItemInSlot(nSlot,oTarget);
 ip = GetFirstItemProperty(oItem);
  while(GetIsItemPropertyValid(ip))
  {
   if(GetItemPropertyType(ip) == ITEM_PROPERTY_DAMAGE_REDUCTION)
   {
   n = GetItemPropertySubType(ip)+1;
    if(n < nDamagePower)
    {
    n = GetItemPropertyCostTableValue(ip)*5;
     if(n > nReductionUnder) nReductionUnder = n;
    }
    else
    {
    n = GetItemPropertyCostTableValue(ip)*5;
     if(n > nReductionAbove) nReductionAbove = n;
    }
   }
  ip = GetNextItemProperty(oItem);
  }
 }
effect eTest = GetFirstEffect(oTarget);
 while(GetIsEffectValid(eTest))
 {
  if(GetEffectType(eTest) == EFFECT_TYPE_DAMAGE_REDUCTION)
  {
   switch(GetEffectSpellId(eTest))
   {
   case SPELL_GHOSTLY_VISAGE:
    if(nReductionAbove < 5) nReductionAbove = 5;
   break;
   case SPELL_ETHEREAL_VISAGE:
    if(nDamagePower < 3)
    {
     if(nReductionUnder < 20) nReductionUnder = 20;
    }
    else
    {
     if(nReductionAbove < 20) nReductionAbove = 20;
    }
   break;
   case SPELL_SHADOW_SHIELD:
    if(nDamagePower < 3)
    {
     if(nReductionUnder < 10) nReductionUnder = 10;
    }
    else
    {
     if(nReductionAbove < 10) nReductionAbove = 10;
    }
   break;
   case SPELL_STONESKIN:
    if(nDamagePower < 5)
    {
     if(nReductionUnder < 10) nReductionUnder = 10;
    }
    else
    {
     if(nReductionAbove < 10) nReductionAbove = 10;
    }
   break;
   case SPELL_GREATER_STONESKIN:
    if(nDamagePower < 5)
    {
     if(nReductionUnder < 20) nReductionUnder = 20;
    }
    else
    {
     if(nReductionAbove < 20) nReductionAbove = 20;
    }
   break;
   case SPELL_PREMONITION:
    if(nDamagePower < 5)
    {
     if(nReductionUnder < 30) nReductionUnder = 30;
    }
    else
    {
     if(nReductionAbove < 30) nReductionAbove = 30;
    }
   break;
   case 695://epic warding
    if(nDamagePower < 20)
    {
     if(nReductionUnder < 50) nReductionUnder = 50;
    }
    else
    {
     if(nReductionAbove < 50) nReductionAbove = 50;
    }
   break;
   }
  }
 eTest = GetNextEffect(oTarget);
 }
 if(GetHasFeat(FEAT_PERFECT_SELF,oTarget))
 {
    if(nReductionAbove < 20) nReductionAbove = 20;
 }
return (nReductionAbove > nReductionUnder) ? nDamage : nDamage + nReductionUnder-nReductionAbove;
}

As you can see it actually increase the damage with the value of a damage reduction to overcome it. This is quite complex calculation and its not even fully covering all possibiities. I only covered the fixed reductions, there are several spellabilities that adds scaled reduction such as shadow evade or illithid inertial barrier. Therefore I think its better idea to make a change in the AA arrow feats (AFAIK only AA arrows have a damage penetration, other spells/abilities are treated as mundane weapon anyway).  Convert all their physical damage into magical is imo easiest and best way. The AA arrows are quite underpowered anyway. Also Im thinking about adding the arrow's damage into the effect but with a disadvantage of requiring to actually have some arrow which these feats in this moment doesn't. Thoughts and opinions welcome.

[Shadooow]

Lately Ive been slowly working on a better documentation for a 1.71 version, it still isn't finished but there is a preview:
Basic readme
Spell changes
Special ability and feat changes

BTW the red color implies that the subject was changed in the 1.71 and wasn't presented in the first version. If something is red and crossed it means it was introduced in the first version, but removed later in one of the 1.71 betas.

Im still looking for help with recoloring higher resolution of a nymph texture. And now I am also looking for a linux NWNX developer that would helped me to port my new NWNX Patch plugin (for server). And I would definitely welcome help with the windows plugins (both server and client) development as well.

Modifié par ShaDoOoW, 01 février 2014 - 08:55 .

[Gruftlord]

If you already have a texture you like but just dislike the color, i could once again try my luck with gimp. The barkskin texture turned out quite nice, despite my limited abilities.

[leo_x]

ShaDoOoW wrote...

And now I am also looking for a linux NWNX developer that would helped me to port my new NWNX Patch plugin (for server). And I would definitely welcome help with the windows plugins (both server and client) development as well.

What does nwnx patch do?

Also, I've noticed a couple things that could be fixed, is there a place specifically to submit bugs(bioware bugs)/bugfixes?

[Shadooow]

pope_leo wrote...

ShaDoOoW wrote...

And now I am also looking for a linux NWNX developer that would helped me to port my new NWNX Patch plugin (for server). And I would definitely welcome help with the windows plugins (both server and client) development as well.

What does nwnx patch do?

Hmm thats still not incorporated into readme.

Patch NWNX Plugin:
Fixes trident weapon focus bug.
Removes the limitation on weapon color from CopyItemAndModify function. (copied from Terra777's minipatch plugin)
Fixed the bug with a fact that immunity to the ability decrease prevented also ability decrease from equipped items.
Ability decrease immunity doesn't prevent from ability decrease effects from a curse on a DnD/Very High difficulty.

Patch NWNCX Plugin:
Fixes trident weapon focus bug.
Enables to select a nonstandard base classes at initial character creation.
Removes the limitation on weapon color from CopyItemAndModify function.

This is what I already have in my working version, at this moment only the NWNCX plugin is available and it doesnt have the weapon color feature. Atm im trying to port the immunity to ability decreases feature into client and Im working on fixing Circle Kick.

Also, I've noticed a couple things that could be fixed, is there a place specifically to submit bugs(bioware bugs)/bugfixes?

anywhere into this thread and I will incorporate them into my list of unresolved issues myself. Or send me a PM, anything. Better to send me the fix itself hehe.

Modifié par ShaDoOoW, 01 février 2014 - 09:25 .

[Shadooow]

Since new release is coming, would the users of this project welcome the addition of the ceilings into the vanilla tilesets?

I think its in the scope of this project as far it doesn't changes texture colors. The only problem I see is that the nonstandard tiles won't be affected which looks weird, but thats something the each such project suffers and I don't think it would have caused peoples not to use it.

(I am looking for suggestions of which project to import it from, aka is there a difference in the ceiling models from "Cave ruins, Natural caves, NWNCQ, Zwerks facelift" ? Hopefully, permissions won't be an issue there.

Modifié par ShaDoOoW, 04 février 2014 - 02:36 .

[Gruftlord]

i've seen quite a few different approaches to ceilings. currently i use Zwerkules' work, because i think it's the best. so while i wouldn't mind, i think it's outside the scope of a patch, and works quite well on its own as a hak extension. there is nothing wrong with missing ceilings in vanilla, as long as you do not unlock the camera. for me that crosses the line between bugfix and extension/overhaul. which isn't to say i wouldn't recommend everyone to use them.
zwerks models usually include a realistic ceiling, with wooden frame for roofs and narrow tunnels underground.
other, less detailed work i've seen included "skydomes" for underground (more like "dirtdomes with stalactites") which worked ok from a "at least there is something" point of view. and then there was this one version, that had flipped and mirrored models put on top as a rather odd looking fake ceiling. that one is a definatelly no-go

Modifié par Gruftlord, 04 février 2014 - 02:06 .

[Shadooow]

Gruftlord wrote...

i've seen quite a few different approaches to ceilings. currently i use Zwerkules' work, because i think it's the best. so while i wouldn't mind, i think it's outside the scope of a patch, and works quite well on its own as a hak extension. there is nothing wrong with missing ceilings in vanilla, as long as you do not unlock the camera. for me that crosses the line between bugfix and extension/overhaul. which isn't to say i wouldn't recommend everyone to use them.
zwerks models usually include a realistic ceiling, with wooden frame for roofs and narrow tunnels underground.
other, less detailed work i've seen included "skydomes" for underground (more like "dirtdomes with stalactites") which worked ok from a "at least there is something" point of view. and then there was this one version, that had flipped and mirrored models put on top as a rather odd looking fake ceiling. that one is a definatelly no-go

thanks for opinion.

Can you explain me why do you think such feature isnt in a scope of a patch? To me it seems to be, its not a new model only an improvement of the original one without changing textures. Main reason for this is my wish to ceiling become a new standard, while they still aren't. But I certainly don't want to substitude a overrides that doing this too, so I guess it in consideration only when the author of such package will want it to provide.

[Gruftlord]

think of it like this: there is a difference between: what would the designers have wanted to be fixed 10 years ago, and what would they want to include into a game nowadays.

by original design, they did not think ceilings are a must. maybe they needed to cut space because of disc limitations. maybe they didn't think it was necessary given the vanilla camera angle. maybe they wanted to keep the polygon count low because of hardware expectations back then.
would they decide differently today? most certainly.
but that is the question: does the CPP try to provide a fix for all the things that were not fixed from way back then, or do you see the CPP as a project to bring Neverwinter Nights into the 21st century?

it is certain, that you draw the line somewhere inbetween. so do i. i like the ground models and i think the colored spells icons and distiguishable immunity icons are a great addition to make things discernable with much more ease. especially given today's screen resolutions.
but where that line is drawn is ultimatelly arbitrary. a complete overhaul of most tiles with the attempt to add ceilings to all of them is way behind where i draw that line.

as i said, i use them myself. i would not want to miss them any more. i recommend them full heartedly to anyone. but some people would disagree with the visual change this addition would bring. it is at it's heart not a bug fix, but an addition. and a quite visually impacting one. i think that is, why i think a patch project would remain inviting for a larger audience, when not including such things.
ceilings may also hinder gameplay at times, so they come with a minimal drawback, unlike ground models for example. also comaring to the ground models again: personally i caught myself thinking when i first played the game: what a bag as groundmodel for all these things? come on....
unlike the ceilings. being the first step into 3d rpg (for bioware), with isometrc view the norm just a few year back, i wasn't expecting a ceiling anyway. i was too amazed by the fact i could rotate and tilt the camera. and i would have felt confused had things gotten in my FOV while doing so. (that brings another thought: fading features: the original programmers took great care to make extra sure everything was visible at all times with the fading feature. something they maybe felt a ceiling could not provide. i know most community ceilings fade much later than vanilla buildings and trees do. zwerks ceilings even keep the wooden framwork in interiors for nearly the whole screen. a feature i enjoy today, as i said.)

i summary: there is no definite answer as to why and where to draw the line. it comes down to: for how many people do you want to remain open. and what is the harm in keeping the ceilings and visual improvements as optionals the way they are?
if you are going to put together a nice documentation for 1.71, may i recomment a section: "The CPP recomments the following patch haks/overwrites, that go along nicelly with it's content" followed by links to the various improvements (zwerkules, monster mash, weapons redux, undead redux, IMProvements, varied groundmodels for rings and potions, translucent UI to name a few)

Modifié par Gruftlord, 04 février 2014 - 08:59 .

[Shadooow]

Gruftlord wrote...

...

Ok you are correct with the tilefade. For me as an action-tsype of player playing in a topdown camera mode, fading feature is a must. Todays' tileset developers often intentionally doesnt suppor this feature or they dont pay that much attention to it. This is a case of Zwerk's facelift which exposed a lot of objects that doesnt fade properly, this led me to uninstall it, but I dont condemn his project. I see it as a new standard, that only have to be a bit polished which is what I could do myself - as you might notice the most tileset bugs Ive fixed in CPP has something to do with tilefade, its very easy to fix this really and I believe Zwerkules will eventually fix this later. PS it shouldnt have caused any visibility issues, afaik the ceiling is transparent from a top-down view. But again. I guess this is solely depending on a fact whether the author, Zwerkules probably (I guess there isnt reason to go back for chiko's work?), will want/allow to add his ceilings into the patch in a first place. I would certainly not want to substitude his entire project. As you've said Gruflord the line is somewhere between.

[Shadooow]

ShaDoOoW wrote...

Im still looking for help with recoloring higher resolution of a nymph texture. And now I am also looking for a linux NWNX developer that would helped me to port my new NWNX Patch plugin (for server). And I would definitely welcome help with the windows plugins (both server and client) development as well.

This has been solved, Gruftlord has provided a high resolution nymph retexture and pope_leo is working on a nwnx_patch port for linux. Thank you both.

There is one more issue to solve though. Seems there is quite a lot peoples who dislike the new colored icons from AD. I still believe this was a good idea to do, and if this itself decide someone to uninstall patch, well its a price Im willing to pay. However there was an objection that has a point.

In a case when user has different colored icons in override already but not the scrolls, after installing the patch, few scroll icons gonna change. That is suddenly problematic because the icon of the spell hasnt changed (the icons in override has a priority). This is definitely not a wanted behavior and I would like to fix it. Can someone make a new colored icons for those few icons the AD replaced completely (with a way better image indeed)? Maybe The Amethyst Dragon himself? Pretty please. I know you have a lot of work.:innocent: In this regard what Im looking for is a high quality matching the rest of the AD icons. The colorization must have a sense, it cannot be a recolorization of the whole icon, it must be a hard work of coloring each part of the icon on its own. I know I want a lot and my expectations are high but it really must match with the rest of the icons otherwise it gonna be just worse.


And now, given the idea of Bogdanov89, there is an easier job to help with. It is possible to add a new loadscreen hints. If you have an idea for a load hint, whether its a general knowhow/mechanic (really no idea what) info or something from CPP perhaps (maybe mentioning new feature added into Sunbeam/Sunburst? something like that). If you have an idea for a loadhint share it.

Modifié par ShaDoOoW, 04 février 2014 - 10:51 .

[Shadooow]

NWNX_Patch development update:


Thanks to pope_leo and his help, this project can now offer various new features. Question is only if its in scope of this project and if there are builders who want this. All features that this plugin adds are designed to be automatical.

Examples of the possible changes:

- addition of the DURATION_TYPE_EQUIPPED and DURATION_TYPE_INNATE constants to be used in a ApplyEffectToObject function (I dont really know if innate behaves differently, but equipped is automatically removed when a item (creator of the effect) is unequipped. + It might allow to add additional feature such as to make effects applied as equipped to ignore immunities)

- GetAttackTarget function would also returned a counterspell target.

- a Supernatural penalty to magic resistance would ignored the monk's immunity to this effect (this would fixed the problem with the CPP's caster level modification)

- SetTrapDetectable(FALSE) would removed the trap's flagged status. (as there is no way to hide flagged trap anymore)

[Gruftlord]

does automatical mean they are allways on, or are this features that can be switched on and off by the builders? i got the impression the NWN©X plugins are optional anyway, so i guess there is no harm in having them. i can not speak for the features presented here, since i do not understand enough what they do, and how they would change things ingame. i'm probably the wrong person the answer this question, but i thought i'd chime in after 3 days of no other responses

[Shadooow]

Same as a CPP itself also CPP NWNX Plugin is designed in a way "all or nothing", the features in there wont be switch-able. So it needs to be planned in a way that builders wouldnt want to disable anything.

One advantage of this plugin is that its consistent across both OS types and even client. So you can plan with its features and then use it regardless of your hosting. Even switch it without need to rewrite anything.

Basically the question is whether to add new functionalities into default scripting functions - eg. something that works only on creatures will suddenly work on player as well, and so on...

[Gruftlord]

then my question would be: which ingame bugs would this fix? i have a hard time telling from the more technical explanation given above

[Shadooow]

None. Fact that the weapon color on CopyItemAndModify is limited to 4 is not a bug afterall. All these new features Ive listed only expands the possibilities of the NWN scripting functions which are limited/bugged/missing functionality.

[Gruftlord]

so it does add new functionality but doesn't change anything per se for the end users (aka players) without the builder making use of it?

[Shadooow]

Gruftlord wrote...

so it does add new functionality but doesn't change anything per se for the end users (aka players) without the builder making use of it?

Yes exactly, at least for this part of the plugin. The main content are playerstuff fixes actually (trident, circle kick...).