@LinkOFF, some extra info that might be useful for info.arc: * All offsets are relative to the address where that offset is stored * Main header - 0x14 bytes: 0 - Text - "BXON" 4 - ? 8 - ? 12 - Int - Offset to archive name/type ("tpArchiveFileParam" in this case - other types see...

Like I mentioned, the sample files *are* important because info.arc contains the file table which has several thousand entries for stream.arc. So you need that to get the offsets and sizes for all of the individual files in stream.arc, easier than ripping them manually. I've managed to parse the inf...

Yeah, there's no password protection, it's just pure ZSTD from the few sample files I've looked at that people have posted. The files info.arc and common.arc are both 1 single block of compressed data, whereas others like lang1.arc and lang2.arc are made up of small blocks of compressed data that ha...

I just used RPFTool to get the initial files - it seems to work the same for both versions.

The resulting "CSR" files are compressed with standard zlib for PS3, and xmemlzx for XBox 360, so I just did a QuickBMS script that decompresses both versions (attached).

Yeah, those are XBox 360 ones (including your other sample). It's no big deal, just so I know which version I'm looking at. I think the XBOX version is slightly easier format than the PS3. It seems like I can get the info for all meshes from the X360 versions, although still a few issues to iron out...

Each file is a separate part of the whole model, so one file is just a seat or chassis, etc. Some are lower detail versions too. I just put some of the pieces together in Blender. The rims/tyres and stored separately as well. So there may be some "setup" file covering the whole model somew...

Here's my first attempt at parsing your sample file(s). Seems ok so far, but still lots of unknown stuff.

I'm always interested in car models, so I wouldn't mind getting these. I've also extracted the files myself and get the same resulting unnamed files as you, so they are most likely correct. The format itself is very convoluted, with pointers all over the place to various bits of data. The addresses ...

Download Noesis, put my script in the plugins/python folder and the _model.bin files should then load.

I can see that there's a table to split the meshes into parts. I could probably do a Noesis script, but would need a few more examples of meshes, and maybe some of the textures to go with them.

No, it looks like the file is fine. It's just a custom format. Unless there's a script for another game that uses the exact format, then something needs to be created for it. Not an easy task considering these formats can be quite complex at times. I can hack something together for the level data, b...

I've had a bit more of a look at it. The header is the first part of the file. The magnum file seems to have an extra 8 bytes at the start compared to the previous level file. Not sure if that's how it's supposed to be - i.e. it should start with the 0x09 value if it's meant to be the same format as...

I'm not sure what you mean by "necessary header" - headers can be absolutely anything. Just from a quick look, you've got a file table at the start with offsets to each section - the first Short value in the file is the number of entries in this table (0x251). So this file has 0x251 separa...

Just install Foobar and the vgmstream plugin and they'll play. That file says it's Custom Vorbis format.

From what I can see, there's no actual model data in those Grunt or Wretch files - just textures and text files.