Win32 Development Binary Installer Links

[Mattn]

type setdeveloper DEBUG_COMMAND before you click that button (and maybe set developer cvar to 0 after you clicked it)

[Muton]

type setdeveloper DEBUG_COMMAND before you click that button (and maybe set developer cvar to 0 after you clicked it)

set developer DEBUG_COMMAND == no output
set developer cvar 0 == flag can only be u or s

if i press the "firebutton" i can't zoom into the map using wheel
can't select an alien or teammate
It seams the popup is not only hidden
'couse im unable to select some firemode blind

yes its a debug build


under build 23162
its the same but i dont need to press ESC to release the cursor

[bayo]

Hello. I commit something, and it should fix your problem (r23172). I think the problem is the firemode window is displayed outside the screen. Plus some problems (also fixed, r23161, r23159) make the firemode a little hard to use.

This revision is not about that, but it fix in the same time uninitialized vars also used to set the dropdown popup position.

[Muton]

Yes fixed
thx

ufoai_2.3-dev_23205_diff_win32.exe will update any full bild (Destructavator) after 22950
incl w2k support
excl src and mapeditingtools
NO debug build i686 optimized

ufoai_2.3-dev_23205_diff_win32.exe 9,54 MB (yes 10MB )
4shared
Mediafire
Rapidshare
FileFront

*edit

ufoai_2.3-dev_23245_diff_win32.exe
4shared
Mediafire
Rapidshare
FileFront

[XB7]

I downloaded the  R22955  binary install from odie's post.  I am really impressed with the improvements to this game.

So far the game his playable for me except when I enter tactical mode, the game drops to the desktop.  Can someone point me to the latest dev binary install that has everything I need to run the game?

[XB7]

Sorry for the false alarm.  That was a african map that was bombing out - not the game itself.  Since I don't have the latest version running, it's probably already fixed.

[geever]

Tropic_river map assembly has problems...

-geever

[Destructavator]

I'm back.

I'm also building a new binary, I know it's been a while.

Also, FYI ufo2map seems to be fixed and working without crashing now, at least on my computer.

I'll upload the new build later today, if a quick test of running the game works.

[Destructavator]

Uh-oh, now I just found out that ufo.exe can't be created in the compile process, using codeblocks.

Either I'm doing something stupid, or I'll have to wait until a fix is committed to the SVN trunk.

(Yes, I know this sometimes happens with the trunk.)

(build log from codeblocks attached, revision 23348)



[attachment deleted by admin]

[geever]

It must be C::B project file as it compiles and runs fine on linux...

-geever

[Muton]

Linking executable: ..\..\ufo.exe
.objs\client\src\client\renderer\r_model.o:r_model.c:(.text+0x40a): undefined reference to `strcasestr'

V:\MinGW\ufoai\src\client\renderer\r_model.c
line 160

if (strcasestr(mod->name, ".obj")) {

http://www.koders.com/c/fid1740146D1762BACEF195478A80AC725EA2BB64E3.aspx?s=md5
> c-strcasestr.c -- case insensitive substring search in C locale
no c-strcasestr.h found



*Edit

I've modified compile_maps.bat
to speed up mapgeneration dramaticaly

first why and how
We know ufo2map own a -onlynewer switch
but sometimes we can end up with a map "missmatch" (
ufo2map think the bsp is up2date
while the bsp is'nt
)
This is caused by the routine ufo2map uses to determine *.bsp actuality
Its just a timestamp compare between *.map and *.bsp
if *.bsp is newer than *.map then *.bsp is up2date

And thats the "problem"
If you compile maps while a dev releases a new map
and lets imagine this new map is the last map that will be compiled
than you end up with a bsp accurate for you current build
But on the next build
svn download those new map and ufo2map compare both timestamps
and think the bsp is up2date 'couse your bsp was build after the new svn release

So how to prevent this?!
I'm using a hashsum for a while and its working quite well
I store a md5 hashsum for the last full mapcompilation
after a SVN update i generate a new hashsum for *.map and *.footsteps
and compare both against each other
Those files that have been changed will be deleted (*.bsp) and ufo2map is called with -onlynewer

Here we go
download the zip and extract it into your ufoai scr folder
it must be stored at contrib\scripts
The script depends on fsum.exe and diff.exe
fsum.exe is free slavasoft
and diff.exe is a c++ project of mine (source is included [I know i'm not an expert ])

cangelog:
.) check for NT system
.) check if you relay want to call the script witout a parameter
.) add arg /?
.) add /onlynewer (for the hashsum)
.) case insesitive argv (windows style)
.) complete error handling
.) diskspace check
.) sucess or error message if you use /shutdown (during next login)
.) complete new code for compilemap
.) counter for maps that must be compiled

[attachment deleted by admin]

[BTAxis]

I think it's a good idea, but I really don't like how you added the need for third party software. It's getting to be that whatever you want to do requires you do download additional tools, and that's Bad(tm).

[Muton]

fsum is the fastest, smallest and universal tool for hashsums
but the gnu coreutils md5sum http://gnuwin32.sourceforge.net/packages/coreutils.htm
can be used

[BTAxis]

The problem isn't the performance of the tools, but the need to download them in itself. It's not my call, but I'm against this change as long as the batch file can't be used out of the box.

[Destructavator]

I glanced at that page in that link - it looks like the tools are cross-platform and have a compatible license, I'd imagine they could be combined with the customized uforadiant code or included with it in the package somehow.  I don't have the time or expertise to do that and submit a patch myself, but I'm guessing Muton might...