Do you mean, the loop should account for multiplayer multiparty modules/campaigns?
The buff code uses ally lists which include both friends and faction members. A neutral that is not in the same faction as the PC should not get buffed. A quirk of how NWN2 works is that companions are neutral but in the PC’s faction - they are not friends.
The code that builds the ally list is in hench_i0_target, InitializeAllyList.
The most that could be done is to only use faction members for the out of combat pre buffs. Not sure about that one. During some combats, friends can join in the fight, and they would make decent buff targets.
Yes, well at least one party with multiple PCs in it. But if you do that, may as well do multiparty PC.
So it needs more check between factions, or if they are in combat. I will check if I set the factions to “50” if avoid the buff on neutral party. Setting the NPC at 50 seems to work.
Hello. I would like to ask about nwn2fixes. Whether fixes can be made please
- Ford Locke crypt - fixes traps in corridor to not damaged enemies
https://i.ibb.co/Dz2hTpd/fix.jpg - screen
- Highcliff Catacombs - make to black priest equip and use maсe that he has in his inventory
Those sound a bit like customizations (not fixes). although Tony might want to look at the black priest not equpping a weapon (if that’s what’s happening)
Please post suggestions for Nwn2Fixes to the Nwn2Fixes thread …
Thanks. I have copied my post to the Nwn2Fixes theme.
The shadow priest only has simple weapon proficiency. Martial weapon proficiency is required for the warmace. When the AI runs the NWN2 call, ActionEquipMostDamagingMelee, it must be unequipping the weapon because the priest doesn’t have the proficiency feat. The default AI does not equip weapons, so it is unaffected by the mismatch. A special workaround just for the shadow priest would have to done to fix this.
Edit to add.
A more elaborate general workaround for the problem could be done by giving the creature the required weapon proficiencies for their equipped weapons.
I was scared it would be an AI problem.
But now you have 2 problems.
As you said, you can’t equip an item if you don’t have the proficiency, but you can’t equip an item if the item is undentified as well.
But if the item with default AI is equiped, it stay equiped no matter what. Your AI behave more according to the rules, but “module maker or Game maker”, tend to cheat a lot with them.
Equipped weapons are auto identified by the AI so that situation is covered.
Did you edit the on death script to unditified items upon death ?
No change to the death script.
In order to get better behavior with weapon use mismatches, I have changed the initialization routine to only identify weapons if weapons are found in the inventory. If none are found, the auto weapon switch is turned off using the same behavior setting switch that companions have. This should leave unequip-able weapons as equipped for use in combat. More could be done to make identified non droppable copies of the weapons, but I don’t know about going that far.
I have considered having the auto create items routine give non droppable melee weapons to ranged weapon users unless they have feats like point blank shot. Since the default AI doesn’t switch weapons, this simple optimization is frequently not done by module builders.
Edit to add:
Testing shows that weapon proficiency feat mismatches cause the weapon to be unequipped without the AI being involved. This is true for monsters directly put into the area but should also happen with spawned monsters. The editor shows the weapon equipped, starting the module as a player shows no equipped weapon. I really don’t want to mess around with giving the monsters the correct feats so it will up to the module builder to catch this, I guess. I will leave the code in to only identify weapons if weapons are in the inventory.
Question for Tony or anyone else who knows:
Does the AI judge the “threat level” of NPCs based on each individual character level, or an average of the levels across the party?
I know that it’s not intended to be played this way, but I imported my MoTB character into SoZ. I stuck him on parry mode permanently and am playing it as if he is shepherding or coaching a team of new adventurers.
The issue is that none of the other characters are activating any of their class abilities or casting any spells. Barbarians don’t rage, druids don’t wildshape, wizards don’t cast. I am wondering if this is because they are assessing the threat of enemies from the perspective of my level 26 “main character” and deciding that nothing is worth activating these abilities.
If that’s not the issue, does anyone have any suggestions? The mod worked beautifully with MoTB, but it appears to do nothing at all when playing SoZ.
Thanks!
@pyro ,
The AI does consider party members in the decision to cast spells. The high level of the PC relative to the rest of party is causing the issue. The routine is written with the idea of a party of nearly equal levels trying to get an estimation of the relative monster challenge. After setting the party members to overkill casting, I don’t see a workaround without changing the function GetEnemyChallenge or adding an unlimited casting option.
Fair enough, like I said… not using it as intended lol. It was absolutely fabulous for MoTB, though, so my thanks either way.
I did try overkill mode, and pretty much every other setting combo that could be relevant. I did also try running combat with the Wizard ENTIRELY unarmed and empty inventory to see if that could get her casting, but no dice.
IF… hypothetically speaking, someone moderately savvy (but not entirely familiar with NWN2 modding), wanted to change that function, could it be done on the user’s end? I know sometimes these things can be relative simple to tweak.
Fortunately, only one script needs to be changed and compiled. In the hench_o0_ai script, find the call to “fChallenge = GetEnemyChallenge();”. If you change the line of code to: “fChallenge = 10000.0;” and compile it everyone in the party will start using feats and spells in all cases.
I have also thought about changing the radio button spellcasting threshold options to be a sliding scroll bar. This would allow more levels to be set in less space but would be harder to implement.
Any news about new version?