Charm, Confuse and Dominate cancelled prematurely [3.03]

[Jojobobo]

I know that the premature cancelling of these effects was on the player character was introduced to stop time wastage if there were no other friendly targets around, but reasonably often it causes these effects to be cancelled on the opponent too. I'm not sure if this is a result of them not targeting another enemy fast enough, but it's problematic when you have a limited number of spell holdings for Charm/Dominate on an item already.

 

If possible, it might be better to go back to the old system for enemies (full duration of these effects, regardless of whether their are other friendlies around, which as I mentioned the game often has difficulty detecting) but keep it as is for the player character. I'm not sure if this would be doable or not, but I thought I'd float it out there anyway.

[Jojobobo]

Yeah, can this really be looked at in some fashion? I appreciate the "fix" might not be so simple as I suggested above. Quite often in solo combat I'll have the fight sewn up, (a Whispers of Treason hit for 12 sec, a figurine out, the relevant defensive buffs like Prayer Against X, Sworn Enemy on a target) and either (a) the Charm effect will go instantly for no reason or (b) the entire encounter will finish and instantly restart, cancelling all my active effects and so making me die pretty sharpish - per encounter abilities do not get refreshed in this process (even if they did I wouldn't want to be using x4 Flames of Devotion anyway because it's cheating, however I would obviously re-use the Sworn Enemy that gets cancelled).

 

I'm currently trying to fight some Cean Gwlas in level 13 of Od Nua, and one of these outcomes is literally happening 4/5 encounters - usually the encounter cancellation and restart. Maybe this is something unique to solo play or my strategy, but it's incredibly frustrating to lose an encounter time and time again through no fault of your own - I've literally been at this single encounter for an hour already. I know this game isn't designed for solo combat, but still encounter mechanics do seem inherently flawed if this is happening so often - solo or not.

Edited August 10, 2016 by Jojobobo

[Sking]

Hey Jojobobo,

 

You will not be able to charm a single enemy in our current system. The charm will end if the character has no targets. There are some instances where charm will end because our AI will not pick up a new target (even when there are some). This is as you stated 'much more prevalent' in solo play. From what I remember when I was investigating this issue that it happens much more with melee enemies. Try saving your charms ranged enemies and you might have more luck. We have an issue for this in our database, but as of now other issues are taking priority. 

 

Sorry buddy,

- Sking

[Jojobobo]

Thanks for the response Sking. For clarity, it's not single enemies I'm talking about - it's enemies in groups. Somehow how they're still not targeting their buddies fast enough and so they're still registering as a single enemy which makes the Charm effect end prematurely.

 

Even then, the encounter ending issue is a rather severe problem - maybe it's not related but it seems similar. Combat will literally just stop and instant restart (and with it those Charm effects, which is why I think the issues have common ground), which as I mentioned doesn't recharge per encounter effects but will cancel effects you have active - this also happens with groups and can be brutal. I do tend to pull enemies to areas where I have better positioning, but even so the majority of the time it's still not far enough for them to want to wander back to their starting position so I'm not really seeing why it would end prematurely. Given that the encounter system is the crux of combat in the game, it being defective semi-frequently in solo play can be pretty problematic.

Edited August 10, 2016 by Jojobobo

[Arranvin]

I'd just like to add that I'm also having this problem. It made beating the bear cave encounter as a solo level 3 cipher a real pain, however I'm more concerned about the potential impact on my trial of iron 'The Ultimate' attempt ranger. I've had a few close calls due to Whisper of Treason ending prematurely when I've used it as a defensive measure on an enemy that has gotten in my face. I understand that there are higher priorities for bug fixing at the moment but I really do hope that this gets fixed eventually.

[Loren Tyr]

Just wanted to bump this a bit. I checked into the code that ends the effect, at the end of the StatusEffect.UpdateHelper function. What is does is simply to check every two seconds whether it has a current target, and if it does not (and is not Confused) the effect is ended. Obviously there are plenty of reasons why the character might not (currently) have a target, other than there not being any at all. The previous target may have expired but no new one selected yet, or there may be enemies in sight but outside the movement range the AI for that character allows. Even if in the latter case the Charmed character would stay put rather than engaging out of range enemies (but visible), that still seems preferable than the Charm effect ending with visible enemies in range. That a character sticks to his "I'm defending this spot, not moving an inch" AI mind set is fine (and makes sense, conceptually), but that shouldn't make him inherently less susceptible to being charmed. 

 

My suggestion would be to add an additional check for enemies in visible range, if there is no current target. At present the relevant bit of code looks as follows (modulo having been run through a disassembler, and slightly formatted for space):

if (aIController != null && aIController.CurrentTarget == null && !aIController.IsConfused) {
  if (this.AfflictionOrigin != null) {
    this.m_targetStats.ClearEffectFromAffliction(this.AfflictionOrigin);
  } else {
    this.ClearEffect(this.m_target);
  }
}

I would think changing it to something like the following would result in much more intuitive Charm/Domination:

if (aIController != null && aIController.CurrentTarget == null && !aIController.IsConfused) {
  List<GameObject> enemies = new List<GameObject>();
  float range = aiController.PerceptionDistance;

  GameUtilities.GetEnemiesInRange(this.m_target, aiController, range, enemies);
  if (enemies.Count == 0) {
    if (this.AfflictionOrigin != null) {
      this.m_targetStats.ClearEffectFromAffliction(this.AfflictionOrigin); 
    } else { 
      this.ClearEffect(this.m_target); 
    }
  }
}

This should result in the character staying Charmed/Dominated if it can still see any enemies; arguably the range could be extended somewhat beyond the PerceptionDistance to have some more margin (the TargetScanners tend to use PerceptionDistance * 2, though that seems a bit much here). 

 

Having this in place should also stop groups of Charmed/Dominated enemies all turning hostile again at the same time if no actually hostile enemies are left (which at present also essentially forces you to try to deliberately miss at least one enemy with any group Charm effect, since if you hit everyone they almost instantly all turn hostile again for lack of viable targets). UpdateHelper calls on the SwapFaction StatusEffects on different Charmed/Dominated enemies in a single update step are (presumably) sequential, so even if the first to be evaluated would find no enemies and turn hostile, the second Charmed/Dominated character would then see that first now hostile enemy and stay Charmed/Dominated (likely selecting it as a Target in the next AI update). 

[Fenixp]

Man...

if (aIController != null && aIController.CurrentTarget == null && !aIController.IsConfused) {
  if (GameUtilities.GetEnemiesInRange(this.m_target, aiController).Count == 0)
    if (this.AfflictionOrigin != null) {
      this.m_targetStats.ClearEffectFromAffliction(this.AfflictionOrigin); 
    } else { 
      this.ClearEffect(this.m_target); 
    }
}

aiController with PerceptionDistance is clearly passed to GetEnemiesInRange, there's no point in storing its value into a local variable and then passing it into the function. There's also no point in creating a new list. And besides, what's up with passing its reference as opposed to returning a new list from GetEnemiesInRange (so that the method can, say, be used directly)? You've suffered too much C in your life, haven't you?

[Loren Tyr]

Right, and C# will just magic up the corresponding GetEnemiesInRange function? Because I'm thinking the compiler will just throw a hissy fit about there being no such function and quit on you. Maybe it's just my old-fashioned C++ mind-set, but I prefer writing code that actually compiles. 

[Fenixp]

(I might have been joking very slightly :-P)
Seriously tho, there actually is a method called "GetEnemiesInRange" which accepts these parameters!? ... I'm just ... going to assume there's a good reason for that.

Edited September 4, 2016 by Fenixp

[Loren Tyr]

It does:

public static void GetEnemiesInRange(GameObject owner, AIController aiController, float range, List<GameObject> enemiesInRange)

Which does look rather weird to me. But that's just because of the whole "objects are really just object references" thing that C# has going on, it's not specific to this function. The function itself is primarily used to populate existing lists (and not necessarily perception distance), so it does make sense to do it this way. Even where a newly created list is passed, it's still to subsequently iterate through the enemy list.

 

There are several instances where just a count is needed, but in those cases that is implemented directly rather than by calling the GetEnemiesInRange function (or its brethren); those tend to check some specific additional condition as well, I suspect there was never much use for a generic 'count' function in the way I'm using it here. So if they do make my suggested change it'd indeed be more efficient to create a 

public static int CountEnemiesInRange(GameObject owner, AIController aiController, float range)

function, just a matter of copy-pasting the GetEnemiesInRange function with some minor changes. 

Edited September 4, 2016 by Loren Tyr

[Fenixp]

Oh wow, Unity is using an ancient version of Mono. That explains so many things...

[Loren Tyr]

Quite possible. I generally just stick to icpc myself :D. Would a newer version of Mono change much about that function signature then? Assuming we'd want the same four (kinds of) input parameters and function behaviour?

[Fenixp]

Can't be arsed to decompile the code, it's quite possible that the side-effect of expanding a list is there for optimization purposes, but I've seen quite a few similar shortcuts written in order to save a bunch of lines of code for a common operation done on a collection, which can be written via LINQ queries in a much more concise and readable manner (which may often be slower of course, but... That argument would be rather moot given stellar optimization we've seen in POE :-P)

 

I might be entirely wrong of course and I'm pulling all of this out of my arse - still, I did work with legacy code a decent bit and have seen similar constructs written for these reasons. Unity 5 seems to be using Mono equivalent of .NET 4.0 which should readily support all of this, but I think earlier versions of 4 used something like ... 2?

[Loren Tyr]

Googling around a bit it isn't exactly clear what Mono version they're using, but I do see quite frequent references to Unity being rather behind the curve in that regard (something with licensing, apparently), so that sounds about right. Anyway, haven't seen any LINQ queries in the code; not sure to what extent those would recognisably survive compilation and disassembly though. 

 

Anyway, I seem to recall that PoE 2 will use Unity 5, so that should be an improvement. Though hopefully they'll also change their general code architecture, keep it a bit more relational. Should help keep the bugs out. 

[Aurelio]

Found this in the Unity 5.5 Beta Release Notes:

 

Upgrade Mono C# compiler (to version Mono Version 4.4) against our current .Net 2.0 and 2.0 Subset profiles. Note that this is an upgrade of the C# compiler only, not the full Mono runtime

[Jojobobo]

As an update, with encounters ending prematurely, I just had to do a hard reboot of my machine because the game crashed (the first time I've ever had to do it with my mac).

 

I was fighting the swamp spores on level 11 of Caed Nua, and when their dominate effects wore off on me it would cancel the encounter more often than not, and then one of the times this happened the screen completely froze and I couldn't do anything to shut Pillars down. Definitely something that needs looking into, hard reboots of my laptop are not something that I'm especially fond of.

[Sking]

Hey,

 

We have not been able to reproduce this issue lately. Our steps seem to be outdated. Can anyone send me step by step on how to cause this issue?

 

- Sking

[Loren Tyr]

Hmm, I seem to be able to trigger the Charm canceling and combat ending quite reliably, for example using this save: https://www.sendspace.com/file/wg860q

I just attack the sailor with my rogue, then stop attacking. Cast Whispers of Treason with the Cipher, and soon after the Charm effect is ended and combat restarts.

 

It actually gets a bit weirder though, see the attached screenshot. After the Charm hits the sailor and before it turns back off again, the sailor is actually attacking himself (in that example I used Shadowing Beyond with my rogue, but that turns out to make no difference for either the Charm and combat ending or the sailor's self-destructive behaviour). Quite possibly this is because the sailor has "auto-attack" in his action cue, and it lacking a valid target somehow substitutes himself for that. Regardless of whatever other fixes are applied, it would probably good to reset the Charmed character's action queue after the SwapFaction effect is applied, to make sure weird stuff like that doesn't happen.

 

However, it also demonstrates that the charm+combat ending is actually a different mechanism than the 'normal' premature charm ending. Because the sailor in this case does have a target (even if it is himself), the Charm effect actually doesn't end prematurely. This is also confirmed by having Eder initiate combat somewhere else on the map, and then attacking and charming this sailor. In this second scenario where Eder remains in sight of (uncharmed) enemies, the sailor remains Charmed for the duration of the spell or until he knifes himself to death, whichever comes first (the death-knifing, as it turns out). So what is happening here (in the first non-Eder scenario) is actually that combat ends first, because there are no hostile enemies in sight of my party anymore. Because combat ends all the combat-only effects end as well, including the Charm effect. This turns the sailor hostile again, restarting combat mode. 

 

Thus, there seem to be three separate issues that need fixing:

A) a charmed enemy potentially attacking himself -> probably fixed by resetting the action queue

B) charmed enemies prematurely becoming uncharmed -> almost certainly fixed by the change I proposed earlier in the thread

C) combat ending when all enemies are charmed (and immediately restarting again once they uncharm as a result) -> a possibility to fix would be 1) to extend the "no hostiles in sight" time interval; in conjunction with the solution for B) that presumably would turn someone hostile again before this runs out; and/or when this time interval expires, first looping through all the non-hostiles in visible range and removing all Charmed/Dominated/Confused effects on them until there is at least one hostile character again (if any).

 

I'll see if I can find a less self-mutilaty NPC to get a good savegame to produce scenario B as well. Should be able to find one. 

[Loren Tyr]

Hmm, getting the scenario for B is actually not as straightforward, because the AI targeting is acting screwy. I moved to a Justiciar as a new candidate, save here: https://www.sendspace.com/file/7u5cig

However, when I attack the Justiciar with my rogue (and stop attacking) and Charm him, he keeps on attacking my party. It's not just auto-attacking either, he is actively switching targets and throwing in Knockdowns. In most cases after being Charmed he knocks down the rogue and comes after the squishy Cipher, though in one case he switched to my Cipher early, and only later decided on a Knockdown for my rogue. However, if the Cipher runs left with the Justiciar and kills one of the NPCs there so the others turn hostile, the Justiciar does get the idea and targets one of the hostiles. However, once all the hostiles are dead he happily switches back to attacking the Cipher, so it doesn't seem like just a matter of having pre-Charm planned actions stuck in his action queue. It still might be and flushing the action queue upon Charm could then resolve it, but if not it might be better to add the "can I see visible enemies" I proposed above for the Charm cancelling and actually removing the "do I have a target" that is there now.  

[Jojobobo]

Hey,

 

We have not been able to reproduce this issue lately. Our steps seem to be outdated. Can anyone send me step by step on how to cause this issue?

 

- Sking

For the dominate effects cast on the player character ending and resetting combat, as I mentioned level 11 of the Endless Paths is pretty good using the three Swamp Spores in the north west corner (clear out the Sporelings and slimes first, then return to them when they're by themselves). These problems seem to happen playing solo more often, so I would recommend it with just the one character.

 

For the character's effects ending prematurely and also potentially ending combat, in addition to Loren Tyr's example, I've found the easiest place to reproduce this is again that same level 11 of the Endless Paths, this time going to the group in the east with the Adragans. I stealthed up to the group, revealed myself, cast Whispers of Treason via Munacra Arret on the most northern of the two Adragans present in PotD and I'd say 9 times out of 10 it will not stay charmed - even with many possible targets around for it to attack. A few of those times combat should also cease and instantly restart (ending all active effects, but not restoring any per encounter uses).

 

This was also playing solo, so again I'd recommend not bringing a party to make it reproducible (it could be that with a party present the bug doesn't occur as often). I'd say the encounter took about 45 minutes due to this bug when it should have taken about 5, so the reproducibility at least for that particular encounter should be high.

Edited September 9, 2016 by Jojobobo

[Sking]

So... it looks like we have a fix for part of this. We fixed the combat resetting when the all enemies are charmed.

 

- Sking

[Jojobobo]

While that is good (and appreciated) a fix for enemies having charm end way prematurely/borderline instantly would be great. I'm at Longwatch Falls currently, and as soon as I get a charm/dominate in on a Broodmother (which is a great thing to do, seeing as Cleansing Flame straight up kills you very fast) the effect ends within a second or two. Loren Tyr obviously mentioned a potential fix, hopefully this would rectify the problem.

 

I am playing solo, and while I appreciate this game was never designed for solo, it's frustrating losing out to quirks in the mechanics rather than errors you yourself are making.

[Mygaffer]

Hey Jojobobo,

 

You will not be able to charm a single enemy in our current system. The charm will end if the character has no targets. There are some instances where charm will end because our AI will not pick up a new target (even when there are some). This is as you stated 'much more prevalent' in solo play. From what I remember when I was investigating this issue that it happens much more with melee enemies. Try saving your charms ranged enemies and you might have more luck. We have an issue for this in our database, but as of now other issues are taking priority. 

 

Sorry buddy,

- Sking

I am on the third floor of the endless paths and fighting the Ogres and Ogre Druids that are found there. I've hit and crit with dominate on both the Ogres and the Ogre Druids, the effect lasts for all of a fraction of a second and then they lose the dominate effect.

 

It's really frustrating in what is proving to be a difficult fight. I'm on the latest patch.

 

Is there a fix incoming for this? Or something going on I'm not catching?

 

Thanks.