March 28, 2024, 16:23
bigger smaller reset     1020px Wide width Full width Reset   * *

Gildor's Forums

  Homepage Facebook Read news on Twitter Youtube channel Github page
Welcome, Guest. Please login or register.
Did you miss your activation email?

« previous next »
Print
Author Topic: Mass Effect 2 DLC Compression  (Read 16814 times)
saltisgood
Newbie
*
Posts: 5


View Profile
« on: February 18, 2013, 18:46 »

Hello everyone, I hope I'm posting this in the correct sub-forum. Given the other content in this forum I thought that it was more fitting here than the Mass Effect one, but you can move it if necessary.

I'm one of the developers on the ME3Explorer project, and we've recently started branching out to the other games in the series. If you're not aware of what we do, then basically we create modding toolsets for the games. For ME1 & ME2 it's primarily just texture modding but ME3 has a lot more options.

We have a *.pcc reader for ME2 and it's working fine. Files can be decompressed, read in, modified, saved and correctly read in-game but the ME2 DLC files are proving to be more challenging. Given that those files appear to have the same structure as the stock game files it's somewhat frustrating to be unable to read them. Given that your tools (both the decompressor and the UE Viewer) Gildor, can correctly open them I was hoping that perhaps you or someone else on the forums might be able to help me out.

At the moment I'm using the same functions that work with the stock game files, and it's only able to read about 10% of the DLC files. Specifically the files with only 1 chunk of compressed data. The compression type flag in the DLC is the same as that with the stock game (LZO compression) so I should be able to use the same decompressor and it's definitely reading the correct offsets and sizes from the file. The error occurs in the decompressor method, but as it works perfectly for all the stock game files I find it hard to believe there's something drastically wrong in there. The program is written in C# and we're using the MiniLZO port by "Astaelan" from here: http://www.codeproject.com/Articles/16239/Pure-C-MiniLZO-port
I've also tried other implementations with no success.

Any help/ insight you could provide would be very helpful. Here's an example DLC file that doesn't work with our reader if that helps.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #1 on: February 18, 2013, 18:53 »

Hi.
Check file versions - which version is used for original game and which one for DLC?
Logged
saltisgood
Newbie
*
Posts: 5


View Profile
« Reply #2 on: February 18, 2013, 19:04 »

Thanks for replying so quickly. I assume you're talking about the versions at 0x4 and 0x6 offsets?

Testing a few files from both DLC and the stock game they all had the same versions, 512 and 130.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #3 on: February 18, 2013, 19:12 »

Yes, you're speaking about correct versions. So, some files are loaded correctly and some - not, and you have the same version for all files. This means you have one of two reasons of failure:
1) DLC has some objects which you're able to load (with error), but which are missed in non-DLC game
2) you've made some mistakes in basic serialization code

It wasn't clear for me from your first post which part of package was serialized with errors. Could you tell me more? It's not useful for me that you've provided packages which you're unable to load but umodel loaded them with no problems.
Logged
saltisgood
Newbie
*
Posts: 5


View Profile
« Reply #4 on: February 18, 2013, 19:21 »

I'm sorry if I'm not being clear but it's not the objects that are the problem it's just the decompression of the file. All the stock packages can be correctly decompressed whereas the DLC ones are troublesome.

The program reads the header and detects whether it's compressed or not, then finds the chunk info and reads all that in. It then moves to the compressed offsets that were read in and reads each chunk header and the block list. It will then decompress each block and add them all together to make the uncompressed file. It's the decompression of the byte array that's throwing errors about incorrect formats.

It's definitely reading the correct offsets and sizes since I'm double checking them by hand.

Edit: The objects aren't a problem because I can read in the file if it's decompressed with your program.
« Last Edit: February 18, 2013, 19:23 by saltisgood » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #5 on: February 18, 2013, 19:27 »

Edit: The objects aren't a problem because I can read in the file if it's decompressed with your program.
Agreed, that's the argument.
So in your case you have troubles with MiniLZO library. As the quick test you could try to compile C (original) version of the LZO into a dll and use native code from your executable. Also I think compiling mixed native-CLI executable is also possible.
Logged
saltisgood
Newbie
*
Posts: 5


View Profile
« Reply #6 on: February 18, 2013, 19:45 »

Okay then, I'll give it a go. I figured that the problem had to be either with MiniLZO or some unknown factor in the file. And if anyone could tell me about an unknown factor in the file it would be you. Thanks for the help mate.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #7 on: February 18, 2013, 19:55 »

Nobody can speak about "unknown" things Wink Simple misprint could lead to very-hard-to-catch bug. I told you how to check - whether that's bug in C#'s LZO or in your own code.
Logged
saltisgood
Newbie
*
Posts: 5


View Profile
« Reply #8 on: February 18, 2013, 20:14 »

Well let's say it could have been unknown to me  Tongue

I just successfully decompressed the file with some help from quickbms, so I guess it's definitely the MiniLZO that's causing the issue. Thanks again for your time.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #9 on: February 18, 2013, 21:20 »

You're welcome!
I hope you'll find the solution. Perhaps another LZO/C# port or a piece of native code in .NET executable.
Logged
Print 
« previous next »
Jump to:  

Powered by SMF | SMF © 2006-2009, Simple Machines LLC
Leviathan design by Bloc | XHTML | CSS