make_UfoAI_win32 (all in one win32 build script)

[Muton]

That

Code: [Select]

If @OSVersion = "WIN_2000" Then
$Process_array = ProcessList(StringLeft(@ScriptName, 15))
If $Process_array[0][0] > 1 Then
MsgBox(270352, "Error 000", @CRLF & "An instance of " & @ScriptName & " is already running!" )
Exit
EndIf
Else
$Process_array = ProcessList(@ScriptName)
If $Process_array[0][0] > 1 Then
MsgBox(270352, "Error 000", @CRLF & "An instance of " & @ScriptName & " is already running!" )
Exit
EndIf
EndIf

was added @ 0.9.3

Because you are the only one with this problem
its hard 4me to debug.

Try this one
i've compiled it using autoit 3.3.6.1

[bucata]

Nope, its same error.

If its not too much bother can you just put in comment all this section... or just give me the script i will recompile myself.

[Muton]

The problem is on your side
you should find out why this problem occur.
Possibly a virus scanner who run the program internally to check the behavior ...
File emulation ....

There is a reason for this check
if you run it twice you would screw up the whole setup

The source is always extracted as soon as you start the program
its called make_UfoAI_win32.au3

[bucata]

Well something is wrong for sure.. prolly have to preinstall windows next time to fix it.
But anyway I bypassed the process check as result now IT WORKS.
Thanks a lot of your help.

[Muton]

== 2012.04.09 == 1.1.1 =====================================
You are now able to select the branch you want to build
Be careful with it because youll switch to the selected branch
and than you likely need to compile maps again



best practice if you switch often

Code: (open cmd) [Select]

md D:\UFOAIwin32BUILDenv\2.4
md D:\UFOAIwin32BUILDenv\2.5
copy /y D:\UFOAIwin32BUILDenv\make_UfoAI_win32.exe D:\UFOAIwin32BUILDenv\2.4
copy /y D:\UFOAIwin32BUILDenv\make_UfoAI_win32.exe D:\UFOAIwin32BUILDenv\2.5
md D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.4\.git
md D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.5\.git
@echo \objects\>"%tmp%\exclude.txt"
xcopy D:\UFOAIwin32BUILDenv\MinGW\ufoai\.git D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.4\.git /E /V /H /R /Y /EXCLUDE:%tmp%\exclude.txt
xcopy D:\UFOAIwin32BUILDenv\MinGW\ufoai\.git D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.4\.git /E /V /H /R /Y /EXCLUDE:%tmp%\exclude.txt
del "%tmp%\exclude.txt"
linkd D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.4\.git\objects D:\UFOAIwin32BUILDenv\MinGW\ufoai\.git\objects
linkd D:\UFOAIwin32BUILDenv\MinGW\ufoai_2.5\.git\objects D:\UFOAIwin32BUILDenv\MinGW\ufoai\.git\objects
This will hardlink
D:\UFOAIwin32BUILDenv\MinGW\ufoai\.git\objects
and save you a lot of space

start D:\UFOAIwin32BUILDenv\MinGW\msys.bat

Code: (msys.bat) [Select]

cd /ufoai_2.4
git checkout .
cd /ufoai_2.5
git checkout .

Now run D:\UFOAIwin32BUILDenv\2.4\make_UfoAI_win32.exe
point to the directories and dont forget to use ufoai_2.4 or ufoai_2.5 as the source directory

start compiling

add

• branch selector

bug

• make install directory reset to default at each start

[Muton]

== 2012.04.21 == 1.1.2 =====================================
Just a tiny bug
that lists all revision time stamps of a commit instead of only the last one


bug

• list only the last revision time stamp instead of all

[aestend]

I've been gone a while, and when I try to redownload the starter file "UfoAI_win32_build_environment_0.3.1.exe" The file size is only about 70meg and errors out. I seem to recall the file being much larger than 70meg. Is it a temporary issue? Can't wait to get back in, game seems to have improved markedly since last I was around.

[H-Hour]

Welcome back. We now offer nightly builds of the latest development version as well as our release candidate for the next stable version (2.4). Check out our downloads page under 2.4 dev for the stable release candidate and Development (latest) for a nightly build of our latest development version.

[Muton]

UfoAI_win32_build_environment_0.3.1.exe is in fact just 76MB big (and working well)
You would need the source too and than you will get your >2Gig

As already mentioned
better use the nightly builds
but (self-praise ) i prefer this one
getting updates is easier this way

[aestend]

Strange, guess i'll download it again.
I hear you on the nightly build updater thing, but in the past I enjoyed editing some of the .h files to tweak the campaign difficulty :p

Using a third browser, and when extracting, it gets to 125meg processed, and then halts, and goes no further.

Even stranger, though I had tried before, using 7zip itself to unpack worked!

[Muton]

Its an LZMA2 archive and most tools cant handle that kind of type
thats why its an sfx archive

Hope you have a fat line to the net
or you run into troubles getting the source from sourceforge
referring to http://ufoai.org/wiki/index.php/Getting_the_source#github

Would be a good idea for me to use github and than switch to sourceforge as suggested
Some work 4the weekend

[aestend]

About 1.5 MByte/s Should suffice, considering last time (SVN days) my pipe was only 1 MegaBIT lol
Doubly strange, the make tool wouldn't start, tossed me a crash error. But works fine since I restarted my lappy.

Just want to verify, I can update mingw and codeblocks from the web right? If I can without breaking anything.... should I?

[Muton]

the tool will do any update 4you
just run it and forget the rest

but you should realize that git is different from svn
if you modify the sources you run into troubles getting any source update

git will deny any update on top of your changes

[aestend]

The particular thing I liked to change in the source was the attribute scores distribution on newly created soldiers. Poked around for hours, then checked the already installed ufos.pk3, and it's in one of those files So I'm all good.

However one particular thing I'm not sure is possible, or if it would even matter. From what I understand, if I were to build while selecting processor details for my computer(i.e. sse 4.2), it would run a bit better/smoother/faster/whatever, than the catch all PentiumSSE builds. If that is the case, then what would need to be done to build as 64bit?

[Muton]

The game doesnt run faster when using sse
im using it manly for compatibility (x87 80bit <> double 64bit, rounding problem, SSE 64bit)
and 64bit is a completely different story
you need 64bit mingw and 64bit libs
which means month of work
for nearly nothing

Dont compile the game if you dont need to
no troubles on your side
Just enjoy the ride with the nightly build