FreeOrion

First of all, it's great to finally see a MOO clone with some organization and momentum! (And written in C++) I would very much like to help out, by performing code reviews if nothing else. But first I would like to actually run the game.

After a few false starts, I was able to build the three executables, using version 4.9.8.0 of DevCpp. The server seems to run fine (it opens a socket on port 12345) but the human client does nothing. No error message, no nothing. Well, it does seem to print a blank line before giving me the prompt back, but that's it. (freeorionca does the same)

I tried to use the debugger to step through and see what was going on, but this doesn't seem to work either. No really useful information from DevCpp, but running gdb from the command line I get a "sect_index_text not initialized" error. This seems to be a known bug, with an attempted fix in gdb 5.2, but the version in DevCpp 4.9.8.0 is 5.1.1. I did try the debugger with a toy DevCpp project, and it worked fine, both from DevCpp and the command line.

So I stuck in a cout<< as the first line in chmain.cpp:main(), and recompiled and still got nothing. Hmmmm. FWIW, I got the sources this morning (Thursday).

freeorion.exe is 32,117,848 bytes (!!)
freeorionca.exe is 9,745,031, and
freeoriond.exe is 12,170,009.
I am running Windows 2000.

BTW, since DevCpp is in Beta, it would probably be good to include the "official" version in the README.txt in windowsKit.Zip. Ditto for zlib, since the header files are not in the zip.

Thanks in advance,
- Kevin

_________________
What is done out of love always occurs beyond good and evil.
- Nietzsche

I have no idea from that what the problem is. I added zlib.h and committed WindowsKit.zip though. Actually, the problem really sounds like some kind of library version conflict, or different compiler versions maybe. Are you using gcc >= 3.2? That's the version I built the .dlls with. If you're using 3.3 there may be some ABI issues, but I'm not at all sure about that.

Gcc is definitely version 3.2. (mingw special 20020817-1). The versions of the dlls seem to match the versions reported in the header files, insofar as I can check them. Might I suggest a version resource be added to the GG dlls?

Has anyone else had a problem with gdb (on the command line) reporting sect_index_text not initialized? If not, what versions of gdb are people using? (Mine is 5.1.1, which came with DevCpp 4.9.8.0.

The cout<< problem was just a silly mistake on my part. MessageBox() works much better. So far I've verified that chmain.cpp gets all the way to g_app(). However, since I currently only have the header file and dll for SDLGGApp, it will take a little time to find out where to throw in the next MessageBox.

However, It occured to me that it might be because I have no sound card on this computer. Can anyone confirm or deny that this would make the app throw up its hands in disgust?

Also, I have not yet run across a description of how the logging works. (Haven't really looked yet, though I did briefly look over the home page) What's the best way to find out where the log(s) is (are) created & how to enable logging? Forums, source code, TFM? This might help me track down the problem.

Thanks.
- Kevin

_________________
What is done out of love always occurs beyond good and evil.
- Nietzsche

OK, it's the call to MixOpenAudio() in HumanClientApp::SDLInit() that is failing, resulting in an Exit(1).

Ideally it seems that lack of audio should not prevent the game from running. Would there be some way to open a 'null' audio device so this could be done witout littering the code with with if (AudioWorking()) conditions?

I poked around the available documentation of log4cpp. It looks like the log is using stdout (or stderr?), whatever the default appender(?) is. I will look into using file output, say to ./logs/<date-time>.log. Does this sound useful for anyone else?

- Kevin

_________________
What is done out of love always occurs beyond good and evil.
- Nietzsche

Currently, the AIs create logfiles called AI###.log (or something like that anyway, the ### being the AI's id number), the human client creates a freeorion.log and a ClientUI.log, and the server creates a freeoriond.log.

We do not need to address this sound issue imo, since sound will be a system requirement. However, if you can find a simple and clean way to handle a missing sound system, we'd gladly accept the patch.

I have the source now in linux (SuSE8.2) Ahm ... I hope thats not a stupid question: I wanna know how to compile in linux ? I've tried make, make install, sh *.sh , I guess I do something wrong.

It's However, you will either need to

• Create the configure script with autotools
• Let update-configure download the autotools-generated files

If SuSE has installed automake 1.7, autoconf 2.5 and libtool 1.5, you can run autogen.sh to create the files for you, otherwise, just use ./update-configure

update-configure needs the program wget, install it if you haven't it already.
Then do the configure;make stuff

EDIT:
You'll need to install GG first. Get it from CVS, this time it should include configure etc.
Unfortunately, the permissions for some files are wrong, you'll need to do a

Afterwards, you just do (--disable-debug removes the debugging symbols from GG, this way, it will be 3M instead of 25M)

If you have any problems, just drop me a PM (I'm german, so you can do it in german

I've been experiencing a lot of version conflicts lately and I've been resorting to doing complete rebuilds to try to weed them out, and since Dev-CPP takes about 35 minutes to compile the client on my system, I'm starting to get impatient as I've done it at least 3 times in the last 48 hours.

I am running windows XP.

Today, I have done the following:
- deleted the entire contents of C:\FreeOrion (except some changed files I wanted to keep, which I put into a seperate directory)
- checked out the source from the repository (done this afternoon at around 5:00)
- extracted the repository version of WindowsKit.zip to C:\FreeOrion
- copied the 'copy-to-devcpp' stuff to C:\Dev-CPP
- built everything in the client (from scratch).

It is now crashing right before displaying the intro screen. This is extremely frustrating to me, since I aught to be able to do a clean checkout and have things work, especially if the source that's there is working for others

Stuff I have NOT done yet:
- I have not checked out anything from Zach's GG repository in the last month or so.
- I have not done anything to the code except to add "." to the "/default" directory in some places, in the hopes of fixing it.
- I have also not replaced my versions of log-4-cpp, boost, or expat with any of the stuff found in WindowsKit (has there been a new version of any of these put in there recently?)
- I have not built the server or AI client, because as far as I know I shouldn't need them yet.

I suspect a GG version problem, but I have no idea where to look. Is there something else that needs to be done? New GG, SDL or OGL libraries that aren't in WindowsKit?

EDIT: The GG DLL's from the WindowsKit that I got from the repository are dated 9/9/2003 if that helps.

JB

_________________
Empire Team Lead

Did you also copy all of the GG headers from WindowsKit.zip to C:\FreeOrion\GG\include?

Also, where is the problem? Have you traced through the code in gdb, or at least run it under gdb to see where it is failing? If so, send me a stack trace and I'll have a look.

As for the long rebuild times, try turning off debugging support in DevC++; it should make your rebuilds quite a bit faster. (However, it also makes debugging quite a bit impossible.)

The are GG headers are in C:\Freeorion\GG\include

I would love to trace through the code in gdb, but when I try to do it within Dev-Cpp it just sits there and gives me no meaningful output, and when I do it from a command line is says this:

C:\FreeOrion>C:\Dev-cpp\bin\gdb FreeOrion.exe
GNU gdb 5.1.1 (mingw experimental)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mingw32"...
(gdb) run
Starting program: C:\FreeOrion/FreeOrion.exe
../../../BUILD/gdb-5.1.1/gdb/coffread.c:472: gdb-internal-error: sect_index_text
not initialized

I will go online sometime and try to download a new version of GDB to see if it will work better.

I know from walking myself through the code and from examining the logs that it's happening sometime after HumanClientApp calls ClientUI::Initialize() I suspect it's someplace in the Introscreen constructor. I also know from the windows-generated error code that it's an access violation.

_________________
Empire Team Lead

I'm planning to install cygwin, in the hope of getting a working gdb and/or better gcc performance. Once I've done that I'll do another build and see if I still get the same problem. Hopefully this is just a quirk i my current setup.

JB

_________________
Empire Team Lead

I've installed CygWin. Build times seem a little better but are still rather slow. I'm currently getting some errors in MapWnd.cpp:

/usr/boost_1_30_0/boost/random/uniform_smallint.hpp: In instantiation of `boost:
:uniform_smallint<int, int>':
../../UI/MapWnd.cpp:73: instantiated from here
/usr/boost_1_30_0/boost/random/uniform_smallint.hpp:257: `int' is not a class,
struct, or union type
/usr/boost_1_30_0/boost/random/uniform_smallint.hpp:190: `int' is not a class,
struct, or union type
../../UI/MapWnd.cpp: In constructor `MapWnd::MapWnd()':
../../UI/MapWnd.cpp:73: no matching function for call to `
boost::uniform_smallint<int, int>::uniform_smallint(int, int)'
/usr/boost_1_30_0/boost/random/uniform_smallint.hpp:187: candidates are:
boost::uniform_smallint<int, int>::uniform_smallint(const
boost::uniform_smallint<int, int>&)
/usr/boost_1_30_0/boost/random/uniform_smallint.hpp:205:
boost::uniform_smallint<UniformRandomNumberGenerator,
IntType>::uniform_smallint(UniformRandomNumberGenerator&, IntType = 0,
IntType = 9) [with UniformRandomNumberGenerator = int, IntType = int]

etc etc There are a bunch more of those 'no matching function' errors which I'm sure are related to the stuff above. My gcc version is 3.2 (20020927)

I'm using the same boost version I used when I compiled it with Dev-Cpp. I just copied it to cygwin\usr verbatim


I'm using the Makefile that's in CVS under client/human
I have had some problems with the autoconf scripts and never got them to finish properly, so that could be part of my troubles. Is it necessary to run the scripts before I try to make using that makefile? The makefile appears to work on its own.

_________________
Empire Team Lead

Fixed. See the CVS Commit info thread.

I had the same compilation problems in Linux solved with the latest commits.

After downloading GG and FreeOrion from CVS repository, I have a question: what suxx is the Perforce (needed for Boost C++ libraries) and where can I get it for gcc 3.2.2 (Red Hat Linux 9)?
Can anyone translate sucking Jamfile into common Makefile?

_________________
This is what you get ...