On Tue, 25 Dec 2001, Christoph Reichenbach wrote: > > 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? > 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), or added some comments to that function? > > I don't see any way to tell any of these are "stopUpdate()d" > > from the output, or by looking at the source for the > > _gfxwop_some_view_print() function. Looking at the definition for > > gfxw_dyn_view_t helps a little, but doesn't give me the big picture view > > of how this could/would relate to the bug. > > I'm sorry that I don't keep the documentation up to date with these > changes. I only have the usual excuses (no one cares; not enough time; > "it's probably just a temporary change"; we're too far behind already, so > no one can understand it anyway; source code is more precise and > much easier to read) to 'explain' this, I assume using some tool to > generate documentation from the sources would be called for (particularly > for the constant values). I must apologize for not keeping the > documentation up to date At least there is documentation! :) I didn't mean to criticize the lack of updated documentation, I was more asking for an explanation and saying I had already looked in the sources and docs as part of my diligence. > 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 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. > BTW, thanks for going through all the trouble of debugging this! You're welcome :) Just trying to do my part in making sure the release happens soon with as few gameplay bugs as possible. -- http://www.clock.org/~matt
