Jump to content
DerelictStudios Forums
jonwil

Details Of The Format Of The Manifest/bin Files

Recommended Posts

Hi DetoNato,

 

Sorry about that, should be fixed now... a side effect of using some options in Borland C++ Builder. If you download the new version attached to this post, you shouldn't need any additional files.

 

--booto

BinOpener.a_rar_file

Share this post


Link to post
Share on other sites

Made the interface a little less annoying, window can be resized as well as the two separate panels. This now also allows the dumping of all streams in a bmri set at once, rather than extracting one by one.

 

Only use the 'extract all' option on the aptui brmi sets, because it tries to dump every stream regardless of whether of not the offsets/lengths make sense. This could potentially cause very large files to be created, cause it to take aaaaaaaages, or cause the program to crash.

 

For the larger brmi sets, use the 'Extract Selected Stream' button to extract files individually.

 

Nothing beyond that has really changed.

BinOpener.a_rar_file

Share this post


Link to post
Share on other sites

When I say

 

For the larger brmi sets, use the 'Extract Selected Stream' button to extract files individually.

 

I mean to extract the files with sane sizes in the info panel.

Share this post


Link to post
Share on other sites

Yet another release... I've started picking apart resource types in the bin files as best I can so far.

 

If you browse to a MissionTemplate resource or a MultiplayerColor resource, it should bring up some extended info in the information pane.

 

This also should not do silly things with file sizes anymore, so you can just 'Extract All'. It should be more stable.

 

Probably best not to play with static_demo_l_common just yet, it's a bit odd... seems just like static_demo_common except with (all?) zero-length stream resources.

 

Next for this program is just to map out various file formats... there's a heap of them.

BinOpener.a_rar_file

Share this post


Link to post
Share on other sites

For some reason, you probably just extracted the header of the files... and these extensions are far too weird... .ae, .af, .vel, .music... The biggest file from global_demo_common had 3.35kb and that package include files like ScoreScreenMusic.music that is suposed to be a lot bigger than that.

 

At least you tried.. and it was a good try, but there are a lot of things that still need to be done in order to bring some good results.

Share this post


Link to post
Share on other sites

I suspect kmx knows more about the audio situation, but if you have a look at the bmri file sets, global_demo_common.bin is only a meg or so. My extractor currently doesn't take much (any) notice of the cdata files, ~423 megs worth of which are in global_demo_common\cdata which might point to the source of that missing data. In reality, I've been working more with static_demo_common (has a lot less cdata) and the textures than global_demo_common and the audio files.

Share this post


Link to post
Share on other sites

Incorporated the processing of cdata streams (takes priority over any data stored in the bin). This slows down loading of mbri sets a bit, mostly noticeable with global_demo_common - but makes the app more complete.

 

The OnDemandTexture resources are converted to DDS, but the Audio files aren't converted because I don't know how to (yet?).

 

When extracting multiple files, you no longer have to extract everything. You can choose a resource category by selecting that category in the treeview and click 'extract selected stream(s)'.

 

There are also a few more file formats recognised... StringHashTable can be loaded (looks suspiciously related to relo entries - same number of both) and I think I have the w3dcb format sorted - it's just a simple box defined by some floats. The values of the floats being generated seems reasonable - no outlandish exponents.

 

Also, when extracting all AudioFile resources from global_demo_common, it extracts the same amount of data that exists in the cdata directory, indicating it's all AudioFile data. This might mean the AmbientStream and MusicTracks are linked to other things through the 'Extras' field.

 

Also, with regard to the weird file extensions, they're just random extensions I chose based on the name of the resource they come from. They're not supposed to represent extensions present in other things, just so you know 'hey, that came from a MusicTrack resource' rather than just having everything related to sound with the same extension. The only extension that is a proper extension in real life is DDS which is used for Texture and OnDemandTexture resources at this stage. When you extract something, feel free to rename the extension to whatever the hell you want, it's just a placeholder I had to make each resource type have a unique extension. Alternatively, if you find that a file is in a widely used file format and I haven't noticed, let me know and I'll change it to be saner.

 

--booto

BinOpener.a_rar_file

Share this post


Link to post
Share on other sites

Imports section now understood (I think?) and converted to useful data to display within the GUI. This should be useful for people who are trying to locate files that are related to each other.

 

Not all imports do resolve, and in the case that an import doesn't resolve, it is because the import comes from another manifest that is included with the examined one. In the stream info window, it should output two hex numbers instead. You can use those two numbers (as filehash1 and filehash2) to search for the import when the brmi set it is included from is open in binopener

 

--booto

BinOpener.a_rar_file

Share this post


Link to post
Share on other sites

@ booto

 

Well, Im still wondering what this crash report means (attached file). It happend if I try to open the static_demo_common.manifest.

 

Anyway, you are doing a great job. Even if this tools is a bit buggy yet. ;)

post-152-1173570065.jpg

Edited by DetoNato

Share this post


Link to post
Share on other sites

Hmm. I'm not really sure :/

 

Has anyone else got this sort of thing?

 

Did it only hapopen with this version, or all previous versions, too?

 

Does the version attached to this post work?

 

If you still have issues, please contact me on msn: temptemp91 at hotmail dot com

 

--booto

BinOpener.rar_file

Edited by booto

Share this post


Link to post
Share on other sites

I'm still wondering.... are you guys sure that every file type is dealt with a different compression code?

Edited by Banshee

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×