Re: CRT Combat Model (really long)

[Jim Kingdon <kingdon at panix dot com>]

> Anyway, I just found that the function used in this case, random_walk,
> is causing some of the synch errors. For reasons that I really don't
> understand, it computes differently on a unix host and client.

Strange.  Did you step through the function on the host and the client
in a debugger?  And were the host and client the same kind of machine?
I glanced at the code and didn't see something like a 32bit vs 64bit
problem, but there is a fair bit of code there.

The other bizarre thing about random_walk is whether there is any
reason for it not to use for_all_directions_randomly?  That would be
faster than what it is doing now.  It would change the odds of picking
each direction at the edge of the world, but I'm not sure that would
be a big problem.

> So I'm going to rewrite it to work like the colonizer random walk,
> which perhaps also will solve the "get stuck" problem if we are
> lucky.

Meaning the call to 

    set_move_dir_task(unit, random_dir(), xrandom(20));

in plan_colonize?  There's similar code in plan_random.  I would think
that if you changed 20 to 1, you'd get much the same behavior as
random_walk.  But what about the case in which you set a move task
which would take you off the edge of the world?  Will the AI waste a
turn before it picks another task?

I'm also not sure I understand why there is both a TASK_MOVE_DIR and a
TASK_MOVE_TO.  I guess it leads to prettier displays of a task in the
user interface....