>> I'm currently running into a small snag with a routine I'm working on >> that does the classic: >> a short sword lies here (3) i've been thinking on this one myself. >> My current plan of attack is traverse the eq list in a room (via the >> CAN_SEE_OBJ macro and obj->next_content), put the item numbers the player can >> see into an array, count up the similar vnums, then send the output to the char. this would be slightly time consuming i would think. obviously the quicker things are done the better, especially when your average number of players increase. >> The problem is the "count up the similar vnums" part of this algorithim. >> I'm sort of stumped on how I should do this in a semi-elegant way. wel, in answer to this one.. copy the room object list to a temp list. take the first obj, and search thru the list for the same rnum removing them from the list as you find them, and at the end print out the desc and number counted (this will be slightly different if you have 'equipment states' (ie. eq can be damaged and destroyed.. eg. "small sword [bad]"). keep doing this with the vnum of the object at the top of the list (remember this changes because we remove this object each time thru the list), until the list is NULL (ie. empty). >> Or, worse yet, is the approach I'm taking a poor one, and is there a better way? highly possible i would say :) > I did something else which I think might be more efficient. First of all I > changed all the obj_to_char, obj_to_obj and obj_to_room stuff to insert into > the linked list, sorted by rnum (i used rnum but vnum is better i guess). > Then when I list objects to character, I go through the list comparing > adjacent elements. This way it's easier to count and you don't need another > array. this is the way i would be inclined to do it, but this might slow things down if you have people with clients doing MEGA multiple drops of coins. (you could always prevent people dropping coins, or prevent people doing more than 10 repetitions of a command (this one can be annoying for players at times, but its not hard to get around either). > This way screws up the way people drop objects (instead of having newly > dropped objects appearing first in the equipment list, they might show > up later) but I didn't really mind that much. this easy enough to get around.. simply move that section of the item list (ie. the section of 'like rnums' of the dropped object) to the beginning of the object list. a snippet of the top of my head for this last bit. in the obj_to_room/inv/container etc. ... (after you have inserted it into the list, and assuming the new object gets put at the head of the section of like vnums, and assuming you maintain a pointer to 'previous obj in list' while searching for a like rnum. (so you can know what object points to the new object)). (oh, and i dont think the structure member next_contain is the actual name, or obj_list for that matter). struct obj_data *i, *last, *previous; for (i=obj,last=obj; i->vnum != obj->vnum; i=i->next_contain) last = last->next_contain; previous->next_contain = last->next_contain; last->next_contain = world[IN_ROOM(ch)].obj_list; world[IN_ROOM(ch)].obj_list = obj; i think this is pretty much ok, but its hard to do it without having any code in front of you. *shrug* just ideas for the questions posed. nothing i've actually implemented, but now that i've thought about it a bit more, i think i will do it this latter way, unless someone has a better idea in the meantime :) Ted @ who am i really? i dont know either!!
This archive was generated by hypermail 2b30 : 12/18/00 PST