[freeciv-ai] Re: (PR#2477) Improved Auto-Explore

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Tue, 28 Jan 2003, Cameron Morland wrote:

> > Also, if one hut is visible but more than 1 step away and there is 
> > unexplored terrain right under our noses, we will go for the unexplored, 
> > right?  Which is rather significant change of behaviour but I think we can 
> > still do it and then see if players complain ;)
> 
> Oh right. Since I way only experimenting with explorering units, this
> could never happen.

What is an "explorering" unit? ;)

> > Now, I found one mistake and have some questions.
> > 
> > 1. Using trireme_loss_pct in explorer desirable could be cheating.  I
> > think you mentioned it earlier.  I take it you don't want to fix it in
> > this pass?
> 
> I wrote the code at one point, so it was really easy to regenerate. I
> added likely_trireme_loss_pct and likely_coastline, both of which
> should always be used by the AI instead of trireme_loss_pct and
> is_coastline. Since at this point they are only used in my code, I
> left them in aiunit.c.

Looks good.  I didn't check in detail.

> > 2. In the first loop in ai_manage_explorer, when you declare int 
> > most_desirable, you give a slightly dodgy comment.  int is not a tile, 
> > it's the value of the most valueable tile.
> 
> Right.

Now, the comment right after that, "destination of most valuable tile".  
What you call "destination" most people call "coordinates" ;)

> > 4. A well-wisher suggested that maybe the return value of likely_ocean be 
> > used like a weight rather than bool, like this:
> >   desirable += ocean * ocean_score + (100-ocean) * land_score;
> 
> Yes, it makes sense to keep the value fuzzy as long as possible. But
> we need to scale it back down by 100, or, to save ticks, increase
> OWN_CITY_SCORE and HUT_SCORE by a factor of 100. Otherwise bad things
> happen, explorers ignore huts, and hackers go mad. :)

Right :)

> > 5. With Per's fix for 2631 in, maybe we can stop idling explorer?  If the 
> > answer is yes, we can do it in a separate patch, but you have to promise 
> > to make it! ;)
> 
> I removed the three mentions of idle in the function. It still runs.

The reason I prefered it to be in a separate patch is because we will not
get it right the first time, nor the second, I am afraid:  (1) you idle
the unit in the wrong place, I believe; (2) I don't think changing
conditions for MR_BAD_ACTIVITY is a good thing; (3) it started me thinking
why we use handle_move_request directly, instead of more robust
ai_unit_goto -- even for one step there might be a shorter (railroad)  
route around.  You see, many issues, and these are not all, I am sure.

Maybe we can commit the patch with IDLING and then make the changes in 
situ.  Otherwise this patch is growing too big and taking too long and now 
I am getting frustrated :(

So here is what should be done before inclusion:
1. Revert changes to Idling (sorry about it)
2. Fix the destination comment
3. And, yes, you make H_HUTS handicap obsolete.  Not necessarily a very 
bad thing, but maybe not now.  Put it back in, please, into your 
explorer_desirable function (compare to line 385 in aiunit.c).
4. Pray that you didn't introduce any bugs in likely_coastline and 
likely_trireme_loss ;)

> Slow pace! Ha! Last week one of my courses consumed 3
> days. Extrapolating and assuming all my courses are that hard, this
> means I need 15 days per week. A slow pace is not a problem at
> all. :) I will probably have to disappear for a few months once this
> thing is done.

Good, so I am not the only one disappearing every now and then :)

G.