Re: Here is the patch

[Jens Granseuer <jensgr@gmx.net>]

On 10.03.2004 04:09, Gil Pinheiro wrote:
> Your right about the annoying nature of the bug! It has never manifested 
> in my windows build - likely there is some difference in the virtual 
> table structure.
> 
> The fix turns out to be quite simple: in ai.h append =0 to the virtual 
> function definitions. Silly error, but jeeze, it would be nice if gcc 
> gave a better error.

Hm, yes, I missed that. Builds fine now.

> Also the linux build seems to have a few problems:
>     AM_PATH_SDL issue that was mentioned on the list earlier is due to 
> SDL standard install location, if you look at SDL_ttf or SDL_mixer the 
> standard fix is to include acinclude.m4 with the source distribution.

I think you're mixing a few things up here. The problems with AM_PATH_SDL
only occur when building from CVS. When using a distribution tarball
the macro is included in aclocal.m4.

>     It may be a good idea in future to stick autogen.sh with the source 
> dist. as well, I know its in the CVS, but it may be helpful.

What for? In the tarballs you already have configure which in turn can
generate the Makefiles from the Makefile.ins. The purpose of autogen.sh
is to create configure and the Makefile.ins.

>     Also if you watch aclocal/autoconfig, there is an error about out of 
> order calls - I'm no auto* expert, so I leave it to those who know more 
> - if you can't reproduce it, I can always grab a copy of the error.

Yes, I know about the error. Actually I have patched my SDL to make it
go away. The sdl.m4 script contains a command that is completely
unnecessary IMO, and to get rid of the warning we'd have to distribute
two more auto* scripts (config.guess and another one which I don't
remember9 which we don't use and don't need. Therefore I'd rather live
with the warning than try to fix it. Maybe I should ask the SDL guys
about it...

I've had a look at the changes you made. At this point I'd prefer not
merging them in, mainly because of two reasons:

1) with the changes with regards to campaigns, difficulty levels, etc.
currently discussed, much of the code (almost everything outside of
the ai* files themselves) would have to be reworked anyway. That's why
I think it is better to wait for those changes to happen. As a result
some of the interface adjustments you made will fit in even easier.

2) I have a few (mostly minor) objections concerning various implementation
details. (The one that hit me first when trying to resolve the linking
error yesterday was the AI stuffed into the Player class and the circular
reference this resulted in. Something like that is usually a sign of
design errors. I know that I did the same in a few cases but that doesn't
mean new code is allowed to repeat that mistake ;-) In this case it looks
like it can easily be avoided.) If you like we can discuss the points in
detail but should probably take this off-list then.

2.5) I'd like to have the mapper select the AI best suited for a scenario,
not the player. Thinking about it, the "null" AI might actually be quite
useful for the tutorial campaign.

In general, the idea is nice and I hope we can put it to good use.
Speaking of which, what is it specifically that you aim for in your AI
project?

Jens