This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: code in adjust_tooling_crossover?


On Thu, 2002-07-11 at 15:34, Hans Ronne wrote:
> Another current limitation in the AI code is that units, like the
> engineers, who can build both builders of other units (cities) and other
> unit types (e.g. bridges) always are assigned a colonizing plan which means
> that they never will build anything but cities. This makes sense since a
> unit that can build other units (a city) is by far the best thing to build
> in most games. Still, I wonder if we should not let them build an
> occasional bridge as well. Just for variety ...

I think that bridges would work better as connection terrain, actually. 
I also think that it would be easier to program the AI to take advantage
of them as connections.  The simplest way to program engineers to build
roads (and road bridges) would probably be:

1. Move to point A.
2. Measure the distance from point A to point B, store as variable d.
3. Decrement d by 1.
4. Move to within d of point B.
5. Add terrain of type road (or other connection) in the direction of
point B (if there are two choices for direction, it might be safe to
pick one at random).
6. If d>1, go back to step 3.

I haven't tried programming anything like this, but if mp-to-traverse
allows a unit to move along a connection on otherwise hostile terrain,
it should work.  The only problems I can think of would be if the
engineer was obstructed by another unit or if the engineer might suffer
attrition or accidents on terrain that a road passes through.  But
wouldn't it make sense for a connection to protect units from attrition
and accidents in certain terrain?


As for the "vanishes on" fix I was working on, when I work on
plan_colonize, I can't seem to access anything within unit2 without
causing a segfault.  I tried adding the following line of code after it
decides if the cell is "good":

if (!ut_vanishes_on(unit2->type, terrain_at(x, y))) {

Could there be something going on with pointers in unit2 that I'm
missing?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]