Hello. Although I've known xconq for a very long time, I've only recently
started developing with it. This is my first posting to this list.
I'm hoping to start (yet another) xconq revival, but I'm not going to go
into too much detail right now, because I've got a long way to go and anyway
I'm not sure anyone's listening.
But to find out whether there is, I'll start by asking about a possible bug
that's been hampering me:
It's in move.c rev 1.55, line 401:
if ((dist == 2 && !border_slide_possible(u, ox, oy, x, y)) && dist >
u_move_range(u2)) return A_ANY_TOO_FAR;
If I understand correctly, this allows a border_slide to move a unit a
distance of 2 even if its move_range is only 1.
But I have units whose move_range is greater than 1, and this line stops
Wouldn't it be better written:
if (dist > u_move_range(u2) + (border_slide_possible(u, ox, oy, x, y)?1:0))
This helps units with a move_range over 1, however it probably doesn't
compensate for multiple slides between ox,oy and x,y. But I don't feel I
understand border_slides enough yet to fix it completely.
Ed Hurst-Frost wrote:
> This helps units with a move_range over 1, however it probably doesn't
> compensate for multiple slides between ox,oy and x,y. But I don't feel
> I understand border_slides enough yet to fix it completely.
Border sliding is a very awkward mechanism for movement, and I think the
general consensus now is that it never should have existed in the first
place. There has to a better way to get the same results.
I'm also pretty sure that there are no games in the library that
actually support moving a unit more than one cell in a single action, so
I wouldn't be surprised if you found bugs there (Xconq has an
unfortunate history of being loaded with new features that don't get
tested until years later).
By the way, it looks like you're posting to the old site that was hosted
by Red Hat, which has not been updated for about two years (although the
mailing lists still function). The Xconq project is now being hosted on