919 réponses à ce sujet

[Shadooow]

Ok, will remove that from the new documentation.

Follow up... is that switch (and the AC one which I notice before) in version 1.70?

Not anymore. It was there but I made the "remastered" edition where I removed everything which was removed from 1.71 to make it more consistent.

 

The player can *still* buy plain unenchanted goods from the stolen goods merchant, cast CF on them, and sell them back for a profit, so what is actually accomplished with it other than hassling the player?  The spell does exactly what it's supposed to, selling of magical goods works exactly as it's supposed to.  There's really no exploit here, just a lack of AI reaction routines and poor gameplay design that is just inherent in an old game which doesn't have sophisticated AI.

Are you saying that since it doesn't prevent player from doing that and only make the whole process harder and less profitable its better to remove it?

 

Are you the kind of player that would like to do this? Just so I know where we stand, because imo, from the builders perpective there is no problem, some even makes item plot or replaces the permanent light with temporary (for duration of 9999999999.0 which makes it almost permanent but not affecting price). From a player perspective - if you want to cheat, why not give yourself 1000000GP already?

 

AND.... it actually solves the issue as it covers all merchants, not just some of them.  If the purpose is to eliminate relatively effortless cash-production with the spell, the current method is not doing it at all, as it creates it's own exploit of the very issue it's intended to fix (and that would be an exploit as it's using game mechanics to bypass the intended game mechanic implementation).

What. If the current method still provided relatively effortless cash production, we wouldn't have this talk I believe because its not and you don't like it. And what exploiut this method creates, I don't follow?

 

EDIT: Ok, I realized the potentional issue, not sure its what you meant, but in pre-existing modules without any merchant buying stolen goods it might be a problem. If a player cast this spell on his equipment, he wouldnt be able to sell it later in game and thus missed gold to purchase better equip. Though, the circumstances under which this proves to be an issue are quite rare, I don't pretend I played every module but this seems to me very unlikely to happen.

 

Anyway, I agree the stolen flag is less than ideal solution, so lets discuss alternatives.

[Gruftlord]

I think the argument is more like: the current solution doesn't really fix the underlying issue. It only makes it less convenient to sell, less profitable and therefor more annoying to exploit. On the other hand, what the change completelly not does is make the ingame experience any more immersive, realistic or believable. It fails at that, and imho makes the shortcomings of the game only more visible.
It reduces the effectiveness of an exploit by making the game ultimatelly react even less realistic than before. We should search for a better fix

[Shadooow]

Alright.

 

Maybe adding Item Cost Parameter C -1 (-500gp) could work? For completely mundane items this could work pretty well effectively restoring original cost as the light is worth 500 too. For a more expensive items, this would only slightly reduced the value since the light cost more there but the ICP C-1 still the same, but for items like these it shouldnt be problem. If player finds it in dungeon I think its okay to allow him increase cost of the item (aka the situation MannyJabrielle presented with rogue finding scroll of this spell). Since merchants sells items with increased cost by at least 10% I think that for anything other than mundane items the potential profit for bying/imbuing/reselling is zero or very small to be worth doing that.

[The Amethyst Dragon]

Regarding continual flame...

 

The "fix" I made for Aenea was to alter the spell script so that the light property from that spell is temporary, lasting a (I think) week. As a temporary property, the item value is not affected, merchants don't pay extra for it, and the property seems to be stripped when such an item is sold.

 

It does mean the spell is no longer "permanent" and has to be recast sometimes, but does avoid the whole item value exploit issue. Plus, cheap scrolls of continual flame are easy to either have available in-game in shops, loot, or via PC scroll scribing.

 

For the Community Patch, the duration change option could be included in the spell script, but just be commented out so builders can decide to use it or not just by uncommenting one line of code. As long as it's documented somewhere, it shouldn't then be too difficult to find and change.

[MannyJabrielle]

Are you saying that since it doesn't prevent player from doing that and only make the whole process harder and less profitable its better to remove it?

It doesn't make it less profitable, unless you are absolutely counting on module builders to set their stolen goods merchants to a value you personally would like them to use.

It doesn't even solve the issue the change is supposed to address.  It simply hassles the player and breaks continuity of game mechanics and breaks immersion.  The player sells a plain ring and a light enchanted ring he finds on a goblin.  Player learns magic version of item sells for more than non-magic version of item.  He then finds another plain ring and enchants it with his own CF spell.  Suddenly he can't sell it to specific merchants, but can to others.  That is a breakdown of the rules of the game.  From a player standpoint, had I not known about this change in the CPP, I would have considered the game bugged, with no logical reason to consider that it was an intentional game mechanic because of how fundamentally flawed it is.

 

 

Are you the kind of player that would like to do this? Just so I know where we stand, because imo, from the builders perpective there is no problem, some even makes item plot or replaces the permanent light with temporary (for duration of 9999999999.0 which makes it almost permanent but not affecting price). From a player perspective - if you want to cheat, why not give yourself 1000000GP already?

 

Ok, I actually have to take offense to that.  I really would appreciate it if you did not outright insult me and call me a cheater because I do not agree with your opinion on this mechanic, or how you implement it as a standard within a project that is supposed to be a community patch, not a house-rules modification.

 

Instead of just insulting me, why don't you take a moment to consider that yes I do full well know how to use the console commands, I'm in the habit of wasting my time, and my reasons for thinking this particular change in the CPP is bad are based on thought out reasoning.

 

If I wanted to *cheat* and get a hundred million GP, I would damn well use the console command to get a hundred million GP, not waste my time tediously casting a spell over and over again rather than having fun playing the game, and most definitely not wasting my time arguing with someone who throws personal attacks at me without cause.

I made my stance on the topic, and I stated my reasons for it very clearly already.  The spell works completely as intended.  The mechanics of price mark up for special properties works completely as intended.  It is not an exploit.

 

Buying/selling items back and forth to the same merchant when your appraise skill is extremely high is an exploit.  Continual light is not.  It's a game balance issue, and frankly one that should be left up to the builders and players to decide on if they want, just like any other house-rule modification.

 

Yes, I am the type of player who will enchant my non-magical loot with a caster character from time to time.  There is absolutely no that and selling weapons or armor I crafted with crafting materials.  Are you honestly going to tell me that you consider it cheating for a player to make a longsword out of crafting materials for a profit?  In both instances, the character uses his skills, abilities, or resources to make money within the established rules of the game.

 

What. If the current method still provided relatively effortless cash production, we wouldn't have this talk I believe because its not and you don't like it. And what exploiut this method creates, I don't follow?

 

The exploit is in the very implementation.  If the mechanics intent is to stop cash production, it does not accomplish that as there is absolutely nothing stopping the player from selling the item to a different merchant, thus completely bypassing the intent of the game mechanic in the first place.

So what's the problem then if the player can just go to a different merchant?  The problem is implementing someone's personal set of house-rules as a non-optional rule-set in a module promoted as a community patch project.  I understand completely that you are really the only one working on it, but if it's going to include your personal house rules, then those should be as a separate package for the players and builders to decide on using optionally, or implemented as switches to turn on and off via builder and/or player, otherwise it's not really a patch anymore in it's intent.

 

 

EDIT: Ok, I realized the potentional issue, not sure its what you meant, but in pre-existing modules without any merchant buying stolen goods it might be a problem.

That was an aspect I hadn't thought of either.  IMO that's another reason to avoid the method of setting item flags.  Off the top of my head I think witch'swake is just such a module.  Not sure, but i don't think any of the merchants in it (there aren't many at all) are black market merchants... flagging items as stolen would really be frustrating until the player figured out that the CPP was breaking the game mechanics.

[MannyJabrielle]

ok, toyed around with the 2da's.  I'm not sure how you got the numbers you did.  I tweaked down the cost parameter in just the itemprofdef.2da down to 0.1 and then again down to 0.01, and both times it drastically reduced the gp value of the light property, but it still multplied when added with other properties.  At the 0.1 setting, my keen +0 dagger was 2208 GP with bright light, 2004 without bright light, and 8 GP with bright light but no keen.  4 GP without any properties.  The default property cost is 1.0, which makes a keen bright dagger 4500 or so, a bright dagger 504, and a plain dagger, 4.

If intent on changing the CF-value issue, it seems 2da is the way.  I'm just not seeing whatever issue you said you saw with setting a target price this way.  I don't seem to get any value changes from messing with the lightcosts 2da, but I'm getting plenty of change with the itemprofdef 2da.

 

The only issue I see with it is actually that it's a 2da edit, and not a variable that can be switched.  The setting it up as a long lasting temp property would see to be the far more comprehensive tweak.  It covers the issue 100%, and the spell's behavior could be switched between temp prop behavior and default behavior.

 

 

For the Community Patch, the duration change option could be included in the spell script, but just be commented out so builders can decide to use it or not just by uncommenting one line of code. As long as it's documented somewhere, it shouldn't then be too difficult to find and change.

 

Switch for the spell's behavior even better.  It's no problem for builders to do that, but it's more of a PITA for the player wanting to put his sp modules back to the default behavior.  The widget method of setting switches is a perfect implementation for non-building players.

[Shadooow]

I don't mind basically any other implementation, but someone else always will. So lets talk about what solution is most ideal for majority. If possible then a solution which wouldn't required option switch to toggle that to default.

 

Some notes:

 

- changing itemproperty base cost value, especially the Item Cost Parameter which is/was heavily used for changing item price is not an option - such change will changes cost on all preexisting items retroactively and thats always bad - UMD is the main reason, as the difference in cost itself should be insignifical

- making itemproperty temporary will completely disable the cost increase - which itself isnt the problem as MannyJabrielle said

- partial reducing the cost via Item Cost Parameter has minor problem in modules with old itemproperty 2DAs it won't work there - so even if this solution will be used, there should be some backup solution

- NWNX solution is least ideal in my opinion because NWNX is optional

[MannyJabrielle]

Having the spell switch between default bioware behavior (perma property) and a temporary property behavior is the best way I think.  Satisfies having a switch AND it more effectively and consistently addresses the CF cash production issue when switched to do so.

[Shadooow]

I would like to avoid that - CPP cannot have a switch for every little thing that doesn't suit few players.

 

IMO, builders doesn't need a switch for this, they either already dealt with it in which case CPP spellscript won't be in play, or they doesn't care (SP modules). For the rest, whatever the new solution will be - they will have to find out whether its adequate for them or not yet.

 

When the player would want to revert the behavior to vanilla then? Or in other words, what functionality is desired? Should this spell be expected to increase item worth? As this effect is not documented, not that it wouldn't be logical...

So if it should increase cost, the solution to decrease worth by ICP -C (-500gp) seems best to me as it makes it less profitable, but not spoil the selling itself in any way.

If it shouldn't increase cost, then the ultimate solution would be to find a formula calculate which ICP properties are needed to decrease cost to original value but making the light temporary for very long duration should work too.

 

At any way, I would rather removed this feature completely than adding a switch for that. Seriously, switches are great and I think the current selection of switches is fine and desired, but the more switches the less tranparent this will be and the more confusing this will be. I wouldn't want to end in a situation that so many other mods similar to CPP ended where player is more changing the options than actually playing the game.

[Bogdanov89]

ShadoOow, i think i encountered some bugs with your mod "Hyper-Gore Re-Revised Edition":

 

1. The NWN game seems to consider important monsters alive as long as their "corpse" exists.

Many important enemies that i had to kill the game would not consider "dead" until i right click-bashed their corpses (bashed corpses into blood and guts).

Example would be the Catapult Commanders (or catapult captains?) in chapter 3 of original campaign, where i can not destroy ("use") the catapults until their Catapult Commander's body was bashed into nothing.

Even after i kill the catapult commander and click on the catapult, the game tells me that the commander is still alive - but this issue goes away after i bash the commander's corpse.

 

2. Certain creatures, like the huge water and huge air elementals, get bugged upon their death - they levitate in the air in a death pose, which looks really silly.

 

3. Certain enemies, like some variant of the "Shadow Fiend" and "Invisible Stalker" creatures, bleed big amounts of (usually green) blood - but those creatures are either ghosts or elementals of shadow/air, and as far as i know they do not have any blood to begin with.

I am not sure of the exact name of the bleeding ghosts/elementals, but they look like the Shadow Fiend type of monster.

 

 

The first bug is really annoying to deal with, since i have to bash pretty much every important corpse for the game to register the death of those monsters.

As long as the game requires me to kill a creature (and not just show it's head that i can loot), i need to bash all the relevant corpses in order for the game to register their deaths.

Worst situation is if i need to kill all the creatures in a specific area for something crucial to happen - i need to bash the corpse of every enemy in that specific area, which can mean i need to bash 15++ corpses

[Shadooow]

ShadoOow, i think i encountered some bugs with your mod "Hyper-Gore Re-Revised Edition":

 

1. The NWN game seems to consider important monsters alive as long as their "corpse" exists.

Many important enemies that i had to kill the game would not consider "dead" until i right click-bashed their corpses (bashed corpses into blood and guts).

Example would be the Catapult Commanders (or catapult captains?) in chapter 3 of original campaign, where i can not destroy ("use") the catapults until their Catapult Commander's body was bashed into nothing.

Even after i kill the catapult commander and click on the catapult, the game tells me that the commander is still alive - but this issue goes away after i bash the commander's corpse.

 

2. Certain creatures, like the huge water and huge air elementals, get bugged upon their death - they levitate in the air in a death pose, which looks really silly.

 

3. Certain enemies, like some variant of the "Shadow Fiend" and "Invisible Stalker" creatures, bleed big amounts of (usually green) blood - but those creatures are either ghosts or elementals of shadow/air, and as far as i know they do not have any blood to begin with.

I am not sure of the exact name of the bleeding ghosts/elementals, but they look like the Shadow Fiend type of monster.

 

 

The first bug is really annoying to deal with, since i have to bash pretty much every important corpse for the game to register the death of those monsters.

As long as the game requires me to kill a creature (and not just show it's head that i can loot), i need to bash all the relevant corpses in order for the game to register their deaths.

Worst situation is if i need to kill all the creatures in a specific area for something crucial to happen - i need to bash the corpse of every enemy in that specific area, which can mean i need to bash 15++ corpses

None of these issues are caused by CPP or Hyper-Gore.

 

Some clarification then:

 

1: Bad campaign design, you remember the issue with Arena in Chapter1? Same story, the scripting is bad and checks whether creature exists rather than if she is dead.

 

2. Thats normal, it gets messed especially when the creatures are knocked down in the time of death. Its purely visual issue so not big deal.

 

3. Thats vanilla settings - their blood is set to green in appearance.2da, so they are splattering green blood - this setting is questionable but I think its correct. The invisible stalker is invisible - that doesn't mean he has no body or blood. The shadow fiend is similar case - its demon not a living shadow.

[Shadooow]

I have dropped the licence on the project itself. I am highly disappointed with all the peoples for which the only interest in CPP is to rip specific features or even nwnx features into their own mods (plugins) and toss away the patch itself after. But as Gruflord said - even those do use the work I did in some way and they might change their opinion later.

 

Thus as of now, you are free to rip anything, repackage anything, redistribute anything, claim that CPP content is your own, make your own fork of CPP, whatever you want. If thats what means the project is open, then this is it .

[Gruftlord]

That's a big step, and i think the right one. Though i think it wouldn't harm to state that you wish that people give credit where credit is due and do not try to fork without searching permission. You see, if someone wants to fork for some reason, it might be good to have him come here and state the reason. Who knows, maybe its a good request and it can be incorporated into the real cpp. Or you could state that forks are allowed, as long as the fork also remains open.
But honestly, i doubt someone would want to fork anyway, while i can see some builders wishing to pack cpp into their haks

[Shadooow]

Community Patch 1.72 Beta 4 Released

download

 

Yes I renamed it to 1.72. There is now too many content to be convinient to distribute as override or patch-hak. As of now, the ongoing patch development will be distributed in the patch (BIF) way and will have lowest priority.

 

From this reason, a signiicant issue raised - the older addons which were released as override will have higher priority and will overwrite the new stuff. To fix this, either clean your override completely and get all the stuff again (I know not an option for most of you), or proceed this way:

1. download the 1.71 addon v3 again and unpack it into separate folder

2. use some kind of comparing tool (I use Beyond Compare 2 if you don't have any). And compare the folder where you unpacked it with override. Delete every matches and mismatches. Or you can do this manualy...

 

Anyway, without this the new features from 1.72 might not work.

 

Also, note that the 1.72 beta is dependant on 1.71 as it contains only new and changed files (to keep distributing simple for me). It won't work without it and might cause crashing.

 

To install it, follow as in 1.71 manual installation. Simply unpack the archive into folder with NWN files (thus if you do this right it will want to overwrite bunch of files which you have to confirm). The 1.72 is international, works for all languages as there are no changes in dialog.tlk file yet.

 

To uninstall it, either run 1.69 critical rebuild, 1.71 installation, or manually delete/rename the xp2patch.key file and rename the xp2patch171.key which is included in the 1.72 beta distribution.

 

Neverwinter Nights Community Patch 1.72 beta 4 content:

Fixed broken stuff from previous Patch versions:
- Fixed switch for managing henchman inventory which worked reversely.
- Fixed bug with henchman's automatic trap handling.
- Added missing code for Wounding itemproperty handling (somehow didn't make it into 1.71 final due to the overlook).
- Chain lightning: removed duplicate oTarget != spell.Target condition code (no impact on functionality, only cleaner coding).

Revisited features from previous Patch versions:
- Harpy song won't be used by AI under silence effect anymore.
- Removed ground targetting from the Blinding Spittle special ability (Eye of Gruumsh) as it caused misfires. (2DA change in spells.2da)
- Wounding property will be functional now even when player is dying.
- ground item models improved featuring ground models for shields and increased appearance range to 255 (Gruftlord)

New fixes and features:

Tileset fixes:
- tde01_c13_01: one mesh didn't faded properly
- tde01_a01_02: fixed flickeringof the lava behind the bars
- tdm01_z01_01: shiny water fixed (image)
- tde01_o16_01: pathnode changed to fix pathfinding issues
- tdt01_j02_02: "up in the air" walkmesh fix

AI improvements:
- Improved barbarian rage handling, creature using barbarian rage will immediately run into combat and won't stand flatfooted any longer. (Note this is 1.71 feature which is allowed by default only for henchmans and creatures with variable 70_ALLOW_RAGE = 1, it won't have impact on creatures using the special ability rage version)
- Improved intentional trap triggering by a henchman. It's still not perfect due to the engine limitation, but its not more reliable then before.
- Daze spell handling - won't be cast on creatures with more than 5 HD.
- AI will be able (with 50% chance) to cast silence spell at location instead of at target, granting no saving throw roll.
- Fixed henchmen AI issue that could cancel ongoing spellcasting in middle, to cast exactly the same spell again.
- Further improved defensive casting AI behavior:
-- henchmens are allowed to use it as well now, even if their AI level is not HIGH
-- defensive casting won't be used if creature is in Expertise/Improved Expertise mode
-- AI will now use defensive casting mode even if the creature has less than 100% (but at least 25%) chance to actually succeed in the concentration check
-- chance to use defensive casting mode now depends on the chance to succeed in the check and a the number of enemies threatening in melee

Spells and spellabilities:
- Firestorm: fixed bug that prevented the spell to affect placeables and doors.
- Harpy song: added deafness failure.
- Wail of Banshee: number of targets pool was decreased even for targets that were skipped.
- Power Word: Kill : immunity check didn't correctly passed caster into consideration.
- Various AoE spells: line of sight wasn't checked, spell now doesn't affect creatures behind walls. Spells affected: basically all OC and SoU spells with area of effect.
- Dispell spells will no longer affect dead targets (basically only a visual change since it had no effect anyway)
- Added formians and hound archon into list of creatures immune to petrification.
- Removed ground targetting from the Chaos Slaad Spittle special ability as it caused misfires. (2DA change in spells.2da)

Other scripts:
- Module Switches globalized. The switches setup will now be transferred into every single player module the player will play. Note, the module settings has always priority - but player is able to override even module settings via PC Widget Tool.
- Newly, a skill and saving throws bonuses/penalties will be propertly stackes as well if the module switch to stack ability bonuses is active. (Note that a single saving throws itemproperty is capped to +12 thus you might not get what you expect. Examplet: wo rings +8fort => +12fort)
- Incorporated the "new engine polymorph" package. This has been substantially reworked, several bugs has been fixed, class locking disabled by default, added comments, code better formatted. This handles:
 - disabled casting spells in polymorph that player normally doesn't have access to
 - fixed polymorph temp hitpoints stacking (dependant on 2DA change in polymorph.2da)
 - fixed losing all merged item properties when "repolymorph" happens
 - fixed losing bonus spell slots from ability bonuses (but only up to the ability bonus that was merged into shape)
 - merged ability decreases now ignores immunity to ability decrease from shape or from other merged items (without NWNX, that is)
 - dying after unpolymorph
 - and this features the OnPolymorph event inside NWScript without NWNX, the OnPolymorph event script is "70_mod_polymorph". (see here: http://forum.bioware...s-without-nwnx/ )
- Player given items are no longer lost when OC henchman level up. (But still be gone when moving between chapters!)
- Upon respawn, outgoing AOEs cast by the respawning PC will be dispelled. (At this moment only AOEs in the area of the respawning PC - should be enough in most situations.)
- Upon respawn, player will be stripped of every effect, not just negative ones.
- 70_inc_itemprop: added three new functions for builders:
 - ItemPropertyBoomerang
 - ItemPropertyWounding
 - ItemPropertyItemCostParameter
- 70_inc_itemprop: added also three new constants, useful for checking itemproperty type:
 - ITEM_PROPERTY_BOOMERANG
 - ITEM_PROPERTY_ITEM_COST_PARAMETER
 - ITEM_PROPERTY_WOUNDING
- in several spell scripts, the oTarget != spell.Caster sanity check position swapped from unification/efficiency reasons

NWNX_Patch and NWNCX_Patch plugins (version number v1.7):
- Enabled and implemented Boomerang itemproperty. Throwing weapon with this property will return to hands of wielder = never decreases quantity.
- Increased limit in SetItemCharges function to 100.
- Fixed losing spellslots after polymorph - instead, spells in the slots will be "consumed". Also, merged bonus spell slots won't be consumed at all (note this is dependant on new scripting engine for polymorph which marks which item was merged and which wasn't, without it this feature won't be functional.)
- Added a method of checking whether is NWNX/NWNCX_Patch currently in use, see code below:
 

//return TRUE if the NWNX_Patch or NWNCX_Patch is currently in use and functional - only works with v1.7 and higher
int NWNX_Patch_IsInUse()
{
    SetLocalString(GetModule(),"NWNX!PATCH!VERIFY","0");
    string sRetVal = GetLocalString(GetModule(),"NWNX!PATCH!VERIFY");
    DeleteLocalString(GetModule(),"NWNX!PATCH!VERIFY");
    return sRetVal == "1";
}

Now notes:

 

1. Keep in mind that this is beta version and might contain bugs, I cannot recommend to use it for PW because it wasn't thorougly tested yet. Mainly because nobody care to help with that task - I have tested it in the most common way and made sure everything work as intented, however I didn't checked every possibilities especially those that includes:

- what happens if this will be used without CPP

- what happens if script A will be overriden by module version and scriptB not and reversely

 

2. Everything in 1.72 beta is subject to revision and possible removal. Almost every feature can be removed if it is not desired.

 

3. Some of this stuff is now dependant on the NWNX and also reversely on the scripting Ive done. Thus some features might not work properly if NWNX or CPP scripts are not in use. For this reason I implemented the new function which allows builder to check the NWNX_Patch presence/absence and inform player about the features not working in his module. Unfortunately this doesn't work retrospectively. It will be available only for NWNX_Patch v1.7 and higher. The only way to handle this issue that I can think of, is to distribute NWNX_Patch separately (atm only the 1.2 version is downloadable separately because higher versions are still treated beta).

 

4. I apologize for the way how I did described the polymorph changes - but trust me this is very very messy and hard to describe, not many peoples even knows what exactly is broken there and how it should work. So before you ask a question, try it. Then ask for anything you want to know.

 

5. I have removed the new polymorph engine package from CPP downloads page. It contained several bugs, one quite serious (too many instruction error) and I heavily revisited the code anyway. The new code is now twice as complicated, but its better formatted and very deeply commented. At any way both the 70_inc_shifter and 70_inc_itemprops are not expected to changed by majority users. Usual builder will want only to use the function ApplyPolymorph() in his script and thats everything he needs to care about.

 

6. I hope you guys agree that we don't need a special switch to allow stack merged skills and merged saves and its fine under one switch. If thats the case, the switch will be renamed in the PC Tool Widget but its internal name (the one that builders uses) will remain the same to make it backwards compatible (which is always requirement).

 

7. I havent dealt with Continuous Light spell yet. Its not because you haven't persuaded me, but because I haven't decided how to deal with it yet. At this moment, the complete removal of that feature is what I see as a best option - I wonder if this could be removed also in 1.70/1.71 final or whats the preference on the handling this.

 

And last. I noticed that there is a little issue with the new ground models: I found the new ring to be too small and too undistinguished from the ground especially in forest tileset but basically everywhere with a bit darker ground. Compared to the previous one I personally see no advantage - but I keep it to you to decide. (Also I noticed that these models comes from Q, but I think Pstemarie won't mind)

[Pstemarie]

Don't mind at all Shadooow.

 

This Q is your Q

This Q is my Q

From the tileset fixes

To the brand new models

This Q was made for you and me

 

Use whatever you need Shadooow.

[Gruftlord]

Great update. Lots of usefull changes here. I got to agree that the ring can be hard to spot at times. Maybe the new model can be enlarged somehow surely that would be the ideal solution.

One question regarding the new skill and saving throw stacking: what is the new change? I thought they stacked already in vanilla

[Shadooow]

Great update. Lots of usefull changes here. I got to agree that the ring can be hard to spot at times. Maybe the new model can be enlarged somehow surely that would be the ideal solution.

One question regarding the new skill and saving throw stacking: what is the new change? I thought they stacked already in vanilla

Not on the same item, which is what happens after polymorph merging, when the highest is used. This wasn't adressed in CPP before because I didn't know how to code it seamlessly and custom content compatibly - I finally figured it out so here it is.

[Bogdanov89]

Superb patch

I love all the AI tweaks and the spell fixes!

 

 

Will all these changes to the polymorph engine help out the druid/shifter (and wizard) shape-changing?

 

I primarily mean about the scaling with items, so that shape-shifting (with good gear and weapons) can actually be very good even in very-high-magic worlds (compared to melee classes like fighter/barbarian/weaponmaster)?

[Shadooow]

Superb patch

I love all the AI tweaks and the spell fixes!

 

 

Will all these changes to the polymorph engine help out the druid/shifter (and wizard) shape-changing?

 

I primarily mean about the scaling with items, so that shape-shifting (with good gear and weapons) can actually be very good even in very-high-magic worlds (compared to melee classes like fighter/barbarian/weaponmaster)?

Yes, but to clarify. There are two features in play here.

 

1. The new polymorph "engine" which is a fully scripted improvement for the polymorph effect which doesn't use NWNX.

2. NWNX fix for losing spell slots in polymorph.

 

The new polymorph engine adressess the losing spell slots only partially - it saves only spell slots coming from ability bonus and only up to the maximum merged ability.

 

To explain this its needed to clarify why the slots are lost in the first place. Its because that after polymorph, all items are unequipped and their bonuses removed, so its like you had no items. At this moment you lose all your spell slots granted by ability bonus from items. No matter that the shape merges the items because the merging is done a slightly later and while it will grant the slots again, the spell you had there will be lost.

 

This is now fixed as ability bonuses are applied before polymorph so you won't lose spellslots from that. But not all shapes merges items and not all shapes merges everything by default so you still lose some slots in polymorphs that doesn't merge items that are granting you the ability bonuses - you follow? This is not handled by the new polymorph engine because this behavior is correct - you are not expected to get these bonuses so the slot removal is expected.

 

The same applies for itemproperties granting bonus slots - the slots from these are lost and new polymorph engine doesn't handle it at all.

 

But the new NWN©X_Patch solves all of this. In polymorph, when the ability is removed, the spell slot is not removed but consumed (that is slot is still there with the spell you memorised but the spell will be used as if you cast it). And for spell slots from itemproperties - if the item granting that itemproperty is merged, then the spell slot won't removed nor consumed. If the item is not merged, it will be consumed. This works together with new polymorph engine - it doesnt need it, but without it you all the spell slots will be always consumed.

 

As I said its very hard to explain, so some examples:

 

A) Wizard casting Shapechange with +12intelligence from items:

- without NWNX: all spellslots from the +12int are lost completely

- with NWNX: all spellslots from the +12 int are consumed but not lost

 

Druid casting animal shape with +12wisdom however +5 on armor +1on helm and +6on amulet.

- without NWNX without ability bonus stacking switch: after polymorph, the wis bonus will be +5 so the spell slots from +6/+8/+10/+12 are completely lost

- with NWNX without ability bonus stacking switch: after polymorph, the wis bonus will be +5 but the spell slots from +6/+8/+10/+12 are consumed not lost

- without NWNX with ability bonus stacking switch: after polymorph, the wis bonus will be +6 because animal shape doesn't merge items only armor category so the spell slots from +8/+10/+12 are completely lost

- with NWNX with abiliy bonus stacking switch: slots from +8+10+12 are consumed but not lost

- with NWNX without new polymorph engine (no matter stacking switch): all spellslots from the +12wis are consumed but not lost

- normally without any of this: all spellslots from the +12wis are completely lost

 

C) Druid/Shifter shapeshifting into wyrmling with +12wis and staff with bonus spell 9 and ring with bonus spell 9 (now assuming ability stacking since that was explained already)

- without NWNX - spellslots from bonus wisdom are intact since the shape merged full +12wis, both bonus slots from items are lost completely

- with NWNX - spellslots from bonus wisdom are intact since the shape merged full +12wis, one bonus slot is intact (because ring merged) and the other is consumed (because staff didnt merged as wyrmling shape doesnt merge weapon)

- with NWNX without new polymorph engine (no matter stacking switch): all spellslots from the +12wis are consumed but not lost, one bonus slot is intact (because ring merged) and the other is consumed (because staff didnt merged as wyrmling shape doesnt merge weapon)

- normally without any of this: everything lost!

 

Now thinking about this - for player it might be convinient to have a switch to allow full merging for all shapes. It wouldn't be a gamebreaker though it would significally improved already strong shape - Tenser, but there is actually no reason why itemproperties shouldn't be merged for all shapes. What you think?

[Bogdanov89]

Honestly i always thought that ALL ITEMS you are currently wearing should 100% scale (merge) with all druid, shifter and wizard forms.

 

It just seems better and simpler that way.

 

Every form gets the full benefit of all of your items and all your feats

 

In short, what affects/improves your character should also fully affect/improve your character while in any shape forms.

 

It would also be awesome if all shape-forms could benefit (use) feats like all those monk unarmed feats, and feats like Power Attack, and perhaps even feats like Weapon Focus (and weapon master's feats for that weapon) IF your shape actually has a weapon of that type.

[Gruftlord]

Hey Shadooow. I have some interesting news. I found 5 slightly varied bark textures inside the vanilla high res erf. They all have slightly different colors and moss coverage and are stored in 512x512. And it seems, that they are the same texture that the low res bark skin was derived from.

I was able to generate new vanilla like high res texture replacers for barkskin. There is currently one i like especially, which has some moss here and there. The bark itself still has some odd red spots, that i will try to get rid of.

In the end i'm not too sure how it will turn out. The current cpp barkskin is higher resolution and also sharper. Then again, the new one would be closer to vanilla and has the nice moss. I'll upload it soon with some comparison pics once its finished

[Shadooow]

It would also be awesome if all shape-forms could benefit (use) feats like all those monk unarmed feats, and feats like Power Attack, and perhaps even feats like Weapon Focus (and weapon master's feats for that weapon) IF your shape actually has a weapon of that type.

Those actually works fine in polymorph

 

But yes, I agree that there is no real reason why all gear shouldn't be merged into shape. It is possible that it is because this feature wasn't there from start and it was one modder who invented it (and he made those categories), bioware inherited it then into official game but kept the categories. It is better no doubt since that way builder has a direct control over this, but seriously, polymorphing suffers with so many issues and limitations that allow to merge everything for every shape won't cause any balance issues at all.

 

Anyway, Iam not considering to replace the categories nor vanilla merging choices. Those will stay intact - builders can always modify this to their own pleasure. But a switch for players to merge everything might be really useable.

 

Hey Shadooow. I have some interesting news. I found 5 slightly varied bark textures inside the vanilla high res erf. They all have slightly different colors and moss coverage and are stored in 512x512. And it seems, that they are the same texture that the low res bark skin was derived from.

I was able to generate new vanilla like high res texture replacers for barkskin. There is currently one i like especially, which has some moss here and there. The bark itself still has some odd red spots, that i will try to get rid of.

In the end i'm not too sure how it will turn out. The current cpp barkskin is higher resolution and also sharper. Then again, the new one would be closer to vanilla and has the nice moss. I'll upload it soon with some comparison pics once its finished

Thats very instesting. I get used to the new barkskin color very fast, but if we can get closer to vanilla then it should be attempted to.

[Gruftlord]

Ok, i think i got a version i'm happy with. One question regarding format: do you prefer dds or tga for cpp? I saw you packed both versions i send you in the new beta. For the record: i just sent both because i did not know which is better for bif files. Maybe the amethyst dragon knows this.

[Bogdanov89]

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!!!

[Gruftlord]

here is a preview of the new barkskin:

 

let me know if you like the moss. i can also use a version without it, but i think the high res texture without the moss looks a bit boring, and the moss adds just the right amount of diversity (and i was surprised how nicelly it spreads across the armor and cloak).

i also managed to make a new texture for the key ground model, that hides the horrible UV mapping, and also improved the belt texture a bit. stay tuned