Hi,

> > > They don't follow the same path in FSCI as in SSCI, that's why the
> > > coordinates are slightly different. What I did was step in the SSCI
> > > debugger until shopwoman was at x of 82, which is where she stops in FSCI.
> > > The y coordinate is different, which doesn't make sense. They seem to
> > > deviate from their path sooner in FSCI than SSCI.
> >
> > She seems to have an Avoider, which could have caused this (triggered by
> > the collision), so fixing the collision would fix this as well (provided
> > that my assumption is correct).
> 
> Okay. So, the collision happens too fast for the Avoider to move her our
> of the way?

My guess would be that the Avoider can't handle the situation, as it
expects moving objects only to block the area covered by their brRect.
(In other words, it's only a second symptom of the underlying bug).


> > The signal values are the same as for view objects, except for the two
> > additional flags mentioned in kernel.h; one is used as a temporary result
> > (-> updated Animate() algorithm), the other is a very recent hack or
> > solution (I'm not sure which it is quite yet) to mark views that have been
> > stopUpdated(), and this is 0x20000000.
> 
> Excellent, thanks for the explanation! Would you mind if I either
> reformatted the debug output to be more readable (list heapobj, for
> instance),

Um... you mean rename 'objs' to 'list heapobjs'? I'm not sure what you're
aiming at...

> or added some comments to that function?

Which function?

Sorry, I guess I'm missing something obvious here...

> > Sorry, I meant the list of haines::signal in temporal order, starting at
> > his first appearance and leaving out duplicates in between. Doing this
> > manually would be rather painful.
> 
> Can you explain what you mean by "list of haines::signal in temporal
> order"? Do you mean to print the dynview information for haines from the
> moment he steps on the screen

>From the first time Animate() is called upon a list which he is a member
of, rather, but otherwise, yes.

> and then sort the output by the temporal
> value of his dynview? If that's what you mean, I can do that and have
> something by tomorrow.

Well, if you do have the spare time, I'm not going to stop you :-)
It's not certain this will yield new results, but if it does, it might
allow us to make the destopupdatification process (some language
lawyer is going to kill me for this) more restrictive.


llap,
 Christoph


Reply via email to