On Thu, 26 Oct 1995, Billy H. Chan (~{3B:FH;~}) wrote:
> > From: Donald Louis Karpovich <dlk2@Ra.MsState.Edu>
> >
> >
> > hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
> > if (FIGHTING(ch) == NULL || ch->in_room != FIGHTING(ch)->in_room) {
> > stop_fighting(ch);
> > continue;
> > } else if (!IS_NPC(ch)) {
> > percent = number(1, 101); /* 101% is complete failure */
> > if (percent < GET_SKILL(ch, SKILL_SECOND_ATTACK))
> > hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
> > } else if (IS_NPC(ch) && GET_MOB_ATT(ch) > 1) {
> > for (j = 2; j < (GET_MOB_ATT(ch) + 1); j++)
> > hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
> > }
> > if (MOB_FLAGGED(ch, MOB_SPEC) && mob_index[GET_MOB_RNUM(ch)].func !=
> > NULL)
> > (mob_index[GET_MOB_RNUM(ch)].func) (ch, ch, 0, "");
> > }
> > }
> >
>
> It doesn't seem like you're checking for the validity of the victim
> during your for loops, which would cause major unhappiness for the
> mud when it tries to attack a corpse or things of such ilk.
Well, that's probably the cause of the seg fault :-)
> As for the logic... I reindented your code for my own reading (if
> you haven't noticed you do something very very weird in that for
> loop... you start the index at 2, and you go up to GET_MOB_ATT(ch) +1.
> Of course, you could do a j <= GET_MOB_ATT(ch) and save a +1... or,
> if you like J < GET_MOB_ATT(ch), you could just start at 1... hope
> you don't mind my nitpicking (I wish someone would nitpick my code for
> me :)...
I did that to ensure that the mobs didn't get too many attacks. Since hit()
is called at the top of the block, only number of attacks greater than one
will cause the loop to execute. For example, if I set num_attacks to 6, the
first hit() would be called, and the rest (2-6) would be called as a result
of the for loop. Of course, I guess I just find it easier to visualize that
way, your methods work too.
> As for why mobs are doing strange things, I didn't understand which
> part of the mob you stuck the new variable in... for reference, I stuck
> it in where the BareHandAttack variable is saved... puff getting 9
> attacks while hydra getting 1 seems like some ssort of 'global' variable
> is being "looked at", which may be the cause...
I added a field to the E type mobile (just like you did) to add extra
attacks. This way I wouldn't have to rewrite all of the mob files.
> are you sure you wouldn't
> just like a cut/paste ? :) (btw, you may find it in demand for a third
> attack, esp if mobs are gonna be doing more than 2 :).
> Anyway, there should be a check before the first hit(ch, FIGHTING(ch)...)
> and you need that directly before any calls to hit(...), else your code
> may not be fully portable (linux I think pukes on a call to hit a corpse).
> YMMV.
Actually, I'm not entirely against a cut & paste solution, but I am trying
to teach myself how to program, and simply copying everyone else's code
seems to defeat the purpose.
By the way, I did rewrite the relevant code (based on what Glenn Campbell
posted) to look like this:
do {
if (FIGHTING(ch) == NULL || ch->in_room != FIGHTING(ch)->in_room) {
stop_fighting(ch);
continue;
} else
hit(ch, FIGHTING(ch), TYPE_UNDEFINED);
counter--;
} while (counter > 0);
The same problem...either puff gets 9 attacks and the hydra gets one, or the
hydra and his mob opponent only get one attack. If a player attacks it, they
still get their skill-based second attack.
I'd like to keep the multi-attack option as part of the definition of an
extended mob, otherwise, I am completely agreeable to looking at someone
else's code to learn from.
Thanks...
> -Billy H. Chan
> <bhchan@csua.berkeley.edu>
****************************************************************************
Donald Karpovich * I am myself alone
**************************** Realise I never need to use No-one
dlk2@ra.msstate.edu * Money, Power, Holy Roads,
74547.2546@compuserve.com * Freedom puts my faith in None of the above
**************************** -Duran Duran (1993)
*************************************************
This archive was generated by hypermail 2b30 : 12/07/00 PST