AI ChooseRandomSpellFromList - range, has LOS and slots issues

[anatoliy-savchak]

In Orc Cave of IWD there is Orc Shaman, AI of whos is using this ChooseRandomSpellFromList way of determining of spell selection.

What I have seen in my playthroughs: 1) Split to #609; Shaman would target Hold Person onto PC even if Shaman is not visible due to FoW on the screen. Range in the spell allows that but the Game visibility - not sure, open for discussion. 2) Split to #609; Shaman would target Hold Person onto PC even if Shaman does not have Line of Sight. That should not be possible. See Spell Aim \ Target: "You must be able to see or touch the target, and you must specifically choose that target." PHB p 175. 3) Split to #610 ; Shaman would use Sound Burst even if Shaman is way too far to be within a range of the spell. I saw same thing in ToEE. 4) Cancelled: Shaman would use Sound Burst several times although Proto specify the spell only once. 5) Alert issue, current one. Moreover initial encounter in Orc Caves alerts EVRYBODY in the cave and there is continuous fight with 20+ orcs, a Shaman etc.

[DudeMcDude]

4. Can you verify his script doesn't replenish his memorized spells?

[DudeMcDude]

BTW just wanted to note that it's easy to add the check, but to truly fix this the AI must be able to approach just enough to cast the spell, and ideally also judge whether it should do it in the first place.

[anatoliy-savchak]

Sure it's obvious change, but it could potentially affect ToEE module. That's why I have not proposed solution. Just informed.

Moreover initial encounter in Orc Caves alerts EVRYBODY in the cave and there is continuous fight with 20+ orcs, a Shaman etc. I need to confirm such behavior in the vanilla IWD first before saying if it is design error. Right now it is unplayable.

The best fix would be to disable ChooseRandomSpellFromList as I do in zmod modules and do spell cast AI manually, where I check for all of these requirements. Not sure about this meddling at the moment.

[anatoliy-savchak]

They should not alert everyone in Orc Cave, see this ( time: 17:22): https://youtu.be/FDx90D9TzME?t=1041

[DudeMcDude]

They should not alert everyone in Orc Cave, see this ( time: 17:22): https://youtu.be/FDx90D9TzME?t=1041

Are you sure this is a Temple+ issue? I think the Co8 guys purposely changed their positioning to trigger each other. I believe this is not the original layout:

[anatoliy-savchak]

I would say it's pretty close to vanilla:

[anatoliy-savchak]

I still see your point Sitra. Open question is does it work same as in vanilla ToEE...

[DudeMcDude]

In vanilla the groups have well defined separation: the first 3 is group 1, group 2 is the next 4 orcs, and only then you get the big chamber with the shaman. In the TC you can see there's potentially a continuous connection between all these groups.

Having said that, it is true that Temple+ allows to alert AI allies at a big distance when there is line of sight, which can chain trigger the main chamber even at vanilla IWD distances. I just tested what happens when removing the code that pulls in allies, there are indeed much fewer combatants. I'll have to think about what to do with that.

[anatoliy-savchak]

I thought you moved that part to Python

[DudeMcDude]

I moved ConsiderTarget to python, but not Subturn (see Subturn in combat.cpp) which also has code for adding combatants (originally just around the PCs, but I adapted it to also add AIs).

BTW, I looked at the history of that code. Apparently it started out at range = 12 tiles, which is more or less the fog of war distance I think, and then it got changed to 19 and finally 24 (current value). That's indeed quite a long range. Unfortunately I didn't document why, but I suppose it's due to testing some encounters and seeing AIs not recruiting their friends in open ground. The classic example is the Moathouse brigands - in vanilla ToEE you could usually pick them off one by one. However even with 12, and the positioning I posted above, the main chamber will be triggered. If the Orcs patrol a little it might not however (e.g. the first group is supposed to approach you, so they should break off from the 2nd group at least).

[anatoliy-savchak]

Please consider moving that part to Python, and not rushing fixing that in cpp. That is crucial for new modules including IWD2.

[DudeMcDude]

Can you split this to multiple issues?

[DudeMcDude]

LOS issue: I've successfully added LOS checks to cast_fireball and cast_area. 1bf40019c16fa4fc21e5b3b39c0c8dc29071b033 But now I remember why I was reluctant to add that: the AI is not smart enough to tweak the AoE center so that it hits around the corner and such. Todo..

[dolio]

So, this is probably something that would be hard to fix fully, but...

Fireball, for example, is supposed to go around corners anyway, because it's a "spread". I think ToEE treats every area effect as a "burst"/"emanation", where you have to have line-of-effect from the center of the area. But that's not proper for a bunch of spells.

I guess even if that were implemented correctly, the AI wouldn't behave correctly for some spells. But it might fix a lot of relevant examples.

[DudeMcDude]

Oh, I did see that the Area picker has a flag for bypassing LOS check. But that'll also go through walls where it shouldn't... I should probably prepare a coarse blockage grid for calculating this sort of stuff. ToEE's fine grained grid is visually nice, but it makes these sorts of calculations needlessly complex...

[anatoliy-savchak]

1. Can you verify his script doesn't replenish his memorized spells?

Not confirmed - it was due to two Shamans. I withdraw the claim, it works fine.