Gammon Forum : SMAUG : SMAUG coding : New item types

Entire forum ➜ SMAUG ➜ SMAUG coding ➜ New item types

New item types

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by Isthiriel (113 posts) Bio

Date Reply #15 on Sat 18 Aug 2007 08:42 PM (UTC)

Message

Ok, an explanation on the uses (and abuses) of UNLINK.

SMAUG stores most objects (in the computer science sense... a struct in C) in doubly-linked lists.

A linked list is the name given to a bunch of objects where the first object has a pointer to the next, which in turn has a pointer to the next where no object in the list has a pointer to an earlier object in the list (this is important to avoid an infinite loop when attempting to traverse the list).

SMAUG's doubly-linked lists gives each object a pointer to the previous object (that is the object that points to the current object with its 'next' pointer). So it can be traversed either by following the next pointers forward, or the prev pointers backward.

Singly-linked lists are fairly easy to handle. If you want to do an insertion, you set the next pointer on the new object to the current list-head and the new object is the new head of the list.

Doubly-linked lists because you have to update three objects and four pointers (and you're usually trying to keep the number of temporary variables down) are more complicated, so the UNLINK and LINK macros are born.

LINK inserts the new object into a list specified by a head and a tail pointer.

For an empty list, new->next = NULL, new->prev = NULL, head = new, tail = new. Easy.
For a list containing item(s), we can do head- or tail- insertion, new->next = head, head->prev = new, head = new, new->prev = NULL.

So far, so good.

UNLINK has to find the object its handed in the list and then remove it from the list and repair all the references.

For an empty list, no work.
For a list containing the one item (to be removed), del->next = NULL, del->prev = NULL, head = NULL, tail = NULL.
For a list containing the item as the head, head = del->next, head->prev = NULL, del->next = NULL, del->prev = NULL.
(Ditto, but backwards for item-as-tail.)
For a list containing the item in the middle, del->prev->next = del->next, del->next->prev = del->prev, del->prev = NULL, del->next = NULL.

Taking this back to your code, the iteration follows the paf->next pointer to get the next affect in the list BUT you are calling UNLINK/LINK which both change what paf->next is actually pointing to. This is what I was trying to get across with my earlier post.

If your goal is to remove the affect from the gem and add it to the sword, then you should be able to use your code provided you cache the value of paf->next for the iteration.

IIRC, pIndexData is the prototype information? So you shouldn't be modifying (UNLINKing) it for a change to an instance. Personally, I'd destroy the gem once it has transferred its affects to the weapon. Though, that way you have to duplicate the affect from the gem pIndexData before applying it to the weapon.

Something like:


/*
 * gem_ob is the pointer to the gem object (sane variable names ftw!)
 * socketed_ob is the pointer to the socketed object receiving affects
 */
  separate_obj(gem_ob);
  for (paf = gem_ob->pIndexData->first_affect; paf; paf = paf->next) {
    /* paf is now iterating across the affects on the gem prototype, we want to copy this affect and apply it to socketed_ob */
/* Taken from SMAUG 1.8b mud.h: (tells us what we need to copy)
struct	affect_data
{
    AFFECT_DATA *	next;
    AFFECT_DATA *	prev;
    sh_int		type;
    int			duration;
    sh_int		location;
    int			modifier;
    EXT_BV		bitvector;
};
*/
    CREATE(new_paf, AFFECT_DATA, 1);
    new_paf->type = paf->type;
    new_paf->duration = paf->duration;
    new_paf->location = paf->location;
    new_paf->modifier = paf->modifier;
    xCLEAR_BITS(new_paf->bitvector);
    xSET_BITS(new_paf->bitvector, paf->bitvector);
    /* new_paf should now be a good copy of paf, so we can add it to the socketed_ob */
    LINK(new_paf, socketed_ob->first_affect, socketed_ob->last_affect, next, prev);
  }
  extract_obj(gem_ob); /* this destroys the gem? */