> From: Pink Floyd <floyd@south.mit.edu> > > [On disarm losing the equip] > try this: > > struct obj_data *tmp; [/* generally informative comments snipped */] > tmp = unequip_char(vict, WEAR_WIELD); > obj_to_room(tmp, vict->in_room); > Actually, you can save a temp pointer by combining the two statements into: obj_to_room(unequip_char(vict, WEAR_WIELD), vict->in_room); Ya, I know that ;-)... but I figured it was probably more instructive to tell whoever it was (you? can't remember) what was going on. They clearly didn't realize that unequip_char returns a pointer, and I don't think that your method, though more efficient and the way I would have done it, really makes that clear. That being said, ... Does anyone know where an object that is not obj_to_room'ed go? I fixed my bug, but I'm interested in finding out what could've happened (did equip appear out of no where in some strange place in my mud, or did it cause some memory leakage...) The object still exists (i.e., that particular instantiation of the prototype is still in the game, and takes up memory), but now there might be no way of referring to it! Unless there is a global linked list of all the objects in the world, which I don't recall encountering, then failing to pick up the pointer from unequip_char could forever lose that object - a memory leak! What I don't understand is why a) the person's compiler didn't flip out at the original statement, which was blatantly inconsistent with the prototype for unequip_char(), or b) they chose to ignore the message and wondered how their routine could possibly be messing up! Just a reminder to you coders, its a good idea to keep the -Wall flag on gcc.
This archive was generated by hypermail 2b30 : 12/07/00 PST