Jump to content
XCOMUFO & Xenocide

Ufo2000 Beta Testing


Serge

Recommended Posts

  • Replies 262
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

It was kinda stupid to name the release package exactly the same as the original - a friend of mine downloaded the latest and I had to surprisingly download again (even when i had the exactly same name package in my download folder) so that we could play (it said I have an old version).

 

I thought I didn't need to since I already had 1079 but from about month earlier...

 

So next time you release, up the version number and reflect that in the installer package name, even if there is no new content as it's helpful to know what version you have.

Link to comment
Share on other sites

Guest Azrael
It was kinda stupid to name the release package exactly the same as the original - a friend of mine downloaded the latest and I had to surprisingly download again (even when i had the exactly same name package in my download folder) so that we could play (it said I have an old version).

 

I thought I didn't need to since I already had 1079 but from about month earlier...

 

So next time you release, up the version number and reflect that in the installer package name, even if there is no new content as it's helpful to know what version you have.

Hmm... latest release was a joke, and was named 1079, while the previous beta release was called 1071.

 

I think the guys have the necessary experience in upping version numbers when updating :P any problems you may have experienced might be related to the fact that the latest version was an April Fools joke :laugh:

Link to comment
Share on other sites

yeah, nice prank...

It's only that when I first saw it, it was 4th of april already...

So obviously I though that this is awesome and downloaded it instatly.

Needless to say, it wasn't funny when I found out.

So could you please add notification to http://ufo2000.sourceforge.net/ about it? or delete it completely.

Link to comment
Share on other sites

So could you please add notification...

 

Done

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...
any new release comming soon?

i want tftd aliens

I have yet to cope with my partially broken build.

I sure haven't got the next stable for now. <_>

Link to comment
Share on other sites

  • 3 weeks later...

After a recovery of what I had done, and a temporary funeral for the highresolution tilesets. Here's what we got :

 

The visibility bug is fixed. Now you can see everything you should above and below your soldier. No more gap.

 

Night combat improvement. Your soldiers will now have a glowing halo to somewhat reflect visibility (much like old X-COM)

http://img55.imageshack.us/img55/5859/lightlq5.th.jpg

 

For the next beta, I'll try to get rid of the "anything through walls" problems. Starting with lights and moving on to explosions if all goes well.

Link to comment
Share on other sites

After a recovery of what I had done, and a temporary funeral for the highresolution tilesets. Here's what we got :

 

The visibility bug is fixed. Now you can see everything you should above and below your soldier. No more gap.

 

Night combat improvement. Your soldiers will now have a glowing halo to somewhat reflect visibility (much like old X-COM)

http://img55.imageshack.us/img55/5859/lightlq5.th.jpg

 

For the next beta, I'll try to get rid of the "anything through walls" problems. Starting with lights and moving on to explosions if all goes well.

 

 

oh heck yes, this looks fantastic.

 

is that a mechanical flying bug? or am I just horribly misinterpreting that unit.

Link to comment
Share on other sites

I believe it is the flying drone unit that never got released, from here.

 

EDIT: I stand corrected, it was released. Grab the hover.zip file from that post.

Edited by Exo2000
Link to comment
Share on other sites

After a recovery of what I had done, and a temporary funeral for the highresolution tilesets. Here's what we got :

 

The visibility bug is fixed. Now you can see everything you should above and below your soldier. No more gap.

 

Night combat improvement. Your soldiers will now have a glowing halo to somewhat reflect visibility (much like old X-COM)

http://img55.imageshack.us/img55/5859/lightlq5.th.jpg

 

For the next beta, I'll try to get rid of the "anything through walls" problems. Starting with lights and moving on to explosions if all goes well.

 

Awesome! Keep up the good work Nachtwolf! =b I'm looking forward for the next series of updates. :D

Link to comment
Share on other sites

Starting with lights and moving on to explosions if all goes well.

 

It is not yet going well... :(

 

At least, what you saw works. And the vision bug was fixed.

Link to comment
Share on other sites

I don't know if you've seen this mentioned in other threads. But if you are fixing some bugs... there is a panic related bug that crashes the game to desktop, everytime without fail.

 

It can't be recreated in hotseat, so a bit hard to test by oneself.

 

Player 1: Has a unit who is panicking, end his turn, unit is still panicking.

During Player2's turn, player 1 uses TAB to cycle through his units, when he cycles back to his panicking unit, player 2 is ejected from the game, and a new turn starts for player 1. This causes lots of fun sync errors upon reconnection.

 

The message "Joe Smith has panicked" is relayed each time the unit is cycled to, and the turn count goes up.

 

It seems like it would be a simple fix, as somewhere, the Turn end sequence is connected to that panic message.

 

 

----

 

and (sorry, another big one) when units are stunned via proximity mines, just by mines, that player is unable to end his/her turn and the game must be stopped. I've only tested this with the ufo2k set, but its repeatable with both stun mines, and proximity mines (when they stun a unit and don't kill it). This happens in both hotseat and online.

Link to comment
Share on other sites

I'll look into this. Thanks =b
Link to comment
Share on other sites

  • 6 months later...
  • 1 year later...

Definitely not in this case. I would try to learn C just to work on this, but my all-honors school schedule and my Eagle project have me busy enough as is. But yeah, someone really needs to set working on this again.

 

I mean, it's a fabulous game, it's just not large/popular enough, and has enough bugs to drive most of the potential audience away. And development appears to have stopped.

 

So come on! Anyone with a knowledge of C and some spare time should give just a little time to this. If everyone here did, we would have a new version in months.

Link to comment
Share on other sites

Accipitre's post has inspired me with its enthusiasm to write an answer.

 

The development did not stopped, the forum simply does not show it. The place to be visited is the bugtracker: there are some bug reports closed recently. For example, Polish translation was added around 15th of March 2009. It says "committed to SVN in revision 1097" in the related bugtracker issue #562. Game revision 1097 can be obtained via SVN (Subversion) software by anyone. Instructions on how to do it are described in "Compilation instructions" topic in "UFO2000 I'd like to help" branch of this forum. As far as I understand, subsequent game revision will be released as stable version everywhere only after annoying CRC errors will have been resolved.

 

So, I suggest to visit mentioned resources for everyone who wants to learn C for pushing the game further.

 

The bugtracker: http://ufo2000.xcomufo.com/mantis/.

 

"Compilation instructions" topic: http://www.xcomufo.com/forums/index.php?showtopic=8144.

Edited by Fomka
Link to comment
Share on other sites

Accipitre's post has inspired me with its enthusiasm to write an answer.

 

The development did not stopped, the forum simply does not show it. The place to be visited is the bugtracker: there are some bug reports closed recently. For example, Polish translation was added around 15th of March 2009. It says "committed to SVN in revision 1097" in the related bugtracker issue #562. Game revision 1097 can be obtained via SVN (Subversion) software by anyone. Instructions on how to do it are described in "Compilation instructions" topic in "UFO2000 I'd like to help" branch of this forum.

We used to have weekly beta releases some time ago (announced in this thread) to get the latest features and updates easily accessible for everyone. Too bad that nobody has time to do this anymore :(

 

As far as I understand, subsequent game revision will be released as stable version everywhere only after annoying CRC errors will have been resolved.

This may be a bit difficult to fix because it is most likely the result of multiple independent bugs. The fundamental problem is the use of floating point calculations which may have slightly different precision on different machines, this is responsible for some share of the crc error problems. Of course there are most likely other bugs (panic implementation is one of the suspects). I'm not sure if anybody has enough time to invest in hunting down all the bugs related to this crc errors problem.

 

The other things which would be nice to get fixed are: get rid of hawknl and dumbogg dependencies. But this is more important for linux.

 

So, I suggest to visit mentioned resources for everyone who wants to learn C for pushing the game further.

 

The bugtracker: http://ufo2000.xcomufo.com/mantis/.

 

"Compilation instructions" topic: http://www.xcomufo.com/forums/index.php?showtopic=8144.

Link to comment
Share on other sites

  • 4 weeks later...
Player 1: Has a unit who is panicking, end his turn, unit is still panicking.

During Player2's turn, player 1 uses TAB to cycle through his units, when he cycles back to his panicking unit, player 2 is ejected from the game, and a new turn starts for player 1. This causes lots of fun sync errors upon reconnection.

 

The message "Joe Smith has panicked" is relayed each time the unit is cycled to, and the turn count goes up.

 

It seems like it would be a simple fix, as somewhere, the Turn end sequence is connected to that panic message.

 

For the news : This bug just got fixed in 1104. It works for hotseat, multiplayer is harder to verify but it should work the same. As I said : One down.

Link to comment
Share on other sites

For the news : This bug just got fixed in 1104. It works for hotseat, multiplayer is harder to verify but it should work the same. As I said : One down.

Nice. A good catch. Makes sense to release an updated build. The sooner people get it in their hands, the better :)

 

Probably it would be also good to set 'Dawn City Beta' as a default terrain choice instead of 'Moonbase'.

Link to comment
Share on other sites

  • 2 months later...
I cannot find the answer using the search function, but is it normal that my men cannot open doors? Also having a few problems loading guns, sometimes the gun just won't take the ammo, and for some reason, some soldiers do not have ammo loaded into their gun from the start.
Link to comment
Share on other sites

I cannot find the answer using the search function, but is it normal that my men cannot open doors? Also having a few problems loading guns, sometimes the gun just won't take the ammo, and for some reason, some soldiers do not have ammo loaded into their gun from the start.

 

Doors use TFTD system, to open them you need to face the doors and right click.

 

You need to load the guns on the inventory screen before starting the mission. The problems loading clips should be related to using the wrong type of ammo for that gun.

Link to comment
Share on other sites

You need to load the guns on the inventory screen before starting the mission. The problems loading clips should be related to using the wrong type of ammo for that gun.

 

I've had a problem reloading the python pistol in the inventory screen pre-mission. Apparently, if your pistol is equipped in your hand and your offhand is holding something else, you can't reload it. You need your other hand free in order to add the clip. That may be the problem in your case.

Link to comment
Share on other sites

  • 4 months later...
  • 4 months later...

A volunteer to build ufo2000 beta releases for windows is wanted :) Preferably beta releases should be done on a weekly basis (whenever we have something committed to SVN of course). We don't have much in SVN compared to 0.9.1105 release, but there are some fixes and improvements nonetheless:

------------------------------------------------------------------------
r1114 | ssvb | 2010-04-15 12:00:12 +0300 (Thu, 15 Apr 2010) | 4 lines

Fix for issue #593: misspelled GAUGE and MISSILE in Ufo2k sets

From: Fomka
------------------------------------------------------------------------
r1113 | ssvb | 2010-04-15 11:52:16 +0300 (Thu, 15 Apr 2010) | 4 lines

Display enemy's points feature, fixes issue #571

From: Fomka
------------------------------------------------------------------------
r1112 | ssvb | 2010-03-17 17:32:18 +0200 (Wed, 17 Mar 2010) | 6 lines

Finnish translation update (shorter text messages)

Fixes issue #0000592

From: Tuomas Lähteenmäki
------------------------------------------------------------------------
r1111 | ssvb | 2010-03-08 00:26:22 +0200 (Mon, 08 Mar 2010) | 3 lines

Fixed a small typo '% d' -> '%d' in the newly added Finnish translation
------------------------------------------------------------------------
r1110 | ssvb | 2010-03-07 20:31:17 +0200 (Sun, 07 Mar 2010) | 1 line

Fixed skin related use of uninitialized data
------------------------------------------------------------------------
r1109 | ssvb | 2010-03-07 17:05:55 +0200 (Sun, 07 Mar 2010) | 6 lines

Opened and re-saved 'smg_clip.png' and 'smg_f.png' images in gimp

Looks like these files were not completely correct and resulted
in the following warnings showing up when loading the game:
libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk
------------------------------------------------------------------------
r1108 | ssvb | 2010-03-07 12:52:56 +0200 (Sun, 07 Mar 2010) | 4 lines

Finnish language file for ufo2000

From: Tuomas Lähteenmäki
------------------------------------------------------------------------
r1107 | ssvb | 2009-11-15 04:27:21 +0200 (Sun, 15 Nov 2009) | 5 lines

Fix for swapped red and blue colors in PNG images for big endian systems

Unlike previous attempts, this fix now also has been tested on real
big endian hardware.
------------------------------------------------------------------------
r1106 | ssvb | 2009-11-14 22:19:29 +0200 (Sat, 14 Nov 2009) | 5 lines

Fix for buffer overflow bug

The problem was reported in
http://www.xcomufo.com/forums/index.php?showtopic=242029311

Link to comment
Share on other sites

A volunteer to build ufo2000 beta releases for windows is wanted :) ?Preferably beta releases should be done on a weekly basis (whenever we have something committed to SVN of course).

I'm able to build beta releases once a week, sign me in! :) Where should I send files?

Link to comment
Share on other sites

Serge did not answer where to upload a release... But I'm anxious to do it, so I've uploaded Windows installer on free service, http://rapidshare.com/files/376681681/ufo2...4-beta.exe.html. It looks suspicious (an executable in the internet), I know.

 

It was made with "make win32-beta-installer", but manually. Let me explain.

 

There is a problem with svn command line client on Windows 7: svn commands from inside the makefile throws error. The error says "svn: Can't determine the user's config path". If I execute the same commands manually from a command line they run fine. So I've ran all commands in such manner.

 

 

I'm investigating this problem and appreciate any help.

Edited by Fomka
Link to comment
Share on other sites

  • 3 weeks later...
Serge did not answer where to upload a release...

Just uploading it anywhere is fine :) You have a community of ufo2000 players at 7kplay.net and it would be really helpful if you also could take care of building up to date win32 binaries. If network bandwidth is an issue, I think we can try to mirror this stuff somewhere.

 

The only remaining thing is to provide the links from ufo2000.sf.net page to the needed place.

Link to comment
Share on other sites

Hi Serge

The .1114 version shows results of its matches as they were played with .1105 ( http://ufo2000.xcomufo.com/results.php ). I think something should be done about that because players with 1105 and 1114 can start a match at the moment (it is corrupted just after version are compared). Is it server related or Fomka should have done something while preparing the installer?

Edited by Intri
Link to comment
Share on other sites

Hi Serge

The .1114 version shows results of its matches as they were played with .1105 ( http://ufo2000.xcomufo.com/results.php ). I think something should be done about that because players with 1105 and 1114 can start a match at the moment (it is corrupted just after version are compared). Is it server related or Fomka should have done something while preparing the installer?

It happens like this because 1105 and 1114 are not considered incompatible by the game. The minimal compatible version is specified in 'src/version.h' via UFO_REVISION_NUMBER constant. The matches are also reported as played with this UFO_REVISION_NUMBER version. On the other hand, faults statistics is tracked based on real version.

Link to comment
Share on other sites

By the way, I did some changes to remove HawkNL dependency for the linux version of the game (it just uses BSD sockets for the game client now). The changes are available in "no-hawknl" branch here: http://github.com/ssvb/ufo2000/commits/no-hawknl

Downloading this stuff as a tar.gz or zip source archive is also possible using http://github.com/ssvb/ufo2000/archives/no-hawknl link.

 

Testing is appreciated. If no problems are found/reported, I will commit it to SVN in a few days.

Edited by Serge
Link to comment
Share on other sites

... players with 1105 and 1114 can start a match at the moment (it is corrupted just after version are compared).

I've started two matches with my 1114 against some guy with his 1105, the match were not corrupted. I've also tested that again with myself, no corruption. The only difference is in that 1114 user can see his opponent squad points, while the latter can not. I see no problem in that now, when Serge explained where is version check condition is located.

 

By the way, I did some changes to remove HawkNL dependency for the linux version of the game (it just uses BSD sockets for the game client now). ...

Testing is appreciated. If no problems are found/reported, I will commit it to SVN in a few days.

I've compiled that sources on Linux and Windows, played a game on official server (match number 13767), found no new bugs.

 

I wonder, what is the version of the server and under what OS does it work?

Edited by Fomka
Link to comment
Share on other sites

... players with 1105 and 1114 can start a match at the moment (it is corrupted just after version are compared).

I've started two matches with my 1114 against some guy with his 1105, the match were not corrupted. I've also tested that again with myself, no corruption. The only difference is in that 1114 user can see his opponent squad points, while the latter can not. I see no problem in that now, when Serge explained where is version check condition is located.

It may be the result of this fix: http://github.com/ssvb/ufo2000/commit/87ad...801decd89b85d48

When playing 1114 vs. 1105 versions, this weapon set may become disabled because it differs for the players. Minimal compatible version number can be bumped in order to enforce/encourage upgrade

 

I've compiled that sources on Linux and Windows, played a game on official server (match number 13767), found no new bugs.

Thanks for testing. I have committed these changes to SVN.

 

I guess it should be enough for the next beta. Introducing improvements in small steps and making frequent releases can ensure that any possible regressions can be caught early enough.

 

I wonder, what is the version of the server and under what OS does it work?

The version of the server is quite old, but this does not make any difference because network protocol did not change for ages. It runs on a linux VPS server, which was kindly provided to ufo2000 project by current xcomufo.com admins (stewart, mindstormmaster). BTW, now I'm trying to setup crossmingw, wine and nsis there to build win32 version of ufo2000 using all this stuff. If this actually works, then making win32 releases can be automated.

Link to comment
Share on other sites

BTW, now I'm trying to setup crossmingw, wine and nsis there to build win32 version of ufo2000 using all this stuff. If this actually works, then making win32 releases can be automated.

I never used revision control programs personally, but with my experience with Wine, it never proves reliable if things go out of date. Perhaps I should avoid updating periodically to Wine releases though. ;) Hope it doesn't do that to you down the line.. other than that, sure would be useful and less time consuming. :)

Link to comment
Share on other sites

I never used revision control programs personally, but with my experience with Wine, it never proves reliable if things go out of date. Perhaps I should avoid updating periodically to Wine releases though. ;) Hope it doesn't do that to you down the line.. other than that, sure would be useful and less time consuming. :)

Well, I considered to use wine for running makensis tool (nsis installer generation), but looks like a native version of nsis is also available for linux and it seems to work (the generated installers are still targeting windows). there are still problems with crash reporting functionality ('src/exchndl') and libbfd on recent versions of mingw. It would be really helpful if some windows user who has mingw installed (so that ufo2000 builds there) could try to type 'gcc -v' and 'as -v' in console and paste the results here. I would like to know the exact versions of these tools.

 

Btw, I also tried to upgrade the system on ufo2000.xcomfo.com but something went wrong. So it is down at the moment, I'm sorry about that :(

Link to comment
Share on other sites

It would be really helpful if some windows user who has mingw installed (so that ufo2000 builds there) could try to type 'gcc -v' and 'as -v' in console and paste the results here. I would like to know the exact versions of these tools. :(

 

I'm such user. Here are the results:

 

 

Compiler

 

C:\...>gcc -v
Reading specs from C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-
exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)

 

Assembler

 

C:\...>as --version
GNU assembler 2.13.90 20030111
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

C:\...>as -v
GNU assembler version 2.13.90 (mingw32) using BFD version 2.13.90 20030111

Link to comment
Share on other sites

Long story short.

 

1. Here is a new branch with ufo2000 makefile tweaks: http://github.com/ssvb/ufo2000/commits/makefile-tweaks (also downloadable via 'download source' link)

 

All the changes are described in git commit comment messages. Basically these changes allow building windows binaries and installers on linux system and also contain some general fixes and cleanups. I'm going to commit all this stuff to SVN in a few days unless somebody compains.

 

2. Here is a new experimental release of ufo2000:

- http://ufo2000.xcomufo.com/downloads/ufo20....1119M-beta.exe (installer)

- http://ufo2000.xcomufo.com/downloads/ufo2000-0.9.1119M.zip (just a zip archive)

- http://ufo2000.xcomufo.com/downloads/ufo20...19M-src.tar.bz2 (sources)

 

This stuff was compiled on a linux server with mingw crosscompiler. Because the compiler is a bit different than the one typically used in windows, theoretically any bugs or regressions could be related to this. Also we need to make sure that the installer was built correctly. Testing is very much appreciated. If these binaries prove to be usable, I'll set up automatic building of win32 beta installers on each SVN commit and this should make everything much easier :)

Link to comment
Share on other sites

Long story short.

 

1. Here is a new branch with ufo2000 makefile tweaks: http://github.com/ssvb/ufo2000/commits/makefile-tweaks (also downloadable via 'download source' link)

 

All the changes are described in git commit comment messages. Basically these changes allow building windows binaries and installers on linux system and also contain some general fixes and cleanups. I'm going to commit all this stuff to SVN in a few days unless somebody compains.

 

 

I've tried to build windows binaries from Ubuntu. So I've included mingw libraries in the downloaded sources and ran "make binary-zip" command. An error occurred during build process, after successful build of targets "all" and "server".

 

On Ubuntu

svn delete --force ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: [binary-zip] Error 1 (ignored)
 svn export --native-eol "CRLF" . ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: *** [binary-zip] Error 1

 

 

On Windows

svn delete --force ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: [binary-zip] Error 1 (ignored)
 svn export --native-eol "CRLF" . ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: *** [binary-zip] Error 1

 

 

I made an SVN checkout of 1119M version from the trunk, replaced the makefile with the one from the new branch, ran the "make binary-zip" command again. The error vanished, a new one appeared.

 

On Ubuntu

fomka@Ubuntu-10:~/ufo2000_m_t/1119M$ make binary-zip
 svn delete --force ufo2000-0.9.1119M
 svn: 'ufo2000-0.9.1119M' does not exist
 make: [binary-zip] Error 1 (ignored)
 svn export --native-eol "CRLF" . ufo2000-0.9.1119M
 Export complete.
 rm -R ufo2000-0.9.1119M/src
 rm -R ufo2000-0.9.1119M/datfile
 rm -R ufo2000-0.9.1119M/doxygen
 rm ufo2000-0.9.1119M/makefile* ufo2000-0.9.1119M/Seccast*
 rm ufo2000-0.9.1119M/*.rc ufo2000-0.9.1119M/*.h
 cp ufo2000.exe ufo2000-srv.exe ufo2000-0.9.1119M
 cp: cannot stat `ufo2000.exe': No such file or directory
 cp: cannot stat `ufo2000-srv.exe': No such file or directory
 make: *** [binary-zip] Error 1

 

On Windows

svn delete --force ufo2000-0.9.1119M
 svn export --native-eol "CRLF" . ufo2000-0.9.1119M
 Export complete.
 rm -R ufo2000-0.9.1119M/src
 rm -R ufo2000-0.9.1119M/datfile
 rm -R ufo2000-0.9.1119M/doxygen
 rm ufo2000-0.9.1119M/makefile* ufo2000-0.9.1119M/Seccast*
 rm ufo2000-0.9.1119M/*.rc ufo2000-0.9.1119M/*.h
 cp ufo2000.exe ufo2000-srv.exe ufo2000-0.9.1119M
 7z a -tzip -mx -r ufo2000-0.9.1119M.zip ufo2000-0.9.1119M
 make: 7z: Command not found
 make: *** [binary-zip] Error 127

 

I see that makefile targets "all" and "server" do not produce "ufo2000.exe" and "ufo2000-srv.exe" executables for Windows on Linux and do not produce "ufo2000" and "ufo2000-srv" executables for Linux on Windows.

 

So I've made a conclusion, that building of target "binary-zip" works only on Windows with 7zip archiver installed.

 

I wonder, how did you build "ufo2000.exe" under Linux and where is the link in the makefile to mingw crosscompiler, which is mentioned below?

 

2. Here is a new experimental release of ufo2000:

- http://ufo2000.xcomufo.com/downloads/ufo20....1119M-beta.exe (installer)

- http://ufo2000.xcomufo.com/downloads/ufo2000-0.9.1119M.zip (just a zip archive)

- http://ufo2000.xcomufo.com/downloads/ufo20...19M-src.tar.bz2 (sources)

 

This stuff was compiled on a linux server with mingw crosscompiler. Because the compiler is a bit different than the one typically used in windows, theoretically any bugs or regressions could be related to this. Also we need to make sure that the installer was built correctly. Testing is very much appreciated. If these binaries prove to be usable, I'll set up automatic building of win32 beta installers on each SVN commit and this should make everything much easier :)

 

 

The installer works fine, I've tested it on Windows XP. I've played a test match with myself, match number 13793: newly installed 1119M version on Windows XP 32-bit versus 1114 version on Windows 7 64-bit.

Edited by Fomka
Link to comment
Share on other sites

The fundamental problem of purely make based build is that it's difficult or impossible to detect beforehand that all the dependencies are properly installed (tools and the libraries). If something is missing, we get quite an unintuitive error messages. :( This can be improved, but it can make build system somewhat more complex to use (depend on autotools, cmake, scons or some scripting languages). Actually 'make tools' builds a standalone lua interpreter, which can be used to automate some stuff in the makefile, but may become crosscompilation nonfriendly. So no clearly good solution yet.

 

I've tried to build windows binaries from Ubuntu. So I've included mingw libraries in the downloaded sources and ran "make binary-zip" command. An error occurred during build process, after successful build of targets "all" and "server".

 

On Ubuntu

svn delete --force ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: [binary-zip] Error 1 (ignored)
 svn export --native-eol "CRLF" . ufo2000-0.9.exported
 svn: '.' is not a working copy
 make: *** [binary-zip] Error 1

 

Running from SVN working copy is required for building binary packages and installers (I tried to mention it in makefile comments, but looks like it was not clear enough). The point is that makefile tries to identify ufo2000 version number and uses SVN for this purpose. Also 'svn export' command is used to get only the needed stuff packaged without any temporary files or garbage mixed in.

 

I made an SVN checkout of 1119M version from the trunk, replaced the makefile with the one from the new branch, ran the "make binary-zip" command again. The error vanished, a new one appeared.

 

On Ubuntu

fomka@Ubuntu-10:~/ufo2000_m_t/1119M$ make binary-zip
 svn delete --force ufo2000-0.9.1119M
 svn: 'ufo2000-0.9.1119M' does not exist
 make: [binary-zip] Error 1 (ignored)
 svn export --native-eol "CRLF" . ufo2000-0.9.1119M
 Export complete.
 rm -R ufo2000-0.9.1119M/src
 rm -R ufo2000-0.9.1119M/datfile
 rm -R ufo2000-0.9.1119M/doxygen
 rm ufo2000-0.9.1119M/makefile* ufo2000-0.9.1119M/Seccast*
 rm ufo2000-0.9.1119M/*.rc ufo2000-0.9.1119M/*.h
 cp ufo2000.exe ufo2000-srv.exe ufo2000-0.9.1119M
 cp: cannot stat `ufo2000.exe': No such file or directory
 cp: cannot stat `ufo2000-srv.exe': No such file or directory
 make: *** [binary-zip] Error 1

 

It just did not find *.exe files because it tried to build linux version in this configuration, see below for more explanations.

 

On Windows
svn delete --force ufo2000-0.9.1119M
 svn export --native-eol "CRLF" . ufo2000-0.9.1119M
 Export complete.
 rm -R ufo2000-0.9.1119M/src
 rm -R ufo2000-0.9.1119M/datfile
 rm -R ufo2000-0.9.1119M/doxygen
 rm ufo2000-0.9.1119M/makefile* ufo2000-0.9.1119M/Seccast*
 rm ufo2000-0.9.1119M/*.rc ufo2000-0.9.1119M/*.h
 cp ufo2000.exe ufo2000-srv.exe ufo2000-0.9.1119M
 7z a -tzip -mx -r ufo2000-0.9.1119M.zip ufo2000-0.9.1119M
 make: 7z: Command not found
 make: *** [binary-zip] Error 127

 

So I've made a conclusion, that building of target "binary-zip" works only on Windows with 7zip archiver installed.

 

Yes, 7zip archiver is required because it provides absolutely best compression for zip format (I guess it's the least problematic format for windows users) and also it is available for all systems (p7zip package in linux) and has unified command line interface.

 

I wonder, how did you build "ufo2000.exe" under Linux and where is the link in the makefile to mingw crosscompiler, which is mentioned below?

 

It is described in one of the commit comments: http://github.com/ssvb/ufo2000/commit/e90f...15a7db8161d42d1

 

You need to define CXX variable to contain the name of the c++ compiler executable. For crossmingw it would be i386-mingw32-g++, i586-mingw32msvc-g++, i686-pc-mingw32-g++ or something similar depending on how mingw was configured and built.

 

Not defining CXX variable will always try to build a native version of the game for the operating system where it is being built.

 

There is another pitfall with libbfd, it's a bit tricky and may require adding libbfd.a and some of the headers to the 'mingw-libs' directory (these can be taken from MinGW 3.1.0-1). The problem is that newer versions of mingw don't bundle a usable libbfd.a anymore.

 

Hope this helps, feel free to ask more questions if any clarifications are needed :)

Edited by Serge
Link to comment
Share on other sites

Fomka, was my last comment helpful? Have you managed to compile ufo2000 win32 binary in linux? I mostly wonder if these proposed makefile changes work fine and do not cause regressions. If they are ok, then it makes sense to push them to SVN repository and make a new official beta release :)

 

PS. Maybe it is better to start using a mailing list for such development related discussions?

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...