Unable to Compile Game With Muton's Utility

[Edi]

I've done everything according to instructions so far:
- msysGit
- TortoiseGit
- downloaded the source (master branch)
- checked that it's up to date
- have downloaded the all in one pack (MinGW, NSIS, etc)

But when I run Muton's utility, the compilation starts okay, but crashes during ufomodel, always in the exact same spot:

Code: [Select]

---- filesystem initialization -----

Adding game dir: /usr/local/games/ufoai/base

Adding game dir: ./base

Adding game dir: C:\Documents and Settings\Esko\Application Data\UFOAI/2.4-dev/base

using ./base for writing

- model 'models/weapons/vhs/vhs.md2'

  \ - # meshes '1', # frames '1'

  \ - writing to file 'models/weapons/vhs/vhs.mdx'

./ufomodel.exe -mdx -overwrite -v -s 0.2 -f models/objects/vegi/md3-grass/grass.md3
./ufomodel.exe -mdx -overwrite -v -s 0.2 -f models/objects/vegi/md3-palm/blad.md3
---- ufomodel 0.2 ----

---- endianness initialization -----

found little endian system



---- filesystem initialization -----

Adding game dir: /usr/local/games/ufoai/base

Adding game dir: ./base

Adding game dir: C:\Documents and Settings\Esko\Application Data\UFOAI/2.4-dev/base

using ./base for writing

- model 'models/objects/vegi/md3-palm/blad.md3'

  \ - could not load skin 'palm.png'

make: *** [base/models/objects/vegi/md3-palm/blad.mdx] Error 5
make: *** Waiting for unfinished jobs....
---- ufomodel 0.2 ----

---- endianness initialization -----

found little endian system



---- filesystem initialization -----

Adding game dir: /usr/local/games/ufoai/base

Adding game dir: ./base

Adding game dir: C:\Documents and Settings\Esko\Application Data\UFOAI/2.4-dev/base

using ./base for writing

- model 'models/objects/vegi/md3-grass/grass.md3'

  \ - could not load skin 'grass.png'

make: *** [base/models/objects/vegi/md3-grass/grass.mdx] Error 5
---- ufomodel 0.2 ----

---- endianness initialization -----

found little endian system



---- filesystem initialization -----

Adding game dir: /usr/local/games/ufoai/base

Adding game dir: ./base

Adding game dir: C:\Documents and Settings\Esko\Application Data\UFOAI/2.4-dev/base

using ./base for writing

- model 'models/objects/vegi/md3-canopy/stam.md3'

  \ - could not load skin 'canopy.png'

make: *** [base/models/objects/vegi/md3-canopy/stam.mdx] Error 5
---- ufomodel 0.2 ----

---- endianness initialization -----

found little endian system



---- filesystem initialization -----

Adding game dir: /usr/local/games/ufoai/base

Adding game dir: ./base

Adding game dir: C:\Documents and Settings\Esko\Application Data\UFOAI/2.4-dev/base

using ./base for writing

- model 'models/objects/vegi/md3-canopy/blad.md3'

  \ - could not load skin 'canopy.png'

make: *** [base/models/objects/vegi/md3-canopy/blad.mdx] Error 5
logout

Endtime: 2011.05.15 00:43:56 1
Error 51
Error during ufomodel

System specs:

WinXP Pro SP3, Intel Core2Duo E6600, 3 GB RAM, graphics card Asus EAH5750 Formula (ATI Radeon HD5750).

When I try to read the debug info on the error windows I get, there are some references to AMD type CPU stuff, but I don't what, how or why. I'm using Muton's utility on the default settings so it should have no trouble picking up on what kind of CPU I have.

Furthermore, it builds all the models before those four just fine, but with each of these, it gives me the "could not load skin [filename]" error, gives ufofmodel error code 5.

And unless I'm much mistaken, these particular skins and models are the infamous palm fronds, that have been fixed and reverted at least a dozen times in the past couple of years.

Can anyone shed more light on this? I've attached the full build log from Muton's utility.

[Edi]

The problem may be related to this (see comments from today).

[MCR]

I removed the .md3s from master.
Your problem should be fixed now.

Please try again & report here. 

[Edi]

Compiling doesn't crash on model build stage anymore and is well on its way to building the maps, so it works now. The textures and objects themselves looked quite fine, so if they can be added in a way that does not prevent compiling, I'm all for it.

Thanks.