<snip>
After adding mobprogs, some people find that when switched into a mob
they
don't see a lot of the mud text, most notably communications channels.
The
cause of this is the code added to the 'act' function, to check for an
ACT
trigger on a mob. The code returns from the function if the mob doesn't
have
such a trigger, but doesn't take account for a switched imm. Add a
clause to
the 'if' check to return only if the mob has no descriptor and this
problem
should go away.
....

No offense to the author, as the faq has helped me greatly in the past,
but
this little section I find little help at all because of how vague it
is.
1) I cant seem to find the ACT function, I only have an act_new
function. 2)
it sais "..the code returns from the function if.." and then it tells
you to
change "the if check".  Which function is it refering to? act_new? or
each
individual communication function, such as say, yell, tell, immtalk,
etc.
and which "if" is "the" if check to change in "the" function?

Can someone maybe offer a bit more specifics so I might be able to come
closer to figuring this one out?  maybe give an example of a fixed if
check?

Or, do you need more information to help me out with this problem?
</snip>

First off, act_new is the ACT function they are talking about.  That
said, after adding Newt's mobprogs, there should be an if check towards
the bottom something like this:

if ( to->desc != NULL )
  write_to_buffer( to->desc, buffer, 0);
else {
  if ( MOBtrigger ) {
    p_act_trigger( buf, to, NULL, NULL, ch, arg1, arg2, TRIG_ACT);
  }
}

The if is essentially asking if who is getting sent the message is a
player or not (by seeing if the char_data is associated with a
descriptor).  If not, it just goes and checks for an act trigger, and
ignores the message.  I don't have a fix for it at this point, and don't
have time to whip something up quick (read as: I'm in the middle of a
lot of changes, and the code is not compile-able ;).

I don't know off the top of my what type of things to look for to see
that an imm is switched, but what I would suggest is figure that out,
and put another if check in there, and write_to_buffer if the check is
valid.  Something like:

if ( to->desc != NULL )
  write_to_buffer( to->desc, buffer, 0);
else {
  if ( MOBtrigger ) {
    p_act_trigger( buf, to, NULL, NULL, ch, arg1, arg2, TRIG_ACT);
>>if (whatever_you_have_to_check_to_see_if_it_is_a_switched_imm)
>>  write_to_descriptor(blahblahblah);
  }
}

Something like that should work.


Next...

<snip>
**Notice the comment? I don't remember putting that in there so I think
it
was there from the beginning.  continueing on my feeble attempt to fix,
I
realize that the only way "prog" is being set to null in Fix_mobprogs is
if
the prg = mprog_list; statement just isn't working.
</snip>

First, I don't have that comment in mine.  Second, from looking at
mobprog itself, it looks like it is formatted correctly, so I don't
think that is it.  My guess is in the actual reading in of the MOBPROGs
themselves.  Fix_mobprogs(void) is pretty much associating the mobprogs
to the mobs after both have been loaded.  I also think that you are
right that the problem is arising in the get_prog_index function.
Pretty much the mob says I need mobprog with vnum 3700, but when, in
get_prog_index, the mprog_list is being searched for a prog of vnum
3700, there isn't any, so it is returning a null.  Long story short, I
think you need to check that mobprogs are even being read in in the
first place.  Obviously, I could be wrong, but that is where I would
start.

Coy.


Reply via email to