Re: bug in autoDrop?

[Mirjana Majdandzic]

Hi,
Thank you for your suggestions on the autoDrop problem. 

I tested whether autoDrop really dropped the action in the following way:
(In BuildObjects in ModelSwarm, where the first generation of my agents
(i.e. monkeys) are created)
**************
 counter = [monkeyList getCount];
  for (i = 0; i < counter; i++) {
    R = [uniformIntRand getIntegerWithMin: 1 withMax: 10]; 
    debugActionptr = [modelSchedule at: R createActionTo: [monkeyList atOffset: 
i] 
                                    message: M(TODO)];

(after this, they schedule themselves)
**************
I checked every timestep whether the object to which "debugActionptr" refers 
still existed:
  [debugActionptr xprint];
If the action would really been dropped,  an error should be given (as far as I 
know),  
but the program continued to return a value (0x81a1dd8: ActionTo_0).
(When I explicitly dropped debugActionptr, an error indeed occured).

Following Doug's suggestion, I also checked in Schedule.m, in nextAction, 
if "debugActionptr" ever was equivalent to "removedAction":
**************  
  if ( ((Schedule_c *)collection)->bits & BitAutoDrop ) {
     printf("Bitautodrop= %d\n", BitAutoDrop); // for debugging

     removedAction = [super remove];

     if (removedAction == debugActionptr) { // for debugging
       printf("removedAction == debugActionptr\n");
     }
     [debugActionptr xprint];   // for debugging
     [removedAction xprint];    // for debugging

     [removedAction dropAllocations: 1];
   }
*************
They never were equivalent, so debugActionptr does not enter this loop.
I still think the actions are not really dropped, if this is the right way to
check it (?).
I hope this helps to clarify the problem.

Bye,
Mirjana