Madden NFL 08 Decompression Utility!!!

[1312qohelet]

So I've got a question: Is this helpful for trying to import 3D models?

Somewhat, sort of. There are tons of compressed files that nobody has ever decompressed to see what is there.

However, without a method to import or export triangle (face/polygon/mesh/surface) data, there is no way to do much of anything with 3D models.

What about the MORE utility?
I've read conversations that discuss using it for 3D model work.

[trey31]

So I've got a question: Is this helpful for trying to import 3D models?

Somewhat, sort of. There are tons of compressed files that nobody has ever decompressed to see what is there.

However, without a method to import or export triangle (face/polygon/mesh/surface) data, there is no way to do much of anything with 3D models.

What about the MORE utility?
I've read conversations that discuss using it for 3D model work.

It doesn't import or export the 3D model triangle data. Just the vertice and texture vertices data.

[1312qohelet]

Somewhat, sort of. There are tons of compressed files that nobody has ever decompressed to see what is there.

However, without a method to import or export triangle (face/polygon/mesh/surface) data, there is no way to do much of anything with 3D models.

What about the MORE utility?
I've read conversations that discuss using it for 3D model work.

It doesn't import or export the 3D model triangle data. Just the vertice and texture vertices data.

Understood.
Sting's still in developing MORE, am I correct?
Do you know if importing triangle data a "goal" for the MORE?

[trey31]

What about the MORE utility?
I've read conversations that discuss using it for 3D model work.

It doesn't import or export the 3D model triangle data. Just the vertice and texture vertices data.

Understood.
Sting's still in developing MORE, am I correct?
Do you know if importing triangle data a "goal" for the MORE?

I hope so. I don't know how to convert the tmdl binary data into anything moddable. So MoRE is the only way I know of even viewing it.

[mee]

This is one of the greatest utilities of all time.
Decompresses whole dats at once. Wow. Thanks calhoupe and ALUIGI.
I just wish it would repost the dat file, not the individual files..

[elguapo]

There is a feature to repackage the dat file but only if the files are the same size. Otherwise a new script would need to be written to repackage the decompressed files.

I outlined an alternative which isn't difficult to do.
http://www.footballidiot.com/forum/viewtopic.php?f=13&t=20494&p=111273#p111273

[elguapo]

Came across another problem when inserting the decompressed files back into the DAT. When using Stingray68's Dex v1 editor to replace the mmaps the editor saves the decompressed file as compressed. This may be a bug in the Dex editor since all files are now decompressed but the DAT file is designed for compressed files.

So what I did is use one of the DAT files (believe it was the MOVIE.DAT) that does not allow compressed files, expanded it to the desired slots and imported the decompressed files and that solved the issue.

[StingRay68]

Came across another problem when inserting the decompressed files back into the DAT. When using Stingray68's Dex v1 editor to replace the mmaps the editor saves the decompressed file as compressed. This may be a bug in the Dex editor since all files are now decompressed but the DAT file is designed for compressed files.

Not sure what you are trying to do...Dex is not compressing/decompressing anything.
The only time you should try to edit something with dex that is compressed is (maybe) when you are importing a dds graphic to the player/coach portraits dats. You can't import a mmap file with dex. If you are trying that with dex it's not an intended function. Thats something you want to use JD's DFR for.
Any dat can support compressed files if it has a comp table.
If you have a dat with a comp table and no compressed files, just delete the comp table and its padding with a hex editor and you should be good to go.

[elguapo]

Maybe you can try so you can see what I'm talking about. Decompress the files using this thread's method. Use the command scripts i provided to rename them to MMAP files and then use DBR4 to insert them back in the DAT file. Replace a few mmaps using DDS files save the DAT and open it with DFR4, notice how the actual size is listed but in the compress size section it still has the decompressed size.

Let me know if you were able to duplicate the results.

[StingRay68]

notice how the actual size is listed but in the compress size section it still has the decompressed size.

As long as there is a comp table it will list every file whether it is compressed or not. You will see a 5 in each entry if the file is compressed, and 0 if it is not. It will always have the decompressed size. (Look at the comp table in a hex editor as well)
Even if you have 1 file that is compressed in a dat, you need to have the comp table, and every file will be listed in it.

I am using DRF 5
It will say compressed false, the comp size and decomp size should be the same. Filetype should be mmap for your example.
That is just how JD chose to display it.
As I said before, if you have NO compressed files in a dat, you can just delete the comp table and any padding with a hex editor.