Here goes.. sorry for the long, long response.. but i thought i might as well explain the deal so you understand code a little more :) And sorry if you already understand it all, but hey.. just in case 8^) > Well, I actually have the item working in that sense. Basically, via a > coupla static ints, I've saved the last time it was used, check vs. time > now, and if enough time has passed, set powered_up = TRUE. My problem is, > that every copy of this sword in the game follows the leader. > Say every sword in game is powered_up = FALSE. One guy powers his up, > they all power up. there is an easy explanation to this. A static variable maintains is value after the function is complete. This means that the next time the function is called, the variable has the value it had at completion of the previous function access. So.. if 5 items have the same special procedure.. ..mud's main loop runs and comes to the section where all special_procs on items are run/checked.... ..item 1 accesses our power spec_fun. (start of first time): powered_up is not declared yet. this is the first time we have entered this function, and so powered_up is allocated memory space and set to False. and so we power up our sword if its wield sets powered_up to True; (after first time through): powered_up = True; ..other items go through their respective spec_procs .. item 2 accesses our power function second time into the function, hence powered_up has already been declared and allocated memory, and since its static it also retains its value... (start of second time): powered_up = True powered_up is true. so you check the day (i assume you keep a static variable also keeping track of the day it was used). (the lines below are only likely to kick in later on, not the second time through the function). if the day is greater than last used you set powered_up to False, power up the sword if its wielded and set powered_up to True (end of the second time): powered_up = True ..item 3 same as item 2. etc... and since item 1 is always checked for special procedures before item 2, 3.... (because its in the object list before them), then it will always be the one to activate the power. > Okay, so I decided to check ownership. I did an along the lines of... > obj->value[0] = atoi(&ch->player.name), ... > And that led to the problem. When I change obj->value[0] (not 3, my > mistake), it changes it on every copy! not really a good thing to do.. a name is not going to be able to be converted to an integer, and hence 0 will always be returned > and placed it to be executed only upon cmd equaling CMD_WIELD. > My logic was, that you first "claim" ownership of this item, and > thereafter, any thing that is done, first checks whose weapon we are > talking about. > So, obviously, the proc is not treating the item as unique, that's right.. no matter how many items access a special procedure they ALL access the SAME code.. its not as if the special procedure is 'created and assigned unique values' for each item that calls it. > but altering > the prototype of such. I suppose, if I delve into a few of the spells that > alter items, I'll see why I'm not altering a single version of the item, > but most likely that will simply lead to another headache. And then again, > procs are treated a bit differently than other functions.... i would suggest.... in one of the spare values[] nodes.. maintain the day last used. and than all you have in the power() special is a check for the last date used with the current date. if the date is less then power it up set the last used tocurrent date. else do nothing this way you dont need to store whether it was powered up or not b/c than can be determined by date comparisons, each item will have its own last_date used, so it can be item specific too. - Greg
This archive was generated by hypermail 2b30 : 12/07/00 PST