[CF-Devel] Charm monster exploit

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      Hello.
     
     >
     
     
     >
     
      Charm monster *always* works.
     
     >
     
      It seems monsters just get charmed, whatever their level.
     
     >
     
      I was level 10 and could charm Ancient Red Dragons, or dragonmen lol.
     
     >
     
     
     >
     
      Looking in the code, in spell_attack.c:mood_change (i think that's what 
     
     >
     
      is called?), there's a
     
     >
     
     
     >
     
              if (did_make_save(head, head->level, at)) continue;
     
     >
     
     
     >
     
      but i think values aren't really correctly made.
     
     >
     
     
     >
     
      I don't know the best way to fix, so i'm asking others :)
     
     >
     
      I'd see something like singing for the chance to calm down, based on 
     
     >
     
      respective levels.
     
     
  Well, for more context, the code is actually:

             if (best_at == -1) at=0;
             else {
                 if (head->resist[best_at] == 100) continue;
                 else at = head->resist[best_at] / 5;
             }
             at -= level / 5;
             if (did_make_save(head, head->level, at)) continue;

  (best_at is the attacktype against the spell in question that the monster has 
the best saving throw against)

  I don't see any fault in those calculations.

  Now it seems that charm doesn't have an actual attacktype, so in that case, 
the monster isn't getting any advantage based on resistances they have.

  Now at level 10, you should be imposing a -2 or so penalty on the creature, 
which isn't that big a deal.

  at monster level 10 or so, it appears the base save they need is around 11 or 
12, and it goes down 1 point about every 5 levels or so.  So it would seem that 
it more or less is doing a level comparison there.

  I'd think it may be necessary to add some debug statement above the 
did_make_save() line and see what values are getting passed in.  I will note 
that many monstes may not have appropriate level values set for themselves, and 
thus are easier targets.


  However, one thing I notice is how the code resolves the head, eg:

             /* Only the head has meaningful data, so resolve to that */
             if (tmp->head) head=tmp->head;
             else head=tmp;


  The problem here is that it finds each monster, or part thereof, within range 
of the caster.

  The effect of this is that say a 2x2 monster is completely within the range - 
that monster now needs to make _4_ saving throws against the charm effect. 
Larger monsters would have to make even more.  If the monster normally has a 75% 
chance to make it, but has 4 parts, its overall chance is then reduced to 31%.

  What probably needs to be done is some work to make it so that such large 
monsters only need to make a single saving throw.

  I'm not sure the best way to do this.  One thought is that since all multipart 
objects are rectangular, and the area of effect of the charm and that block of 
code is always square, then you know that if a piece of the monster if affected, 
then either the head or tail of the monster must be in the area of effect.

  Thus, in the code itself, you could have some logic like:

  if (head->more && !head->head) {
	this is the head object - see if the tail is in the area of effect (since we 
have the tail_x and tail_y, this is easy to do).  If not, continue to process 
this object - if so, don't process as block below takes care of this.
}
  else if (head->head && !head->more) {
This is the tail object - always process because the block above won't process 
if this block will.

} else if (head->head && head->more) {
	this is a middle part of the creature - just continue because one of those two 
blocks above will properly deal with this
}


  Now for some effects, like fireball, or other area of effect spells, it 
perhaps makes sense that large monsters are more vulnerable simply because more 
of them are in the effect.  But that logic doesn't really hold true for charm 
and the like.

_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel