RE: Buf Switches / Memory

From: Gary Barnett (
Date: 02/28/97

BTW Pardon my mailer.. it sucks and is going to be replaced as soon as I can find something else
that will handle my rather large store of saved messages.

[buf switching snipped. Beginning of vwear problem snipped]

>My question is this, This command causes an **OVERFLOW** on the more
>common wear positions (as per The paragraph above\ explains it should).
>Is there ANY way that someone could point me to, to hold this large of a
>list? (i am not aware of the approximate size of the list, I have never
>gotten to the bottom of it)

First.. anything is possible.. whether anything is warranted is another story.

Here's my vwear_object.. It's hardly efficient, but it solved the overflow problem
With only a few minutes of coding effort.

void vwear_object(int wearpos, struct char_data * ch)
  int nr, found = 0;
  struct obj_data *obj;
  for (nr = 0; nr <= top_of_objt; nr++) {
    obj = read_object(obj_index[nr].virtual, VIRTUAL);
    if (CAN_WEAR(obj, wearpos)) {
       sprintf(buf, "%3d. [%5d] %s\r\n", ++found,
       obj_index[nr].virtual, obj_proto[nr].short_description);
       send_to_char(buf, ch);

This will take care of the problem.. but it will send a line for every
match instead of one big line at the end. Completely solves the
overflow problem.. but will still kick you off if your link isn't so
hot :)

Incidentally I have created a command called VAFFECT that reports the
affects an object can bestow. I'd post it, but as the names of all the stats
and most of the affects have been changed from stock it'd be more trouble
to change than to create a new one.. It is a good one for the idea mill though.
Handy to find all those -100 AC and +10 strength items your less than perfect
builders make :)


| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |
|    Or send 'info circle' to     |

This archive was generated by hypermail 2b30 : 12/18/00 PST