----- Original Message -----
From: "Mark Jeter" <mjeter@EARTHLINK.NET>
> 1) I intend to make it so players have short descriptions (ie. the
> blue-haired, green-eyed man).
This has been discussed on the list earlier. This link will give you a list
of interesting mails concerning what you're after (an 'introduction system')
http://post.queensu.ca/cgi-bin/listserv/wa?S2=circle&q=introduction+and+system&s=&f=&a=&b=
> 2) I'm trying to have a command that can target another player OR mob and
> basically lock
> it into memory for that player. Then later on when someone tries to shoot
> they will automatically
> aim for their target. This of course will allow for other skills to be
> used in conjunction with targetting.
> My big problem is I do not know if every creature has their own separate id
> number for the game
> to check when using these skills, and I was wondering if any knew if there
> was?
As far as I know, there isn't any 'id', as such, in stock Circle. However,
if all you are after is the possibility to target a specific mob/player,
how about adding a
struct char_data *target; /* Current target */
into char_special_data, and make a macro in utils.h:
#define TARGET(ch) ((ch)->char_specials.target)
This way you can set a chars current target with
TARGET(ch) = vict;
assuming you've validated vict to be a mob/player currently
playing. hmmm... come to think of it.. this would need some method of
removal (Nulling), once the target is extracted. Maybe, just as fighting
chars are added to a list, add 'targetting' as well as 'targetted' to a
linked list to be checked upon extraction.
Main advantages of this plan:
1.You won't have to check a long list of people every battleround, simply
check if FIGHTING(ch)==TARGET(ch). (relatively fast)
2.easily addable - nothing needs to be saved, since you're only targetting
playing chars and mobs. (this way you won't break the pfile)
Main disadvantages:
1. You can only target playing players and mobs.
2. quite a lot of coding is necessary to make it work in every case.
Another way would be to assign every mob a unique ID number:
in struct mob_special_data add:
long id; /* id of mob */
in utils.h redefine GET_IDNUM(ch) to
#define GET_IDNUM(ch) (IS_NPC(ch) ? ((mob)->mob_specials.id) \
((ch)->char_specials.saved.idnum))
And have all mobs loaded set a new id number, starting from for instance
50000 and upwards. This mimicks the way DG_scripts seperates two mobs.
A change would be needed in db.[ch] and read_mobile():
in db.h
#define FIRST_MOB_ID 50000 /* arbitrary number - when we have 49999 players
we better raise this */
at the top of db.c - where all the other global vars are declared:
long top_mob_id = FIRST_MOB_ID;
and in read_mobile():
GET_IDNUM(mob) = top_mob_id++;
make a function to set TARGET(ch) (should now be one of those long spares.)
to GET_ID(vict) if vict is an npc, and GET_IDNUM(vict) if vict is a player.
In char_to_store(), reset TARGET(ch) to 0 if it's greater than FIRST_MOB_ID,
since all mobs will have new id's after next bootup.
Benefits of this model:
1. easy to code - only few things need to be changed.
2. Targetted players save with the player.
Disadvantages:
1. code using (GET_IDNUM(ch)==-1) to check if ch is an NPC won't work anymore.
(currently only used once in ban.c - and in this case it'll still work)
I hope this helps.
Welcor
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST