>...If you give them a command buffer (like PC's)...
I don't know if putting a command buffer as mentioned on mobs is the best
solution for a stock
ROM setup. If you did that, you would have to poll all mobs every pulse in
addition to
descriptors (wait is only decremented in comm.c by polling descriptors). That
would be dumb, as
99.999% of the mobs in the game wouldn't have a wait, and you'd have to loop
through 16,000
objects instead of 50 or so. (Admittedly, with an event system, this wouldn't
be a problem.)
Also, you would have to modify read_from_buffer or alternatively make a new
one, which would be
'teh suck'.
>..give them a wait_state also...
Mobs actually already have a wait state, it's just never set.
Solution one (duh solution): Set your own wait to the ordered command (but I
have a hunch this
is not the solution you are looking for);
Solution two, a more hackish yet still easy solution, would be to add a few
things to your own
PC data structure:
ch->pcdata->charm_wait;
ch->pcdata->charm_cmds; where:
struct pc_data
{
...
sh_int charm_wait;
char *charm_cmds;
...
}
And whenever you do an 'order', it essentially just appends 'order mobX
whatever' to the end of
charm_cmds much like how a command buffer works. Instead of comm.c polling
16,000 objects
(mobs+descriptors), it'll poll just the descriptors and, if
*d->character->pcdata->charm_cmds,
it'll strip off a command and execute it (checking to see if your charmie is
alive and whatnot,
of course). Uh, actually, couple different ways of having ROM execute the
command; appending
just what you've written is more of an event thing. Work it out accordingly,
I'm too lazy to
offer alternatives :)
The above comes at a caveat, however, as you can only have one charmie here,
but this can be
worked around by arranging these elements into a linked list of your charmies
(solution 3):
struct pc_data
{
...
CHAR_DATA *charmies;
...
}
And modify char_data a bit:
struct char_data
{
...
char *charm_cmds;
...
}
Now, when descriptors are polled, you'd add something like (comm.c):
/*
* Process input.
*/
for (d = descriptor_list; d != NULL; d = d_next)
{
...
if (d->character != NULL && d->character->wait > 0)
{
--d->character->wait;
continue;
}
/*added code below*/
{
CHAR_DATA *charmies, *charmies_next;
for (charmies = d->character->pcdata->charmies, charmies;
charmies =
charmies_next)
{
charmies_next = charmies->next;
if !(IS_AFFECTED(charmie, AFF_CHARM))
{
charmie_remove(d->character, charmie);
continue;
}
if (!(*charmie->charm_cmds) || --charmie->wait > 0)
continue;
if (*charmie->charm_cmds)
{
/*Here there'd be a function call that
/*strips off a charm command and re-sets the
/*charmie's wait.
}
}
}
Solution 3 is, in my opinion, fairly efficient. One small thing to look at
would be some
potential oddness involving charmed PCs, though I'm not sure.
-- Jeremy Hill
----- Original Message -----
From: "Dale Kingston" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 13, 2003 5:22 PM
Subject: Re: Charmed Monsters and Interpert
> But keep in mind, if you give your mobs a command buffer. You are going to
> use a little bit more memory. Which isn't a problem, but I try to be
> concervative with memory. A bare pointer may only take 4 bytes. But multiply
> that by 1000 mobs, and that 4 bytes isn't so small.
>
> ----- Original Message -----
> From: "Chad Simmons" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Monday, October 13, 2003 12:45 PM
> Subject: Re: Charmed Monsters and Interpert
>
>
> >
> > --- [EMAIL PROTECTED] wrote:
> > > Hello,
> > > I was wondering if anyone knew how to make it so that interp for the
> order
> > >
> > > command would be affected by the delay state of the monster so that the
> > > monster
> > > couldn't be given commands that could be used in combat to gain an
> advantage.
> > >
> > > Such as, kicking infinitly. I am not sure how to do this as monsters
> don't
> > > seem
> > > to be affected by a wait state.
> > > Any thoughts, ideas?
> >
> > The problem is that mobs don't have a command buffer, everything they do
> is
> > executed immedietly. My suggestion would be to reorganize the way NPC's
> are
> > treated in the game. If you give them a command buffer (like PC's) you can
> give
> > them a wait_state also, and this will keep you from having to program in
> > special logic for mobs into all your commands, etc.
> >
> > ~Kender
> >
> > =====
> > -----BEGIN GEEK CODE BLOCK-----
> > Version 3.1
> > GCS/L/C/O d-(+) s++: a-- C+++$>++++ UBLS++++$
> > P+++(--)$ L+++>++++ E--- W+>++$ N !o K? w(--) !O
> > M- !V PS+ PE(++) Y+ PGP->+ t+ 5 X+() R(+) tv+@
> > b++(+++) !DI+++ D G(-) e>+++$ h---() r+++ y+++
> > ------END GEEK CODE BLOCK------
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >
> > --
> > ROM mailing list
> > [email protected]
> > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
>
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
