919 réponses à ce sujet

[Shadooow]

Came to important decision.

I reconsidered the "CPP light" version or whaterver you want to call it.

Since there are now two version, I approve the possibility to remove some features from the 1.70. No way that there would be a fork development (or what is that word...) and I dont approve of adding anything from a version 1.71 into 1.70. Also it would still be all or nothing. Thus the result would be:

1.70 - a lightweight version without features/fixes that are causing that aversion against whole project
1.71 - ongoing development with larger scope

But I need a list of features that should be removed. Best would be if someone volunteered and become a part of this project and had this in a task.

//I still think its a bogus anyway, but hey lets see what happens.

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

[Killmonger]

I am unable to help you at this time...

However, I believe you are on the right track now ShaDoOoW (et al)
Unify your standards (v1.70 "lite" with basic improvements/fixes +explanatory docs)
Achieve a modest goal first and let the rest of us catch up to you...

imho

[Shadooow]

Since the new version is coming, I got another question.

Would be builders using CPP too confused/unconfortable if I changed the metamagic checks from == to the & ?

This would allowed to make a spell with multiple metamagics at the same time without need to change all spellscripts. Builder that would want to allow this would only have to bring some way to combine it ingame, but the spells would be simply ready for it.

It wouldnt have any impact on the default scripts other then lesser readability. The & produces the same result as == without custom content.

This is something I am thinking long time already but I thought it wouldn't be accepted well. But I thought, I might ask first.

[henesua]

interesting idea. i like it.

[Shadooow]

Neverwinter Nights Community Patch 1.71 RC4 released:

DOWNLOAD - this is english version - to install, simply extract in the NWN folder and allow overwrite everything.
German, polish, czech language file for this version is included in this archive.
(builders resources and all NWNX Patch plugins are included inside main package)

CPP current documentation was updated to reflect changes from this version:
Project main documentation.
Spell changes documentation
Special Abilitity and feat changes documentation

EDIT: forgot that I also added an AI support for polymorphing based on discussion here. This is not enabled by default, to enable creature to use shapechanging feats, you need to se variable 70_ALLOW_SHAPECHANGE int 1 on a creature.

Fixed broken stuff from previous Patch versions:
-

Revisited features from previous Patch versions:
- On a suggestions from the community, the Empower Spell feat behavior changed to enforce the "vanilla" behavior which is "empower everything" rather than SoU "empower only dice results" which CPP till now used.
- Removed the double-empower from healing spells which would now, with vanilla empower resulted in too high healing. Thus, the cure wounds spell healing/damage was restored to match exactly the vanilla values. (Deeper explanation: the healing domain makes the spell to be also empowered, but when the spell is already cast empowered this has no effect normally. This is why CPP previously enforced doubling the empower, but due to the fact that empower is now twice as strong already, this feature was removed.)
- DoGrenade function in x0_i0_spells include revisited again to make spells using it backwards compiling compatible again (this compatibility has been lost somwhere between RC 2 and 3).
- Greater restoration spell school restored to the default (Necromancy) due to the issue with specialized wizards - still, the changed spell description intentionally remains Conjuration so it doesn't bother anyone anymore. Nobody spots the difference anyway.
- Tanglefoot's bag can affect characters with woodland stride again.
- Removed the credits from the comments on the spellscripts - this was there because some of the fixes comes from other contributors, but due to the fact that almost every spell contained my own name I rather removed it all as someone might seen that as a advertisement or something.

New fixes and features:

Tileset fixes:
- tde01_a15_01, tde01_a15_02 - fixed visibility node (allowed to see hidden rooms)
- tde01_d09_01 - small gap when tilefading fixed
- tdc01_f10_01 - fixed polygon gaps on the black coverages
- ttr01_z10_01 - fixed polygon gaps on the black coverages
- tin01_l13_02 - the two collumns under the ground position corrected

2DA changes:
spells.2da
- Cure spells uses now a new script, 70_s0_curewounds to allow higher flexibility in modifying the way how healing works. (This change is backwards compatible - aka it is not needed to merge this at all if you dont wish to)
feat.2da
- Added Epic Ranger feat as a prerequisite for the Bane of enemies feat - this will prevent the exploit with bane completely. (Also, unlike previous solution, this will automatically turn all those, who abused this exploit before, invalid.)
- Added Epic Blackguard feat as a prerequisite for the Epic Fiend feat (still to prevent exploit completely, 70_mod_levelup script is required)
iprp_soak.2da
- Added a zero soak itemproperty in order to be able to create a creature skin without any soak but granting the penetration of +X to any weapon the creature possess.
polymorph.2da
--corrected the portrait of the BOAT polymorph

Creature fixes:
- Corrected an appearance sound for the oozes added in patch 1.69. (human -> slime)
- Added missing OnBlocked script to the Lizard Warrior B blueprint.
- Added the usual construct immunities to the Shelgarn's dagger summoned creature.
- Corrected AI script in the Ochre Jelly's OnSpellCastAt event.

Item fixes:
- Added Helm 11 and 17 icon fix from the Realms of Mythology team (http://nwvault.ign.c...s.Detail&id=146).
- Added several clothing icon corrections between genders from the Realms of Mythology team (http://nwvault.ign.c...s.Detail&id=147).

Spells and spellabilities:
- Bigby's forceful hand: disabled self-stacking
- Bigby's grappling hand: disabled self-stacking, incorporeal creatures won't be grappled
- Bigby's crushing hand: incorporeal creatures won't be grappled.
- Gust of Wind: code for opening/closing door changed to be working without delay also in huge modules with slowdown issues
- Shadow evade: effects made undispelable.
- Shifter's wildshape: a spectre polymorph now also release character from the effects of the grappling (Bigby's grasping/crushing hand/entangle effects)
- Cure wounds - other: target type changed from standard hostile to the single target

Scripts:
- Added a new module switch, MODULE_SWITCH_SOU_EMPOWER_SPELL_BEHAVIOR, that will enforce the SoU empower spell behavior (which was up till now what CPP used).
- Fixed losing skin under ILR/ELC settings. This fixes losing the mounted horse when relogging and other issues. (x2_mod_def_unequ)
- Creatures under darkness effect cannot use gaze attack and are also immune to gaze attacks.
- Incorporeal creatures gains also immunity to knockdown and immunity to entangle effects.

Secret Content restoration:
- The secret "Neverwinter Eye" sword enabled for builders in toolset (longsword model number 9) (CEP1 team)
- Enabled unused potion bottom icon (bottom 7, color 9).
- An eight hidden portraits has been added into portraits.2da. (Disclaimer: players without patch won't be able to see them although they are in core game files.)

Client improvements:
- Added chicken texture fix from Ancarion (http://nwvault.ign.c...s.Detail&id=628)
- Added high resolution texture for barkskin effect from Gruftlord.
- Added a high resolution texture of the silver haired nymph from Gruftlord.

DIALOG.TLK corrections:
- Sunburst area of effect corrected to colossal.

HAK Version only:
- Added two unused versions of the ochre yelly creature (Large with one small yelly inside and second medium which is bit smaller than the original, there is one more small version but with no difference to the original small yelly so I haven't added it into 2da).
- Fixed portraits in few of the new blueprints.

Community Patch NWNX Plugin (both server and client version)
- Enables to choose custom base class in initial character creation. (client-only feature)
- Increases the effect icons limit from 130 to 255. (client-only feature)
- Removed the limitation on weapon color from CopyItemAndModify function.
- Fixes trident weapon focus bug.
- Fixed the bug with a fact that immunity to the ability decrease prevented also ability decrease from equipped items.
- Curse effect ignores immunity to ability decrease on a DnD Rules/Very High difficulty.
- Circle kick has been changed to swap the target back after the extra attack on a different one.

Note for the linux users:
Unix client is not supported, we suggest using WINE.
Due to the way how the nwnx works on unix, you might not be able to use the precompiled library which is coming with the CPP release. If thats the case you find all the sources and documentation here. For further details visit the nwnx forum where you find a thread devoted to this plugin.

Modifié par ShaDoOoW, 22 février 2014 - 08:28 .

[Pstemarie]

Not a CPP issue, but I caught some other missing BioWare items this morning while making weapon templates for my module. Darts and shuriken do not have a fourth color channel (black) like all other weapons. Might not be a bad idea to tint the icons and add the missing models so that Builders can have the full range of color options for all weapons. I'd send you the stuff I just added to Q, but we incorporated Project Reforged so the models and icons won't match up to vanilla specs.

Personally, I use channel 4 for cold iron and adamantite weapons so that PCs can easily discern them from regular steel weapons.

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

[Shadooow]

Pstemarie wrote...

Not a CPP issue, but I caught some other missing BioWare items this morning while making weapon templates for my module. Darts and shuriken do not have a fourth color channel (black) like all other weapons. Might not be a bad idea to tint the icons and add the missing models so that Builders can have the full range of color options for all weapons. I'd send you the stuff I just added to Q, but we incorporated Project Reforged so the models and icons won't match up to vanilla specs.

Personally, I use channel 4 for cold iron and adamantite weapons so that PCs can easily discern them from regular steel weapons.

Good catch but this cannot be added in CPP. First, the problem is that its questionable if its within the scope of the project at all, second, this would caused crashes when such dart would be used in module and player didnt had CPP installed, the only way would be in a CPP hak but Im still not sure if its in scope. I think this would suit CEP more.

[Pstemarie]

Didn't think about the crash issue. A HAK would then be the best place to incorporate this if you decide its within scope. As far as being in scope, considering that the rest of the weapons in NWN do have a fourth channel, you could look at this as an oversight on BioWare's part. However, it is an addon and not necessarily a direct fix, so it might be beyond scope after all. 

Modifié par Pstemarie, 24 février 2014 - 01:44 .

[Shadooow]

Pstemarie wrote...

As far as being in scope, considering that the rest of the weapons in NWN do have a fourth channel, you could look at this as an oversight on BioWare's part. However, it is an addon and not necessarily a direct fix, so it might be beyond scope after all. 

Exactly. I would like to add this, but need more opinion on this matter - anyone?

[Shadooow]

I would like to release the final 1.71 version in a month. Therefore I appeal to anyone who has objections or suggestions to propose them.

 

If there still are controversal changes then its still time to do something about them.

 

 

Also if you can, please install the latest CPP (1.71 RC4 - link for download in my signature) and try play/build with it so we can catch all possible issues that might be there.

 

Note for non-english users, the latest CPP has a german, polish and czech translations but as of 1.71 CPP no longer supports the unofficial 1.69 patches anymore. To install CPP on a non-english game version you need to install the english 1.69 via critical rebuild, then apply CPP and then change the language file (dialog.tlk) to version with your language.

 

You won't lose any functionality in this way, the only change in those unofficial languages is usually ending credits with names of the translators and the dialog.tlk itself (which CPP provides).

[Shadooow]

Still need a help with russian translation for 1.71. Its a work for 1-2 hours, any tlk editor allowed, please contact me via PM.

 

EDIT: or its a five minutes job, there are only three changes now since I already have russian tlk just bit outdated now

Modifié par Shadooow, 20 mars 2014 - 07:05 .

[Bogdanov89]

I got a question about the 1.71 RC4 and it's documentation:

 

There is a part that says "HAK Version only" and then a list of various changes/fixes.

 

How do i install the 1.71 RC4 if i want to have ALL the changes active, including both the "HAK Version only" and the regular RC4 changes?

 

Also, if i am to play RC4 with a friend over internet, does he also need to have it installed in the same way?

 

 

Thank you for making the RC4 and for helping me out

[Shadooow]

I got a question about the 1.71 RC4 and it's documentation:

 

There is a part that says "HAK Version only" and then a list of various changes/fixes.

 

How do i install the 1.71 RC4 if i want to have ALL the changes active, including both the "HAK Version only" and the regular RC4 changes?

 

Also, if i am to play RC4 with a friend over internet, does he also need to have it installed in the same way?

 

 

Thank you for making the RC4 and for helping me out

Well, the hak coming with CPP, patch171.hak (or patch170.hak respectively for those using the 1.70 only) has to be integrated into module separately. Unfortunately, there is no option to install it automatically into campaign (havent thought of that before - will see if I can manage it inside installer that im working on for final release). So if you play a campaign its going to be a bit difficult to do, so lets skip this part yet (if you want to play the campaign then let me know).

 

If you playing a fan made singleplayer module its easier. You need to open that module in toolset, then go to Edit-Module Properties-Custom Content. There is a list of all haks you have in the hak folder where you select the patch171.hak and press Add and then OK. It will try to make some thing you can cancel it its not needed, then you need to save the module. As of now however your friend you want to play this module with needs the patch171.hak too. Since this hak is part of CPP it means he needs CPP installed.

 

Damn, ok its not much easier hehe. This hak was intented rather for module builders than players you know, the most features it has are for builders anyway. So my suggestion is forget about CPP Hak. Its main purpose is to control whether player has or hasnt CPP installed when playing module (for example if the builder uses some of the CPP features such as eg. new traps or stacking ability bonuses from merged items when shapeshifting and want to ensure that player will have this features when he play his module).

[Bogdanov89]

Thank you for replying!

I forgot to mention that currently i am only playing the Bioware original Campaigns, as well as the 2 expansions (SoU and HotU).

 

I think i misread the documentation - i am interested in the change that "fixes the trident weapon focus bug", as well as the change to the Circle kick targeting.

 

Those two changes are under the "Community Patch NWNX Plugin" category (inside the RC4 documentation).

Do i need the Hak version installed to have those two changes active - or is the regular installer version enough?

 

Also, can you please elaborate on the Empower change - is Maximize now always better than Empower?

If a spell does like 1d6 +5 damage, in RC4 how much will it do with Empower and how much will it do with Maximize?

 

Again, thank you for helping out.

[Shadooow]

Thank you for replying!

I forgot to mention that currently i am only playing the Bioware original Campaigns, as well as the 2 expansions (SoU and HotU).

 

I think i misread the documentation - i am interested in the change that "fixes the trident weapon focus bug", as well as the change to the Circle kick targeting.

 

Those two changes are under the "Community Patch NWNX Plugin" category (inside the RC4 documentation).

Do i need the Hak version installed to have those two changes active - or is the regular installer version enough?

 

Also, can you please elaborate on the Empower change - is Maximize now always better than Empower?

If a spell does like 1d6 +5 damage, in RC4 how much will it do with Empower and how much will it do with Maximize?

 

Again, thank you for helping out.

Changes and features listed under Community Patch NWNX Plugin paragraph are those you get access to only if you use NWNCX or (in case of hosting a module on internet via nwserver.exe, NWNX respectively).

 

Please read this. If you still have questions please ask them in a new thread because this is a custom content which is CPP supporting, im not able to give you full documentation and advices for it. The reason why the CPP requires NWNCX instead of patching nwmain.exe directly on his own is to:

- support other custom content (in other case it would be stealing part of the NWNCX focus)

- make custom nwmain.exe modifications compatible (NWNCX again, camera hacks)

- not break EULA etc. (I dont have a patching system and providing already patched nwmain.exe would be against afaik)

 

Re: Empower change. Starting with RC4, on the suggestion from the community the new default Empower Spell behavior is the one that was proposed in original NWN Campaing (empowering full normal spell result with all bonuses by one half in your example result of the 6-11+one half = 9-16) instead of the behavior introduced in SoU expansion (empowering only the dice part of the spell result and adding any bonuses into that, in your example result of the 1-6+one half+5 = 6-14).

This means that maximized is now NOT always better and Empower outshines Maximize (although more expensive to cast) for a spells that has a bonus to dice based on caster levels.

You in particular was advocating this behavior, so I dont understand your question.

 

Anyway, it is still possible to change this behavior anytime in game (via so called module switch) but its a bit difficult to do for a campaign as this option is not present in PC widget tool. Anyway, that way or another this gets problematic and visible only on a higher levels which you wont access in official campaigns so you are fine by any way of that.

[Bogdanov89]

Thank you for explaining all of that.

 

Personally i was hoping that Empower will give 50% greater total damage while Maximize gives 75% greater total damage.

 

Is the empower/maximize modification you made (50% and 75%) a month or so ago compatible with the RC4?

[Shadooow]

Is the empower/maximize modification you made (50% and 75%) a month or so ago compatible with the RC4?

Of course, everything is, even when peoples still don't believe it. If CPP breaks something its a bug that I will fix asap, but nobody yet proved that...

[Pstemarie]

Shou Disciple and Eye of Gruumsh - Although I understand why have them disabled by default, for the sake of consistency with the way the other Prestige Classes are setup, it might be worth it to have them enabled by default. Builders that found them unbalanced could then disable them via variable - the same thing they would do for other prestige classes.

[Shadooow]

Shou Disciple and Eye of Gruumsh - Although I understand why have them disabled by default, for the sake of consistency with the way the other Prestige Classes are setup, it might be worth it to have them enabled by default. Builders that found them unbalanced could then disable them via variable - the same thing they would do for other prestige classes.

Given the issue the WhiteTiger found, they have to have the variable requirement to 0.

 

Im still not sure whether enabling them by default is a good choice as it forces builder to change it (which is an argument even you used before Pstemarie, didnt you?) and because it theoretically changes the balance of any module you play (MM argument).

 

Though, I dont think they are unbalanced, Eye of Gruums is crap like PDK and the Shou has very powerfull feats but they are balanced by the cost - class slot.

 

So Im for enabling, especially when the only choice to disable them is via classes.2da PlayerClass to 0 which removes them from list entirely. Any more opinions/suggestions?

[MagicalMaster]

Is there actually a link to the classes as they are implemented in NWN specifically?

[Shadooow]

Is there actually a link to the classes as they are implemented in NWN specifically?

There is not. I was hoping the NWNWiki cover this since this is vanilla content, but so far nothing.

 

But basically it matches with the PRC implementation (Shou) except its all hardcoded into engine. Also there is an undocumented feature that upon taking Shou Disciple, the monk's AC continue to work with light armor, but there might be much more.

 

The Gruumsh is different case, lot of stuff is custom created by me since his feats are not automatic but selectable, so I had to create them from scratch based on the description. I have not tested his automatic feats at all.

 

EDIT: btw I realized the martial flurry feat is badly configured. It must be given into class radial so player can use it - i thought its automatical feat, but appears its selectable as this can be used even without monk class.

Modifié par Shadooow, 06 avril 2014 - 07:39 .

[Pstemarie]

Given the issue the WhiteTiger found, they have to have the variable requirement to 0.

 

Im still not sure whether enabling them by default is a good choice as it forces builder to change it (which is an argument even you used before Pstemarie, didnt you?) and because it theoretically changes the balance of any module you play (MM argument).

 

 

Yeah, I had used that argument in the past. It's tough finding a happy medium that suits the majority. As a Builder I tend to prefer that new game system content included in comprehensive packages such as the CPP, CEP, or even Q is disabled by default - or at the very least includes a switch to enable/disable it. However, its also necessary to keep the formatting of implementation the same for such content. For example, with the PrCs you unlocked, having them disabled by default forced builders to use an inverse variable setting to activate them and ultimately caused issues - as you've found out.

 

In any event, whatever you ultimately decide, I'm looking forward to a final release of Patch 1.71.

[Shadooow]

Well since the variable to 1 solution has failed and causing issues, there are only two choices.

 

1) disable them by default in classes.2da

This means this is no longer possile to control via script ingame - and also means that those classes wont appear in the levelup menu at all. Players, who I suspect might be interested in this content, arent really expected to do the 2da magic to plays them so I think this is a bad solution.

 

2) keep them enabled by default

Players who dont want to play these classes can simply ignore them. Builders who install CPP and dont wish their players played these, will have to disable them unfortunately, but they can do that either via variable (SetLocalInt(oPC,"70_AllowShou",1) or classes.2da (which works in server override).

 

I think the second option has more advantages than disadvantages. Actually the only disadvantage is that builders who dont like those prestige classes are ultimately forced to disable them and forcing anyone to do anything by installing CPP is wrong. I agree with that but see no other way. Either way, both options forces the other group of peoples to disable/enable them anyway.

 

(Or, if someone know about a third way, please tell me.)

Modifié par Shadooow, 06 avril 2014 - 10:26 .

[Pstemarie]

Solution 2 is by far the best choice of the two. It's in line with the way the vanilla PrCs work - they all have a variable defined to disable them - and is the method most familiar to builders. Furthermore, I don't think anyone will cause a big stink about having to disable them if they don't want them in their module but, then again, you  never know...

[Gruftlord]

i think option 2 is the best as well. CPP is not only for builders (like CEP), but regular players as well. builders will have the required knowledge to disable the PrC should they decide to add CCP to their module but do not like the classes. players who do wish to play these PrC in downloaded modules might not possess that knowledge.