919 réponses à ce sujet

[Shadooow]

 

That's what I was trying to get at by suggesting modularity.... not make the package an actual collection of modular packets to clutter up the override or have a gabillion different things to install, but have a wider ranger of switches allowing greater amount of choice for the players.  The entire CPP would still have to be downloaded and installed as one package, but the player could turn off whatever parts they don't want for whatever reason and not be precluded from the other CPP content they DO want.

I see. Misunderstood. Thats possible, though, do we really need gazilion of switches? At this moment, current switches includes things that "shouldn't be" but are highly desirable by players (multisummon, gloves boosts), things that "should be" but that wouldn't be well received (shifter merging improvements) and lastly things that are reverting behavior to 1.69 (spell immunity order). But do we really need a switch to revert every fix? In my opinion the only not-clearly-fix is the spell immunity order which is switchable, everything else is fix to me and a switch to unfix would be a cheat. I don't think that CPP should provide cheats, otherwise there would be, for example, a switch to ignore all prestige class prerequisities already.

 

But lets talk about the things that you would want to be switchable then.

 

From the players I've talked to about the patch, they are interested in given aspects, but not all-or-nothing aspect or how it would affect *every* module they played.

For better or worse, the patch DOES change ALL modules the player has, not just ones where the builders set whatever switches... and to set those switches in the first place, the player has to have the CPP installed, which affects, however directly or indirectly, modules that specific builder does NOT set switches on.

 

And I can completely understand your frustration with mods that require constant changing of options/tweaking, and yes, the CPP as a whole is intended as a single simple application of multiple options/mods/fixes... but I simply think it should be up to the end users when all is said and done.  With the license and how you don't want individual parts of the CPP distributed outside of the CPP as a whole (which is totally your right, don't get me wrong on that)... the end user does not have a choice.  And this original point of the discussion was about how "open" the project was, and if specific parts could/should be open for use without taking the entire package as a whole.

Little correction. Patch changes the core game, it doesn't changes modules directly. But since singleplayer modules are using client's core game resources, community patch of course applies to every single module you play. This is a patch and works the same as official patches in this regard - so I don't see why it is a bad thing, considering the CPP is designed specifically to keep default gaming experiences as much intact as possible. Its not House Rule package as some suggests and it doesn't cause any issues with older modules nor any custom content - it won't break any of the module feature/change.

 

Anyway, I am still not sure whether you understood current license - but that doesn't matter because it seems that the current licence will be, whether I like it or not removed .

 

 

Good question.  Perhaps it would be like any other in-game system like death/respawning, resting, ect?  the builder could make the settings known at the start of the module or in a journal entry, or not, and the player finds out on their own?  Same with if the player can override or not.... builder could decide. If he doesn't want unlimited resting and no unlimited summons (or no summons at all), he can make those decisions.

 

It's not unheard of for a builder to make specific game-changing modifications to his or her module... Like say, evasion not working in leather armor as per PnP rules (the guy who made that mod deserves many dragon-hordes worth of treasure ).

Hmm you are right. And I think that builder definitely should make those settings known if he alters them!

 

Otherwise I can see a way how to disable player to override a module switch but there is a big issue. The 1.71 final is out and I dont think its wise to modify it and add anything to it except some high priority fix for issues that CPP caused (none yet - the one bug you found is very minor ). It is possible to alter the switch system in a way that if builder sets a value to -1 it wont be possible to enable that switch. However, to make this possible I need to provide new scripts for players, so players with "vanilla" 1.71 will still ignore this and will be able to override the module settings. (Not to mention that this needs to update quite a great number of scripts and the addon is getting bigger and causes real mess in override folder - as scripts cannot be added to hak from compatibility reasons).

EDIT: even if this would be part of the CPP 1.72, anyone using 1.70/1.71 would be able to override it again. The only way would be to include the scripts in your module - which is no easy task itself as you have to locate them etc.

Modifié par Shadooow, 03 juillet 2014 - 05:43 .

[Shadooow]

but keep the cpp itself as a centered project with a focused head

Which is an entire reason for that licence. I don't really mind that much that someone is using parts of the patch in his module. Its a bad manner as its something you wouldnt do if it was official but the current licence can't stop that anyway, those who wish to do that will do that.

 

EDIT: maybe I can change the licence so it allows using parts of it but to disallow fork the project itself. (Will need a help with wording that though...)

Modifié par Shadooow, 03 juillet 2014 - 05:45 .

[Gruftlord]

I think any major changes currently discussed would probably be outside the skope of a patch addon anyway. What we are talking about here sounds like potential plans for a cpp 1.

Edit regarding your reply above: then just state that they may do so in the license, so nobody has to feel bad for doing it in the first place. You know after all is said and done, the forces that keep the cpp together and moving forward are the people that contribute to and care about it. All the others play no role in the first place, be it positive or negative. I do not think that letting these do with the patch content whatever they like will affect those that do work and provide fixes for the cpp (however big or small) in any way. And thus will not affect the cpp as a centralized project in any form.

A valid concern may be that it may drive some people away from considering the cpp as a whole package in the first place, this is true. But i got two replys to that:
A: so what?
B: it may as well get some additional people to give the whole cpp package a try, after having experienced some of its goods in a module or two

Second edit: i'm totally liking the idea to allow repackaging/distribution but disallow forking. maybe add a line about that the project is open for suggestions in the forums if anything arises that requires clarification or if people would want to contribute their own changes/improvements to the project (as in: proactivelly encourage cooperation as the prefered method over people wishing to fork some parts)

[Shadooow]

Sorry for sounding like a broken record, but it seems like I've been ignored. Is the source for the plugins never going to be disclosed? It seems you got some really nice stuff going on and such but unlike regular NWNX plugins the source does not seem to be available. There's so many more features that can be built on if this is public - such as doing the same thing with allowing items to be used while polymorphed with a 2da check. Heck, I didn't even know you can make it so that it reads an extra column in a 2da, much less fathom the method. There's so many things you can expand on now, without pretty much reinventing the wheel (or finding one, aka the pointers) - such as allowing a 2da check to see if you can cast spells while polymorphed or expand on something more elaborate like making new cursors, additional metamagic, etc...

 

And tbh, what I'm saying is it'd be nice to make it public because as far as I'm aware there's not a lot of NWNCX resources available. The only other one I know besides the original "online fix" is the Sinfar NWNCX one. I assume it's not public, but I have not yet registered on their forums to see (likely not worth it as google cache on their forums doesn't show any evidence of a source code). I'm sure I'm not the only one who's interested in the src.

Ok with a help of virusman, I finally learned how to use github.

 

Here is a NWNX_Patch source. (my working version, last release was 1.5 this has some more stuff inside)

 

Now you can help me to add disabling features via INI. (value 1 disable 0 enable)

 

I won't make source for NWNCX_Patch public because of security reasons. Yes, I could remove the risky content but I am really opposed to the idea of maintaining two versions and all the extra work to do this seems like waste of time to me. I will provide the NWNCX source on inquiry. Who wants it, drop me a PM and state what you want to do with it and possibly also where are you coming from (PW I mean).

[Bogdanov89]

I honestly have no clue what you fellas are talking about over the past 3 pages, but i am very happy to see people wanting to help ShadoOow with the CPP

[MannyJabrielle]

I see. Misunderstood. Thats possible, though, do we really need gazilion of switches?

 

No, I would think that switches only for aspects which do have a particularly significant impact on gameplay.

 

I can give a list of my suggestions as I write up the docs for you, offhand however I could think of two things that I would consider, the bigbies hands spells in regards to 'incorporeal' creatures, and bard instruments.

 

Bard instruments already has a switch in regard to song use/perform skill check, but they still have a significant gameplay change from 1.69 with the instruments not being able to be used while the bard is silenced (bard might be mute, but why would his fingers suddenly be broken and not be able to strum a lute?).

 

For bigbies spells, incorporeal mechanics are not part of the base game in 1.69 or earlier, are they?  That's another change/tweak/fix I could see a player possibly not wanting.

 

 

 

Little correction. Patch changes the core game, it doesn't changes modules directly. But since singleplayer modules are using client's core game resources, community patch of course applies to every single module you play. This is a patch and works the same as official patches in this regard - so I don't see why it is a bad thing, considering the CPP is designed specifically to keep default gaming experiences as much intact as possible. Its not House Rule package as some suggests and it doesn't cause any issues with older modules nor any custom content - it won't break any of the module feature/change.

 

Yes, I understand the modules are affected indirectly, not directly.   And I would agree that a majoirty of the features are virtually invisible to he player.  It's the features that get the "but I wouldn't particularly like that" response when I've told friends about the patch and all the good stuff it has.

 

 

 

Anyway, I am still not sure whether you understood current license - but that doesn't matter because it seems that the current licence will be, whether I like it or not removed 

That could be... Perhaps a re-wording of the license for clarity is in order.  And don't misunderstand me... I agree with Gruftlord's and Hensua's opinion that since you are pretty much the only person maintaining the project, the decision is ultimately yours.  We might offer our opinions, sometimes very strongly (I have been known to do that), but the project IS ultimately your work and efforts  If you really really want something, you're the one doing the work, you're not really obligated to make changes I or anyone else may want if you don't want to make such a change.

 

 

Hmm you are right. And I think that builder definitely should make those settings known if he alters them!

 

Otherwise I can see a way how to disable player to override a module switch but there is a big issue. The 1.71 final is out and I dont think its wise to modify it and add anything to it except some high priority fix for issues that CPP caused (none yet - the one bug you found is very minor   ). It is possible to alter the switch system in a way that if builder sets a value to -1 it wont be possible to enable that switch. However, to make this possible I need to provide new scripts for players, so players with "vanilla" 1.71 will still ignore this and will be able to override the module settings. (Not to mention that this needs to update quite a great number of scripts and the addon is getting bigger and causes real mess in override folder - as scripts cannot be added to hak from compatibility reasons).

EDIT: even if this would be part of the CPP 1.72, anyone using 1.70/1.71 would be able to override it again. The only way would be to include the scripts in your module - which is no easy task itself as you have to locate them etc.

 

Yes, I like when module creators put pertinent info about gameplay changes into the module's description.  It's a great benefit for the player who can see important notes when they click on the module within the game.  Not mandatory, but nice.  And bug?  I still haven't had a chance to figure out if that glitch with circle against alignment was a bug or just a glitch yet  Last bit of actual NWN playing I did was WCOC as a fighter type.  Been too busy as of late with modding stuff real life to do any more playing than that.

As for all these ideas for changes, after I get the stuff to you I already promised I'll add looking into how that third-party tool might be implemented and try to figure out how any of these ideas could be done without override clutter, ect, that is if it can be done at all

[Shadooow]

No, I would think that switches only for aspects which do have a particularly significant impact on gameplay.

 

I can give a list of my suggestions as I write up the docs for you, offhand however I could think of two things that I would consider, the bigbies hands spells in regards to 'incorporeal' creatures, and bard instruments.

 

Bard instruments already has a switch in regard to song use/perform skill check, but they still have a significant gameplay change from 1.69 with the instruments not being able to be used while the bard is silenced (bard might be mute, but why would his fingers suddenly be broken and not be able to strum a lute?).

You are confusing silence with deafness. Character is mute under deafness effect where ge now got 20% chance to failure (even if he doesnt sing and only playing instrument) but silence prevents any sounds from the character no matter that they come from the mouth or instrument. Keep in mind that silence is usually not a character state but an area of effect and affect certain area, whether centered on a player or location - in this area, no sounds are possible and where there is no sound there are no bardic music benefits. Bardic music is completely dependant on the sound, but not voice. AFAIK there is not even a feat(mean in additional DnD books) that would let character to use bardic music in zone of silence.

 

 

For bigbies spells, incorporeal mechanics are not part of the base game in 1.69 or earlier, are they?  That's another change/tweak/fix I could see a player possibly not wanting.

Incorporeality is a character status that was already there. There was also already a code that handled it in certain spells such as entangle or web so these spells shouldnt affect incorporeal creatures. Though, due to the bug this never worked. CPP fixed those and expanded the spells and abilities where this has no effect.

 

Just to remind you, incorporeal creatures doesn't have a physical body and as such their are not solid. They can move through other objects (not implemented in NWN, though in CPP they can now move throught other creatures) and they cannot be grappled, held, knocked down (probably not even blown out).

 

From this reason I consider it to be a fix, though a little hardcore rule fix it makes sense.

[Gruftlord]

it's a fix, no question. i think nobody here objected to it. the point is still: some people do object, and it doesn't matter if their reasons make any sense to us or not. it is things like these, that while they do fix some exploits, also do change the gameplay/balance a bit, that some people will object to, no matter what.

some people like their exploits/litte quirks in the game, and have been using them for over 10 year now. maybe their favourite character exploits them, maybe they just do not like change at all. it may be a fix for an obvious bug, or an exploit, or something that should adhere to PnP rules. the reasons may be sound, but this will still not convince them (i'm sure Manny brought up some vaild reasons to them as well).

 

here, you are preaching to the choir. we know why some things are changes, and we are ok with it. the suggestion is aimed at those who are not. if it is reasonably (time and complexity) possible to add a switch, for a select few issues, that some people object to, why not give them the freedom to chose which exploit they want to continue to use?

i think once Manny goes through the documentation and resturctures the fixes, the list he will come up with of fixed exploits will be reasonably short, and it might be worth considering adding a switch to them. not because they may be invalid fixes, but because some people will not like them (and not use the CPP with them) no matter what.

 

in other words, see those exploits/rule breaks as house rules, that people have been using for the last decade in NWN. the CPP should empower DMs to change the old rules (they couldn't before, now they can with CPP), but should not force them to change their house rules if they do not want to. we should not judge them for the selection of house rules they want to use.

added switches for such changes/fixes (and i think they are few), would speak that language pretty clearly.

[Shadooow]

I know, but is this project suitable for these players? To add a module switch is quite easy to do and there are no other problems than the list of them getting way too big which makes deciding of what you want harder. With any new switch like this, those who don't mind this change will be confused by the switch presence and might misinterpret it and apply it even if they like it.

 

(Putting aside fact that silence effect is quite rare to obtain (generally) and musical instruments aren't common items at all. And that unless you play a module called "Attack of the spectres", you won't encounter incorporeal creatures very often and even if you do, there are other spells you can use on them, why would anyone tried to cast bigby is unknown to me, mainly because they have a damage reduction so the bigbies does no damage to them.)

 

Imo adding switches that restores fixes is not in scope of this project. Peoples who want to play this way will not be generally interested in this patch itself, only in certain new features - but they won't want to pay the price for them and thats allright I think. I don't think I can provide a:

- switch to remove metamagic exploit so they can double duration of potion buffs again

- switch to add bard class usage into scrolls that possess spells not castable by bard, so they can use it without UMD again

- switch to make aura AOEs dispellable again, so they will be able to dispell dragon fear aura again

- switch to restore old curse song behavior, so once they sing the curse song they will be immune to curse song of others

etc.

[Gruftlord]

i see, you are right. that list might be longer than i expected.

[Shadooow]

i see, you are right. that list might be longer than i expected.

Exactly. I don't think that CPP should be trying to gratify everyone. Players who want to play this way has a right reason not to use patch and thats fine. It doesn't mean the CPP is bad or wrong, it does exactly what it should and its a pity it doesn't suit everyone, but thats expected. Fortunately, it is optional so unless builder decide, you can play any module created with 1.71 with vanilla 1.69 as well which solves all potentional issues and builders are not losing an audience.

 

1.69 also didn't provided a switch to restore the original holy avenger dispel magic behavior (which could dispel everything even monster auras or petrification). Thats not the patch's resposibility - if someone doesn't like this he have to modify it afterwards - which CPP still allows. I even think that one persistant world stayed on 1.68 for this reason, was some kind of arena, its probably down for a long time since players with 1.69 didnt saw this server and I think they even couldnt log in.

[Shadooow]

Anyway, when I was thinking about those musical instruments and silence and re-checking DnD rules and forums I get this idea to improve silence casting in AI.

 

At this moment, AI casts this spell targetted to PC - which gives him saving throw to avoid it completely and in case he fails, it grants him a benefit as the silence zone is centered on him and moving with him so he can reach the original caster and make him silenced and prevent him to cast spells (which is common tactic on PWs where player casts it on himself voluntary - usually because he has silent spell feat - AI is helpless under silence.).

 

Therefore I think that the AI should cast it on the PC position, granting him no save. Player will be able to escape the silence zone but it still make the spell more potent than normally.

 

Also, I realized that silence should probably remove the benefits of bard song and penalties of curse song. But thats probably too hardcore as it spoils the usual self-silenced tactics for bards.

[Gruftlord]

re position casting: maybe a 50% chance for either option? then it would be a bit more unpredictable of what happens

 

re bard song: i'm not sure the bard is supposed to sing (or whatever it is interpreted as by a specific player) during the whole duration of the song. i allways thought the bard does something inspirational once, and motivational effect then lasts for a bit. so, it would have never come to my mind to drop the effect once silenced (after the song has already been sung)

[Shadooow]

re position casting: maybe a 50% chance for either option? then it would be a bit more unpredictable of what happens

 

re bard song: i'm not sure the bard is supposed to sing (or whatever it is interpreted as by a specific player) during the whole duration of the song. i allways thought the bard does something inspirational once, and motivational effect then lasts for a bit. so, it would have never come to my mind to drop the effect once silenced (after the song has already been sung)

he is supposed to sing the whole duration, however bioware simplified the whol bard singing at minimum, in PnP this works completely differently:

- multiple songs, each doing something else and bard can sing only one at the time

- song as an area of effect that has a 5round (*2 with lingering) echo so even if you no longer hear the song you still has its benefits for some time (thus if bard cast song 1 then sing song 2 and after 5rounds he start sing song 1 again, he can keep both songs benefits on all his allies all the time

- no spellcasting during singing - casting a spell cancel current song - however attack and other actions is allowed (if there are exceptions I dont know them)

 

So removing the bard song benefits upon silence probably not fits the NWN song implementation. As per DnD, silence will interrupt character from singing (if he is the singer/instrumentalist) but there is the echo till you still get benefits.

 

Nah, not a good idea. Maybe someday I will release the PnP bard songs which I implemented for my module already...

[Bogdanov89]

ShadoOow, i got some new save game files that i think might show some AI bugs - if you could please take a look at them, it would be awesome

 

http://wikisend.com/...881892/possible bugs.rar

 

The zip file should be about 11 megabytes heavy - short description of saves:

 

If named "passive" then to me it looked like the AI was not trying to fight.

"No heal" means he did not heal me when he was supposed to.

"Bash stuck" means my henchmen got stuck when i tried bashing a chest - he did not move from that corner until i was almost the entire zone away.

"Missing henchmen" is a save in which my hench Lina (the cleric) died (i think it was from a trap) but she did not appear back in the temple (or anywhere else), and i never saw her again in that chapter.

 

 

Also, a few questions about the minimap in NWN:

 

1. Since i am playing NWN at a very high resolution (i think it is 1920x1080), the minimap is very small even when i zoom it fully.

Could you perhaps make the minimap bigger for higher resolutions, or perhaps allow us to make the minimap bigger by zooming in more?

 

2. When in full zoom, the minimap usually centers on your current location and "cuts off" (hides) areas/corners that it thinks are too far to matter.

However i find this extremely annoying, especially since the minimap is still too small for my high resolution - while it insists on hiding valuable map portions because it wants to be compact!!   

 

3. Is there any way to prevent the minimap from automatically out-zooming when i change zones/places (after loading screen)?

I always want my minimap to be as big as possible and having to constantly zoom in after every zone loading is definitely annoying.

 

Overall i want my minimap to always be as big as possible, and i also want it to be forced to display every corner of the zone i am in.

The damn minimap keeps trying to hide big parts of it so that it is compact, but due to the resolution i need the exact opposite - i need a huge minimap that shows all corners...

 

Is there anything you can please do to improve the minimap?

I assume in the form of an optional (separate) file, so that people don't have to use the minimap changes if they don't want to?

[Shadooow]

Okay. I see no way how to alter minimap. Maybe it is possible to somehow enlarge the minimap GUI but I doubt that game will be able to work with that...

 

As for saves:

 

- 000046 - new bug 1 - what is problem there? havent seen anything unusual

- 000047 - new bug 2 no heal - she didnt healed you because there was enemy around and she doesnt possess combat casting so he doesnt heal in melee combat unless she is very badly wounded but that doesnt apply on you as her master - in this situation you must order her to heal you manually - its intented. As soon as I killed that last convict she started healing me.

- 000048 - new bug 3 passive - when I load it, she stands over there not doing anything but in a second she helps me without me need to order anything

- 000050 - new bug passive 2 - she attacks as soon as I load it, he even use turn undead and kill all zombies around

- 000051 - new bug bash stuck - when I load it she is not bashing anything, and I didnt have a problem with her following me - but sometimes this happens and she really stuck in some corner - in such situation you need to "bump" her
 

will cut this - all the passive bug saves are working for me - please redownload the 1.71 patch addon and make sure you overwrite all files when you copy it into override.

 

Will try to look where Linu is in that bug with temple but this looks like a OC specific issue and this is at this moment out of CPP scope.

[Shadooow]

Some update on the global switches.

 

At this moment, the switch won't be possible to enable if builder set a value of -1. However in opposite situation where builder wants to enforce a positive value I see no seamless way to do that. So I ask - is this needed at all? Ie. if builder sets that you can boost gloves with spells, is it needed to restrict player from undoing that? A specific switch where this would be preffered?

 

EDIT: realized that there is a "negative" switch like that in vanilla - to drop expertise when casting. Ok I see it is needed. Nevermind.

[MannyJabrielle]

On the minimap.... When you zoom in and the "edges" get cut off, you can click on the minimap edges and scroll it up/down/left/right.  It's easy to miss even at lwer resolutions, but when an area's large enough and the minimap can't show all of it, scroll bars appear along the top and one side.

[Shadooow]

Okay here is an idea.

 

To enforce a given switch wont be possible to activate builder needs to set it wit value of -1.

To enforce that all enabled switches wont be deactivated, builder needs to set a new switch 71_DISALLOW_DEACTIVATE_SWITCHES to 1.

 

Would that work?

[Shadooow]

"Missing henchmen" is a save in which my hench Lina (the cleric) died (i think it was from a trap) but she did not appear back in the temple (or anywhere else), and i never saw her again in that chapter.

She is from some reason outside of the hall of juctice.

[Shadooow]

One more time about the switches. Very important.

 

Do you, singleplayer module builders, really need the feature to disallow player to deactivate/activate module switches?

 

Because there is no ultimate way to do that - if player wants, he can open the module in toolset and disable this restriction + if he will play with 1.70/1.71 regular versions he won't be restricted to do that at all - its not possible to make this restriction backwards applicable, other than including around 100 scripts and the pc widget conversation inside your module.

 

Which to me, are a reason to abadon this idea...

[MannyJabrielle]

To *disallow*, no.

 

As you stated, the player could open the module up and change it themselves anyway, just as with any other aspect of the module.  As builders, to limit switch availability for the non-toolset savvy player if that's what we really want to do, all we have to do really is overwrite the widget convo with a custom converation in our module.

[Shadooow]

 

 all we have to do really is overwrite the widget convo with a custom converation in our module.

Hmm you are totally right. That will effectively prevent player from changing module choices.

 

Cool, then I don't have to making up various mechanisms.

 

Currently, in my working copy the switch system works this way:

- when a switch is set, the switch value is saved also globally into vanilla database (database name is CPP)

- when a switch is read, first, value set on module is retrieved - if the value is not zero its this value that is used AND as a special case if the value is -1 then its substituted for 0 / FALSE in order to ensure that scripts written like this ' if(!GetModuleSwitchValue("some_switch")) ' will behave correctly as if the switch was disabled

- if the switch isnt set in module, then a value from player's database is retrieved and used

 

Thus. If builder want to enforce some switch to be disabled, all he need to do is to set this switch at value of -1. (Plus possibly overwrite the PC Widget convo to disallow player to overwrite this switch.)

EDIT: crap, that -1 feature won't be backwards applicable again. dammit *thinking hard*

 

 

BTW, it looks that I found another CPP bug. The wounding itemproperty code in OnEquip is missing, so this property probably doesn't do anything...

 

To enable this, put this code into your OnEquip event:

    if(GetItemHasItemProperty(oItem,69))//1.71: wounding item property handling
    {
        itemproperty ip = GetFirstItemProperty(oItem);
        while(GetIsItemPropertyValid(ip))
        {
            if(GetItemPropertyType(ip) == 69)
            {
                ApplyWounding(oItem,oPC,GetItemPropertyCostTableValue(ip));
            }
            ip = GetNextItemProperty(oItem);
        }
    }

Modifié par Shadooow, 05 juillet 2014 - 10:17 .

[Gruftlord]

hey shadoow, i have a few more bugreports, and also fixes for you.
i have been looking at the doa ground models in CPP, and found some odd things with them.
the thieves kit and the cloak ground model use vanilla textures, which have horrible "rainbow discoloration" (odd green and red sparkles, where the color should be an even skin color for example). i was able to fix this with gimp.
i modified the texture of the belt to give much better results with the odd texture mapping.
and last i found the vanilla texture that healers kit is based on, and was able to replace the doa texture with the high res texture. this also got rid of the red cross, which i think makes it more consistent with how the inventory icon looks.


on top of this, i found some more bugs with hem, that i were not able to fix:
the thieves kit and bracer model has very odd triangles in certain places and the texture mapping of the belt and key are absolutelly horrible. would be nice if someone with mesh skills could look into those

[Bogdanov89]

Okay. I see no way how to alter minimap. Maybe it is possible to somehow enlarge the minimap GUI but I doubt that game will be able to work with that...

 

As for saves:

 

- 000046 - new bug 1 - what is problem there? havent seen anything unusual

- 000047 - new bug 2 no heal - she didnt healed you because there was enemy around and she doesnt possess combat casting so he doesnt heal in melee combat unless she is very badly wounded but that doesnt apply on you as her master - in this situation you must order her to heal you manually - its intented. As soon as I killed that last convict she started healing me.

- 000048 - new bug 3 passive - when I load it, she stands over there not doing anything but in a second she helps me without me need to order anything

- 000050 - new bug passive 2 - she attacks as soon as I load it, he even use turn undead and kill all zombies around

- 000051 - new bug bash stuck - when I load it she is not bashing anything, and I didnt have a problem with her following me - but sometimes this happens and she really stuck in some corner - in such situation you need to "bump" her
 

will cut this - all the passive bug saves are working for me - please redownload the 1.71 patch addon and make sure you overwrite all files when you copy it into override.

 

Will try to look where Linu is in that bug with temple but this looks like a OC specific issue and this is at this moment out of CPP scope.

 

I am sorry for wasting your time

I was sure that those saves (the "passive" named ones) had the passive AI bug occurring again...

I reinstalled the 1.71 latest Addons (v3) as you suggested, so far it seems to work fine.

 

 

I got a long list of suggestions and potential bugs, if you could please take a minute to read and consider them:

 

1. Could henchmen/companions be changed so that they always prioritize buffing the player's character instead of themselves?

I always find it kind of a waste for my Cleric henchmen to first buff herself with all those nice buffs (like Bull's Strength) - and then she does not have more to also buff up my Barbarian/Fighter/Weapon Master character (who can make much better use of the buffs)

 

I suppose the AI should first cast party-wide buffs (that affect everyone at once) and then just cast buffs on the player's character - and skip buffing themselves completely, so they have more spell slots for other spells (like spontaneous casting/healing).

 

Honestly it seems that those spell-caster henchmen (cleric, sorcerer/wizard, bard) should always FIRST buff the player's character (unless the player is a wizard/sorcerer who does not benefit from most combat buffs like Bull's Strength).

In fact, it is probably better if the henchmen ONLY buffs the player (and not themselves) - and leave the remaining spell slots for casting other spells (like spontaneous healing from cleric).

 

2. I see two (locked) chests in a room.

I approach and click on the first and it says "locked" - my henchmen runs over to that (first) one to unlock it or bash it.

At the same time i run over to the 2nd chest and click on it (says locked) - my henchmen interrupts his own lock picking (or bashing) of the first chest to run over to the 2nd chest (where i am) to try and lock pick that one, thus wasting a ton of time...

It would be much better if the companion insisted on finishing the (first) lock pick he was already very close to completing, instead of abandoning a near completed job...

 

Could you please make it so that when a henchmen/companion/pet starts doing Lock Pick (or bash) they will not interrupt it unless their master directly orders them something like Guard Me or Attack Nearest?

Also if the master manually orders a new "Pick Lock" command (radial menu) while the AI is already in the middle of a pick lock or bash, the companion/henchmen can be forced to abandon his current lock pick (or bash) and try to lock pick (or bash) the chest the master is the closest to (or the chest the master is trying to bash or lock pick).

 

3. Could the companion/henchmen AI be forced to hug (in melee) his master when the AI is planning to cast party-wide buffs as well as buffs that should be cast on the master (like bull's strength)?

A lot of times at the start of a fight my companion will immediately start buffing - while my melee character is running ahead to fight the enemy.

So when my henchmen finishes casting her buff, i am usually either out of range or behind a corner/wall...

 

Forcing a henchmen to approach it's master FIRST and then attempt to cast a buff would help a lot... especially if the henchmen will try to approach the master before EVERY buff to insure that they all properly reach the master.

 

4. I am loving the new "permanent combat modes" change you made (where power attack does not turn itself off).

However the icon (of power attack, for example) changes very little depending is it on or off - just a very tiny white square appears around the power attack icon when it is on, and it is very hard to notice on high resolutions... which means i gotta open my C panel every time i need to check which combat modes are actually on at that moment

 

Could you please make the icons of combat modes be more noticeably changed when the mode is on?

Perhaps something simple like "invert colors" of the icon when the combat mode is on (like power attack) would be fantastic, it would not require much work but would be instantly recognizable is the mode on or off.

 

5. Could the companion/henchmen AI be told not to try and cast spells that are borderline useless?

I think the AI will try casting a spell that can never work against certain enemies (like death magic on golems, or a low level daze against high level enemies).

Also certain very weak buffs (like Virtue) are just not worth a spell slot and would be better if the companion never wasted time to cast them, and instead saved the spell slots for healing or other more useful spells.

 

6. The Whirlwind attack seems to work a bit strange:

It seems to sometimes automatically cancel my previous "attack" command, meaning that my character will stand still (passive) after performing the Whirlwind - and that is horrible in a big fight...

Sometimes after doing a Whirlwind it will automatically queue an Attack command on a certain creature around my character, and if i want to do more Whirlwinds after the first Whirlwind i have to manually cancel that automatic Attack command in the top-left corner.

Overall the Whirlwind attack seems to be plagued by some "automatic adding of an attack or cancel-attack" bugs, where it will sometimes either add (or cancel) an attack command for no reason...

 

7. A minor bug that is a bit strange and it will not always happen.

When i use the W keybind (move forward) to go through a zone (loading screen), my character will do a 180-degree turn once he "zones in", meaning that if i press W again i will walk back through the same "portal" that i just came through!

My camera is set to "top down" if it is of any significance... anyway it is a minor bug, but kinda annoying when i press W and end up walking back through the zone "portal" that i just came out of - meaning i gotta load the previous zone, and then again load the new zone i wanna go to >.<

 

8. Is there a way you could make consumable things like First Aid Kits and potions be purchased in big groups of 5 or 10?

Either some new way to buy them in groups, or just to very quickly buy them 1 by 1, or perhaps if the vendors themselves could sell them in groups of 5 (or 10)?

 

9. NWN wiki says that barbarian Mighty Rage can be stacked with the regular Rage (or Greater Rage) if casted in a specific order:

"one can use mighty rage then barbarian rage to get the effects of both."

That honestly seems like a bug - it should either stack regardless of casting order, or it should never stack at all.

Did the CPP perhaps fix this double-rage issue in any way?

 

10. Any way for the companion to cast spells like Restoration (or whatever else) in order to remove harmfull spells/effects from it's master - like casting restoration to remove attribute decreases, or casting "whatever" to remove paralysis/fear/daze?

Also any way for a companion to be made to do dispel magic and spell breach on mages/creatures that have valuable buffs/defenses that can be removed/dispelled?

 

11. Sometimes my companion will stand still at the beginning of combat (passive), and after about ~5 seconds he will properly join the fight.

Is there any way to remove or reduce this occasional passive time that the AI sometimes takes before joining a fight?

 

12. If a henchmen or pet/companion has Sneak Attack, could the AI be told to prioritize attacking targets that it would get the Sneak Attacks against?

If i (a fighter) and my henchmen (rogue Tomi) are fighting multiple foes - can the AI make Tomi prioritize attacking the enemies that are attacking me, so that he can utilize his Sneak Attacks?

 

13. When fighting creatures that can turn invisible, my character behaves strangely:

I am fighting a clearly visible Imp in Melee.

The imp casts invisibility, but i never lose sight of the Imp (he becomes transparent, but i still see him).

For some reason, my character stops attacking and goes into the "passive" mode!

I click to attack again... when the Imp's invisibility expires (goes away), my character again goes into the passive mode (stops attacking)!

I click yet again to attack... if the Imp again recasts Invisibility, my character will again stop attacking - even though he can see the Imp!

 

It seems to me that the act of becoming Invisible or losing Invisibility makes player character (or perhaps all characters) lose their "attack" command...

It seems like a minor bug, but really annoying... especially since i can see the damn imp the entire time in melee!

 

14. If my companion/henchmen has the Find Trap or Knock spells, can there be an option for me to order him to cast it?

The caster companions would be much more useful if they could cast Find Trap and Knock spells (if they know those spells).

 

15. My camera controls are behaving rather strange since i installed the 1.71 CPP and it's v3 addons and the NWNC/NWNCX Loader (also the hyper gore and 50%/75% empower/maximize addon you made).

My camera zoom is either extremely fast or very slow - same goes for my camera turning/rotation (both with middle mouse button and by moving cursor to any edge of the screen), it is either very fast or very slow!

I tried changing all the camera speed and camera mode options in the NWN settings but nothing has helped

I think the camera work fine if i play NWN without any mods/addons/patches.

 

16. It would be very nice and helpful if the player could see ("identify") what spells are his party members (both allied players and hench/companions) casting.

It would make sense for your teammates to "tell you" which spells they are casting - and it would also be quite useful for the player to be fully aware of what spells are his party members casting.

Overall it does not make much sense to me that you need Spellcraft to know what spells your ALLIES are casting - they can just tell you the name of the spell, and it is just great for coordination

 

17. Sometimes when i tell my companion/hench to "handle" a ground (not chest) trap we can see (they don't have disarm trap), the companion will walk to the trap's corner and then along the very edge of the trap - but it will not trigger the trap!

After this walk on the very edge of the trap's trigger area, the companion will return to me like it has done it's "handle trap" job!

 

Usually the companion will properly run into the trap we can see when i tell him "handle trap" and he has no disarm trap - but, sometimes, they will do this "on the edge" walk around the trap... trolling AI

 

 

Thank you very much for reading and helping out!