[CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire]

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      Actually, the fix does break a few things....
     
     >
     
      My mistake for not making sure that was ok.
     
     >
     
     
     >
     
      Basically, when you login, player won't even move... (probably due to 
     
     >
     
      the call from check_login).
     
     >
     
     
     >
     
      Here's the fix i propose (attached patch): set speed to 0 in 
     
     >
     
      clear_object, call update_ob_speed (if speed isn't 0 already, of 
     
     >
     
      course). This way, a call to clear_object certifies object is correctly 
     
     >
     
      removed from active list.
     
     
  IMO, that is a broken fix.

  It should be expected that if you make a call to reset_object() that none of 
the fields have any meaningful value.  Thus, passing in data that has been 
malloc'd should be perfectly valid (I think there may be other areas of the code 
that do something similar, but not 100% sure).

  reset_object() does call clear_object().  I suppose you could init the speed 
to zero in reset_object() - thus clear object won't do anything with it.  But 
that won't fix the bug.

  I already mentioned how to fix the bug - add a op->speed=0, 
update_ob_speed(op) into the code in login.c.

  It shouldn't be up to clear_object() to remove the object from any lists.  And 
in fact, it currently doesn't do this with respect to maps, inventories, or 
whatever else - it just sets those pointers to null.  Thus, if you make a call 
to clear_object() without calling remove_ob() first, there will be bugs there.

>
     
     
     >
     
      Doing that there was a trouble in treasure.c, during artifact 
     
     >
     
      initialization: init_artifacts would directly malloc( ) an object and 
     
     >
     
      call reset_object on it (thus some breakage in update_ob_speed due to 
     
     >
     
      uninitialized active_next/prev). So i changed to call get_object( ) 
     
     >
     
      (which is there to provide objects, isn't it? :))
     
     
  Depends.  get_object() provides objects on teh global linked list.  This is 
not always desirable - objects on the global list may get processed in various 
ways, which you don't want to have happen to things like the artifact objects. 
This is why I believe that it did in fact malloc the data instead of using 
get_object()




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel