Hi,
> post my findings here. The problem seems to be in DoBresen - > the following is data from mover, obtained by breaking in > rock::doit and inspecting the object. I have been unable to > check the values against Sierra SCI because the internal > debugger in it seems to be broken. > > The intended destination is (172,122). > > step # | x | y | > -------------------- > 1 | 169 | 120 | > 2 | 169 | 122 | > 3 | 170 | 122 | > 4 | 171 | 123 | Are you certain that these are the right values? Usually, one of the axes is increased by a constant value after each step... Anyway, if the indicated direction (1st quadrant) and the coordinates of the target destination and the 4th step are correct, the Bresenham implementation must be faulty, or the SCI script interfered with one of our values. This *MIGHT* be related to the PQ2/CB1 Mover problems, but the people working on these should rather debug them in-game- I still haven't seen a step-by-step comparison between Sierra SCI and FreeSCI in CB1 (where the debugger works); this would help clear up the situation with a very high probability (if client coordinates, DoBresen() and CanBeHere() return values, and possibly the helper values on both implementations were checked). > And that's where it seems to go wrong... > the part I don't get is why the if statement in DoBresen() fails > to notice that we've crossed our intended destination. I think it's mis-interpreting the quadrant the directional vector is in (4th instead of 1st quadrant). This is what ultimately causes the algorithm not to terminate, but it's not the original cause for its failure. There's a good chance our InitBresen() implementation is just broken. I played around with it when trying to investigate the earlier CB1 bugs, this might've triggered it. llap, Christoph
