Yes, if you add the following line at the very start of the script, it will decompress the NCH.XEPACK files:

Endian Big

It looks like that's the only change needed, at least for the XEPACK sample, so it should work fine with the others.

If you delete the following line:

XMath ENTRY "OFFSET - (ENTRIES * 0x10)"

And replace it with:

Math ENTRY = 0x3c0 (or whatever it is)

The location of entries is always at 0x54, or at least it is in all of your samples.

The way it was calculated was to look for the hex sequence 0xa1a1a1a1 and subtract the size of the file table to get the start, but this didn't always work. The file table usually starts at 0x394 in GAME.XEPACK, 0x368 in GAME.PCPACK, somewhere after the string of 0x01 bytes. In LOCATION_BLACK_CAT_1....

Having looked at the other samples, some of them don't fit the logic of my script. Some of them have the file table starting in a slightly different place. There's no obvious offset to the start of this table because the logic used doesn't always work, so I'm stumped on how to calculate it accuratel...

You shouldn't need to change the file data at all - it looks like you've swapped every 4 bytes in the whole file, as all of the texts etc. are the wrong way round. This definitely won't work as Big Endian only applies when reading numbers; any strings should remain the same, although there are expec...

Being PS2, it uses the horrible VIF tags and packed data that are present in lots of PS2 games, which are a pain to process properly due to their complexity. I can't see any useable face data just by looking at it, and auto-generated triangle strips don't work either. In CAR01.SMB, this is how the V...

It is standard xmemlzx. If you use offset + 8 as the starting point, it will work. I'm not sure what 'Size' refers to, but the decompressed size is 0x21BF of that chunk.

Yes... If the format is identical, then it might be enough just to set any scripts to read Big Endian instead of Little Endian on the PC version.

Yes, everything is mirrored because the XBox format is Big Endian, so numbers and strings are the other way around compared to the PC version. Any scripts that reads those files need to take into account the difference and read them accordingly. If the format is identical, then it should be a case o...

Yeah, it looks like the original Python script had the extension in hex, so just a quick modification to my script:

I'm not sure from looking at the script. I've rewrote a QuickBMS script using the same logic that should work for both file versions, if you want to give this a try:

The reason it doesn't work is because the XBox 360 files use Big Endian format for storing numbers, so the script as it is will only work on PC. Assuming the file structure is identical, you should be able to change the following line and see if it works: bs = NoeBitStream(file.read(fileLen)) Change...

It's a complicated format. Here's my crappy script so far. All it does is get the basic geometry data for each file - multiple files make up the whole car. UVs are often messed up too. There are various LOD levels which aren't obvious from the random filenames, so I have no idea how to tell what fil...

It uses Deflate compression, so you can extract with Offzip, something like: offzip -a -z -15 anim_tex.png "output_folder" 0

They aren't PNG files. The decompressed data has a "PKM 20" header, which Noesis will load.