make_UfoAI_win32 (all in one win32 build script)

[lostdave]

I guess this is the best place to mention it - the server hosting the Code::Blocks, MinGW, etc package (http://www.meduniwien.ac.at/user/michael.zellhofer/ufoai/UfoAIallIN1.exe) isn't currently there (DNS failure by the looks). Anyone know/have an alternative?

[Muton]

retry?

[lostdave]

Yeah, it's back up now.

[Muton]

== 2010.07.03 == 0.9.0 =====================================

Two big things have been added
1) a map download >like< map_get.py
The main difference is that you don't download maps that aren't useful for your build
The serverApp run once in an hour that once a day
I do a md5hash on the original *.map files to determine if a map should be downloaded or compiled than do just download
The server log store hash sums of *.map files and the path of them
If you want to download a map (*.bsp)
the script hash your *.map file and check it against the serverlog *.map hash
If both match, the download of this *.bsp will start
If the download failed or the hash is unequal, you will build the map using ufo2map

2) A routine to build an update than a full installer of UfoAI
It will build a update of your last full build (you need to enable this function first)
A new switch "diff" was added into the GUI (It requiers the "Installer" and "7z" switch too, to work)
First time you build a full installer.
Next time you call it, you will build (differential) updates
A new file to hold all infos was added too, inst_last_build.md5 (release 2.4) and inst_last_build_2.3.md5 (release 2.3)
If you delete this file you will start from the beginning (there is no GUI switch to do this)
The update include all dlls and executables, only files inside of pk3's are removed from the installer if they are the same (the pk3 files are than updated during installation)
This way you can switch between a release or debug build, even include radiant once and next time without radiant.

added

• instance check of make_UfoAI_win32.exe (only on instance is allowed)
• some Hardware infos to log (CPU RAM OS)
• map download
• Installer update routine

bugs

• Internal Search
• GUI

[MCR]

Anyone tried to compile current trunk & then actually tried to get on the battlescape, or is it really just me having total crashes with the latest hundreds of revisions ?

It seems to be some Windoof-specific problem ?!

Would be nice if someone could try a skirmish game with current trunk...

[balasar]

I totaly can't run the game.

[MCR]

I totaly can't run the game.

I am feeling with you, but afair your problem is hunting you already a quite long time. Or did you get it to run after you last posted problems ?
Which is the latest version you got running ?

[Muton]

me too

GL_VENDOR: NVIDIA Corporation2010/07/06 20:31:10 GL_RENDERER: GeForce 7050 PV / nForce 630a/PCI/SSE2/3DNOW!2010/07/06 .....
GL_NV_texgen_reflection GL_NV_texture_barri

ufo.exe just hang

[shaunc311]

Just tried building from trunk yesterday for the first time and couldn't get it to load.  I figured it was something I was doing incorrectly (still could be) since 2.3 did build and run correctly.  My ufoconsole.log is identical to the one above.  The progress bar on the main loading screen never progressed.

Windows XP

[MCR]

Somehow I am glad, because I am having this error since about 300+ revisions & I was beginning to feel quite alone with it already.
A bugtracker-item was already posted by me some time ago, after making a clean-up, a completely fresh checkout & after a clean compile of the maps did not change my situation.

Hope somebody finds a solution for this problem soon...

To all the other testers here: Thanks for helping me find out that I am not alone with this

[MCR]

Here the bugtracker item if someone wants to comment there:

https://sourceforge.net/tracker/?func=detail&aid=3025415&group_id=157793&atid=805242

[shaunc311]

Don't know why, but if you go into src/client/renderer/r_main.c and comment out these lines, it'll load:

Code: [Select]

Com_Printf("using GL_ARB_framebuffer_object\n");
Com_Printf("max draw buffers: %i\n", r_config.maxDrawBuffers);
Com_Printf("max render buffer size: %i\n", r_config.maxRenderbufferSize);
Com_Printf("max color attachments: %i\n", r_config.maxColorAttachments);

At least, it loaded for me.  My ufoconsole.log file ended with "max render b" and that let me to the printout error.  I hope it helps you too.  Technically, I should probably find out why but codeblocks debugger isn't stopping at that break point.  Gonna try eclipse now.


Update:  Ok, now I'm confused.  I tried figuring out why the lines were causing it to hang and put the lines back in and everything is still working.  I'll let you know if it happens again.

[MCR]

Look how far I get:

[MCR]

@Muton: Could it be that these crashes have something to do with the latest update of your script, because Duke got latest trunk running under Windows (Vista) & also tested the battlescape !?

Timing of my first crashes would fit to that theory somehow...

[Muton]

The script dont do any magic
I just analyze ufo.workspace and run codeblocks using *.cbp files

I think the cb project file is missing something
or whatever
../../src/client/menu/m_sound.c/h
has been added lately .....


Edit:
Its a 32bit problem
No problem on XPx64
but no run under XPx32