Bugzilla Bug 96249

Hi,

I'm part of the development team of the Warzone 2100 ReDev project. Warzone 2100 was an innovative 3D real-time strategy game back in 1999, and most will agree it didn't enjoy the commercial success it should have had. The game's sources were liberated in december 2004, and the Warzone 2100 ReDev project was formed.

This version is still experimental, but fully functional. As far as we know, it doesn't crash that much. We have stripped the original code of anything proprietary or Windows related, and replaced with SDL, SDL-net, and openal. We have made very few game modifications (interface, mostly) as our goal right now is to release a stable cross-platform version.

At this time, it works very well in Windows and x86 GNU/Linux. We played a network game between a Windows and a Linux machine last night, and except for the fact that I lost, there was no issue. Campaign-mode, single-player skirmish (with computer AIs) and network games (also with computer AIs) work great.

Please report bugs in the game at http://developer.berlios.de/bugs/?group_id=2909. This bug entry is for the Gentoo ebuild only. You can join the Warzone 2100 Development Forum at http://www.realtimestrategies.net/forums/index.php.

Created an attachment (id=61316) [edit]
warzone2100-0.1.ebuild

i suppose necessary permissions can be set by 'prepgamesdirs'
and wrapper created by 'games_make_wrapper'

(In reply to comment #2)
> i suppose necessary permissions can be set by 'prepgamesdirs'
> and wrapper created by 'games_make_wrapper'

Thanks for the info. I'll check this and update the ebuild.

(In reply to comment #3)
> (In reply to comment #2)
> > i suppose necessary permissions can be set by 'prepgamesdirs'
> > and wrapper created by 'games_make_wrapper'
> 
> Thanks for the info. I'll check this and update the ebuild.

I was waiting for the new release to come (0.1.1 or 0.2, we don't know yet) to
submit the cleaned-up ebuild, but I decided it could be interesting to get
feedback about it as soon as possible. So, here it is (warzone2100-0.1-r1.ebuild).

Created an attachment (id=61617) [edit]
warzone2100-0.1-r1.ebuild

Created an attachment (id=62134) [edit]
warzone2100-0.2.ebuild

Changelog:

* Uses new version 0.2 of Warzone 2100. See notes here :
http://sourceforge.net/project/shownotes.php?release_id=337805

* Makes use of the opengl USE flag, to allow for software rendering with
-opengl.

* Added dependencies to virtual/opengl, media-libs/libvorbis and
media-libs/libmad.

* Uses SourceForge mirroring system.

* Cosmetic corrections in order to fully respect ebuild writing rules.

Since it's been tested on different machines for a few days now and with no
issue, this looks pretty final to me until next version of Warzone 2100.

It would be great if it was possible to make it multilib compatible. Want to
run
it on amd64 ;/

considering the game is from source, multilib is pointless

Created an attachment (id=62208) [edit]
warzone2100-0.2.ebuild

try this ebuild

Created an attachment (id=62230) [edit]
warzone2100-0.2.ebuild

(In reply to comment #9)
> Created an attachment (id=62208) [edit]
> warzone2100-0.2.ebuild
> 
> try this ebuild

Thanks for the cleanup. However, this release of Warzone 2100 is far from
perfect yet, which requires two modifications :

* openal is not currently an option. 'configure --help' seems to allow doing
without openal, but it wont build.

* the content of the data directory needs to be at the same level as the
executable, or it will not run.

Both issues need to be corrected for the next release. All in all, it looks
much better like this, though. Thanks again.

that's the point of the wrapper script

it says to chdir to "${GAMES_DATADIR}/${PN}" before executing
"${GAMES_LIBDIR}"/${PN}/warzone 

(In reply to comment #11)
> that's the point of the wrapper script
> 
> it says to chdir to "${GAMES_DATADIR}/${PN}" before executing
> "${GAMES_LIBDIR}"/${PN}/warzone 

I got that. But there's a bug which makes that changing to the directory is not
enough. The executable has to be installed in "${GAMES_DATADIR}/${PN}", and
the data has to be installed like this :
	doins -r data/* || die "doins data"
instead of :
	doins -r data || die "doins data"

We are doing massive code cleanups for the next release, and this will be corrected.

PS. I forgot to make the previous ebuild obsolete last time, sorry about that.

Please add USE=debug to make debugging easier once ./configure --enable-debug 
doesn't create compile-time errors anymore. I allready filed a wish for fixing 
--enable-debug to the Berlios-page. 

Created an attachment (id=63574) [edit]
warzone2100-0.2.1.ebuild

New ebuild for new release. Lots of bugfixes upstream, including some which
enable a cleaner and more standard ebuild. The only peculiarity left is the
non-working 'make install' due to the data not being included in our subversion
tree. We are already working towards fixing this for next release.

Changelog for the ebuild:
* Directory structure in tarball corrected, so S=${WORKDIR} no more needed.
* Got rid of the static Makefile, so calling src_unpack() to run autogen.sh
isn't needed any more.
* The executable no more needs to be located in the same directory as the data.

* debug USE flag not added, but --enable-debug removed from configure. We are
more and more thinking that some parts of the old code are beyond fixable. The
debug code may be one of them.

Version 0.2.2 has been released (bugfixes, mainly). Get the changelog here:
http://sourceforge.net/project/shownotes.php?release_id=345320

The ebuild stays the same. So, just copy warzone2100-0.2.1.ebuild to
warzone2100-0.2.2.ebuild, do a digest, and you're set.

Instead of the wrapper script, I'd prefer to see the source patched to
correctly
find the data files.  This is the hold up in adding this package to portage.

(In reply to comment #16)
> Instead of the wrapper script, I'd prefer to see the source patched to correctly
> find the data files.  This is the hold up in adding this package to portage.

Am I understanding correctly that the use of games_make_wrapper is undesirable ?

Yes.  It should mostly be used for things like -bin packages and java packages
where there isn't necessarily a nice executable to be run.  If we have the
source, as in this case, a patch is the way to go.

Created an attachment (id=67497) [edit]
patch : src/clparse.c

allows to search datas in $GAMES_DATADIR.

Created an attachment (id=67498) [edit]
warzone2001-2.2.ebuild

some modifications to Charun's ebuild for applying the precedent patch

openal is not a dependency, had to install in manually maybe you can add that..

(In reply to comment #21)
> openal is not a dependency, had to install in manually maybe you can add that..
Sorry it is a dependecy but it didn't install it..  

The 2.2 ebuild works for me..  (fun game too)

Added to CVS, slightly modifed, to remove the nasty -m32 garbage from the
ebuild, since it compiles fine for me on amd64.