H. S. Teoh wrote: > On Mon, Nov 17, 2003 at 11:40:39PM -0800, Mark Wedel wrote: >> Check to see if tmp->env changes - if so, the object was stolen. >> This means storing the old ->env field away. If that succeeds, then >> send the esrv_del_item with the tag that was stored away. > > > Given that I've changed pick_up() to return a true/false value indicating > whether the pickup was successful, I probably don't need this anymore, > right? Correct. > > Also, do you think it makes more sense to send esrv_del_item *inside* > pick_up() or pick_up_item() instead? It would seem that fixing it once in > pick_up() will save us the headache of fixing the 50 other places where > pick_up() is called, which might have to do the same thing. (I don't know > if there's any other place which needs to do this right now, but it's > conceivable to happen in the future.) Well, using pick_up in the stealing code is really a pretty bad hack. pick_up was obviously originally designed/coded to pick up items off the floor and move it to a creatures inventory. Thus, things like checking for fly, no_pick, etc. And for that case, it seems to work fine. The expectation for pick_up() that the object may be in another creatures inventory is odd I suppose it wouldn't hurt for pick_up to send the appropriate client/server command. > Hmm, that's true. So then the question is, is it possible to have a flying > monster that steals, and how would I do it? Well, as said above, pick_up was originally designed for picking things up from the ground, where such a change made sense. The best solution would be to pass another flag into pick_up() which could say to let flying creatures pick up the object. Or the simpler, but slightly more dangerous way, would be to clear the flag_flying before calling pick_up, and then re-setting it afterwards. But calling pick_up() may call fix_player() or otherwise update stats, which makes that not quite such a good method. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel