Hi,
On Fri, 12 Jul 1996, Ryan A.J. Biggs wrote:
> rarely will I have a mob that has a spec_proc that calls a spell
> directly, more than likely, the mob will cast the spell (just like a
> player) and have a chance to fail or succeed) just like a player. This
So the mob would call do_cast (in some way, via command_interpreter or so)???
If yes, here's an interesting problem.... (ran across it with my mobprog
implementation)
First this is not 100% stock code, so beware... do_cast won't allow npc's to
cast in stock. In my version this check is removed. Now the following problem
arises:
In spell_parser.c in the do_cast function the "wait state" of the player/mob
is increased. For a player this is done in the players descriptor_data struct
(desc->wait) for a player this one is decreased every pulse. (WAIT_STATE
macro) For a npc this is done in mob_specials.wait_state (WAIT_STATE then
GET_MOB_WAIT macro) this one is only decreased while the mob is fighting.
Well you made one beautiful healer mob it would cast a heal and not cast
anything else after that because the wait_state wouldn't get decreased
(until someone attacked the mob).
I'm thinking of the following solution (in "the general idea" style):
Use a sorted list with wake_up_time's the following funcs would be used:
add_wait_state( struct char_data *ch, int wait )
this would add the wake_up_time (pulse + wait) for the ch (mob/pc) to the
list (keeping it sorted eg the nearest wake_up_time first).
then in comm.c in game_loop:
/* process commands we just read from process_input */
for (d = descriptor_list; d; d = next_d)
{
next_d = d->next;
if ( (--(d->wait) <= 0) && get_from_q(&d->input, comm, &aliased))
^^^^^^^^^^^^^^^^^^ -> changes to d->wait == 0 (or something
in that line, just see if player has
to wait)
Then in front of this for loop a piece of code that does the following:
check the wake_up_time in the top of the wake_up list has it expired?
remove it from list and set it to zero. And keep doing that until no more
expired wake-ups are found. (thus player and mob wait_states are done
here)
In fight.c in perform_violence some checks/processings for wait_state's would
have to be changed too.
Like this players and mobs would be treated in the same way for their
wait_states. Thus allowing mob's more playerlike behaviour, which is more
fun IMHO (I was making a mobprogram for a healer when I ran across this,
this mob would do very unpleasant things to anyone who attacked it...
(just like a player would.. at least I would :) When the healer killed
the attacker it would cast animate dead on the corpse of the player and
send the zombie (including all the equip of the perpetrator) off to hunt
some poor and innocent mob in the neighbourhood thus leaving a
interesting and exciting quest for the player in question (great feature
this think I'm gonna call it autoquest(tm) :) Well enough spam to this.
Any opinions/divine insights/etc. ????
GrimReaper of Realms of Frustration
-----+++++*****************************************************+++++++++-------
- Ric Klaren - j.klaren@student.utwente.nl - ia_ric@cs.utwente.nl -------------
-----+++++*****************************************************+++++++++-------
``Why don't we just invite them to dinner and massacre them all when
they're drunk?''
``You heard the man. There's seven hundred thousand of them.''
``Ah? So it'd have to be something simple with pasta, then.''
-------------------------------------------------------------------------------
From: Interesting Times by Terry Pratchet
-----+++++*****************************************************+++++++++-------
This archive was generated by hypermail 2b30 : 12/07/00 PST