This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: time.g weirdness
- From: Hans Ronne <hronne at comhem dot se>
- To: Robert Goulding <Goulding dot 2 at nd dot edu>
- Cc: xconq7 at sources dot redhat dot com
- Date: Tue, 10 Aug 2004 22:44:58 +0200
- Subject: Re: time.g weirdness
>Twice I've been playing time.g using the new Mac OSX binaries; and in
>both games something weird has happened to one of my triremes. Having
>developed tech to the City level, I've sent off an unneeded trireme to
>explore uncharted territory by clicking at random on a black section of
>the map. Each time, the boat has reached the place I clicked - but
>that place was inland, so that the trireme is now stuck! I've attached
>a little snapshot from my most recent game. Here, the trireme is
>awaiting orders, having reached the position I sent it to...
OK, I have managed to reproduce this now, and I think I know what is going
on. The ship is actually behaving as it should, since ships can move along
rivers in time.g:
(table mp-to-traverse
(ship river 2)
(ground road 1)
)
This is called a "border slide" in Xconq terminology.
Now, the real problem is that Xconq fails to set a move task that requires
a border slide when you try to do this manually. This is because the move
command pre-flight code doesn't know about border slides. I think that
Peter Garrone added some code that addressed this problem, but it was
probably removed with his path-finding code.
Anyway, the command pre-flight also has other problems, as I mentioned
earlier, so it is probably due for an overhaul.
Hans