[freeciv-ai] Re: (PR#2477) Improved Auto-Explore
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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.
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. :)
> > 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
> 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 :)
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore, Gregory Berkolaiko via RT, 2003/01/08
Message not available
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore, Gregory Berkolaiko via RT, 2003/01/26
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore, Gregory Berkolaiko via RT, 2003/01/28
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore,
Gregory Berkolaiko <=
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore, Gregory Berkolaiko via RT, 2003/01/29
- [freeciv-ai] Re: (PR#2477) Improved Auto-Explore, (continued)