Possible bug in side_can_research

Possible bug in side_can_research

[Lincoln Peters]

When I re-wrote ai_plan_research, I had assumed that the
side_can_research function would return false for advances that have
already been researched.  However, having run advances.g several times
under AI control, I've found that the AI will frequently select an
advance that it already has discovered.  And I have not found any logic
errors in the new ai_plan_research function.*

Would it be reasonable to modify side_can_research so that it returns
false for advances that the side already has?  Or would it be better to
place the necessary code in ai_plan_research instead?


* This is not to imply that no logic errors exist in the new version,
just that if they do exist, they are currently undiscovered.

---
Lincoln Peters
<sampln@sbcglobal.net>

BOFH excuse #251:

Processes running slowly due to weak power supply

Re: Possible bug in side_can_research

[Eric McDonald]

Lincoln Peters wrote:

> When I re-wrote ai_plan_research, I had assumed that the
> side_can_research function would return false for advances that have
> already been researched.  However, having run advances.g several times

That should be the case, and seems to do exactly that in the places it 
is used in the new side research code in the SDL UI. I am surprised that 
it is causing you problems.

> Would it be reasonable to modify side_can_research so that it returns
> false for advances that the side already has?  Or would it be better to
> place the necessary code in ai_plan_research instead?

Actually, there is a function to update the research vector and it gets 
called whenever a topic is actually researched in the kernel run code.

> BOFH excuse #251:
> 
> Processes running slowly due to weak power supply

Excuses such as "solar flares" or "electrostatic buildup" are easier to 
manipulate feeble minds with....

Eric

Re: Possible bug in side_can_research

[Lincoln Peters]

On Fri, 2004-09-10 at 19:45, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > When I re-wrote ai_plan_research, I had assumed that the
> > side_can_research function would return false for advances that have
> > already been researched.  However, having run advances.g several times
> 
> That should be the case, and seems to do exactly that in the places it 
> is used in the new side research code in the SDL UI. I am surprised that 
> it is causing you problems.

So maybe there's a logic error in the new ai_plan_research function that
produces an effect comparable to a logic error in side_can_research? 
It's certainly possible.

> 
> > Would it be reasonable to modify side_can_research so that it returns
> > false for advances that the side already has?  Or would it be better to
> > place the necessary code in ai_plan_research instead?
> 
> Actually, there is a function to update the research vector and it gets 
> called whenever a topic is actually researched in the kernel run code.

I'm a bit unclear on this.  Do you mean that it selects a new advance to
research at the beginning of every turn?  I'd say that such behavior is
rather inefficient.

---
Lincoln Peters
<sampln@sbcglobal.net>

There's a way out of any cage.
		-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
		   stardate unknown.

Re: Possible bug in side_can_research

[Eric McDonald]

Lincoln Peters wrote:

>>Actually, there is a function to update the research vector and it gets 
>>called whenever a topic is actually researched in the kernel run code.
> 
> I'm a bit unclear on this.  Do you mean that it selects a new advance to
> research at the beginning of every turn?  I'd say that such behavior is
> rather inefficient.

It doesn't have anything to do with selecting new advances to be 
researched. It just updates the list of which advances can be 
researched, so that that list can be used elsewhere 
('side_can_research', for example).

Eric