Magically killed monsters still around.

[GoogleCodeExporter]

oes killed with fireball or other magic spells don't show up as crossbones
icons and disappear from the field.  they are invisible until you walk past
or into them. if they are directly in your path, you will attack them and
then they will show crossbones and disappear.  If you go past them, dead
and dying foes will attack you as if they were alive and sometimes hit. 
they can be taken off the board with non-magical missiles too.

Original issue reported on code.google.com by simeon.pilgrim on 27 Aug 2009 at 10:25

[GoogleCodeExporter]

I experienced that they 
- block movement of teammates (monsters walk around invisible dying guys)
- can be made visible by aiming manually
- may even try to flee (or at least I had that feeling)
- make attacks of opportunity.

In case of attacks of opportunity I think problem lies here:

ovr014.cs, line 363:
                                    if (attacker.actions.delay > 0 ||
                                        attacker.actions.field_F == 0 ||
                                        ovr032.CanSeeCombatant(var_1B % 8,
ovr033.PlayerMapPos(player), ovr033.PlayerMapPos(attacker)) == true)


actions.field_F is related to backstabbing. Actually, it is the number of times 
the
attacker has been target for a physical (melee?) attack. Hence, it can be 
called like
attacks_received.

It does make sense to check it here, since those that cannot turn possibly 
cannot
make attacks of opportunity against those they cannot see, but magical attacks 
do not
increase this count, so the disjunctive condition is fulfilled (unless it 
received an
attack earlier that round).

Fixing this would only be a partial workaround though.

Original comment by surrano on 18 Sep 2009 at 7:00

[GoogleCodeExporter]

The difference between phys and magic attacks is:

ovr014.DisplayAttackMessage:
            if (target.in_combat == false)
            {
                ...
                ovr024.RemoveCombatAffects(target);

                ovr024.CheckAffectsEffect(target, CheckType.Death);

                if (target.in_combat == false)
                {
                    ovr033.CombatantKilled(target);
                }
                else
                {
                    seg041.GameDelay();
                }
            }

ovr024.damage_person:
                if (player.in_combat == false)
                {
                    ...
                    if (gbl.game_state == GameState.Combat)
                    {
                        seg041.GameDelay();
                    }
                    else
                    {
                        RemoveCombatAffects(player);

                        CheckAffectsEffect(player, CheckType.Death);

                        if (player.in_combat == false)
                        {
                            ovr033.CombatantKilled(player);
                        }
                        else
                        {
                            seg041.GameDelay();
                        }
                    }
                }


Changing the GameState check to notequal:

                    if (gbl.game_state != GameState.Combat)

fixes the problem, but I don't know whether it introduces some side effects 
during
adventuring. I think no; it should be the original way. Could you please 
cross-check
in asm code.

Another question: may in_combat change to TRUE, once changed to FALSE? Esp. 
within
RemoveCombatAffects or CheckAffectsEffect? If no then the internal if check is
unnecessary and the GameDelay will never be called. Just a thought... maybe 
there is
some hacking around, e.g. in case of Boars, Trolls, etc... whoever gets up after
having been downed.

Original comment by surrano on 18 Sep 2009 at 7:15

[GoogleCodeExporter]

Wow, such a simple fix, and I'd not followed it up, thanks for finding the 
cause of
the issue. 

I've not tested it, but you correct the I had the test flipped, so I'll believe 
your
testing.

Your also correct that CheckAffectsEffect(player, CheckType.Death) does the 
death
check for trolls. Now I'm sure that method doesn't do the revive logic, but it
doesn't seem to do any harm leaving the code there for now. 

Original comment by simeon.pilgrim on 5 May 2010 at 5:23

• Changed state: Fixed