BRF Joiner

[Janus]

Anyone interested in a BRF Joiner program? The purpose of it is to combine a bunch of BRFs into a single one for simplicity's sake.

I have a fully working version done, I just need some people to test it out and make sure it works. That's if anyone is interested in it in the first place.

Here's the 0.60 test release of it:
http://www.fenrisoft.com/storage/MnB/BRF_Joiner.zip

It currently has a list you add the BRF files to, then Save to a new combined file.

Word of warning, BRFview doesn't always do well with combined BRFs and will sometimes lock up trying to load them or sometimes save the file with everything other than mesh data removed.
Not sure if Simpson's texture/material editor handles BRFs with other data properly or not.
Further note, though it will combine mesh definition files (like those you would edit in BRFview), it combines them as two seperate mesh listings within one file rather than combining the listings into one.
It is a first test release though.

If there's interest, I'll try to add in simple BRF splitting capabilities to split a combined BRF, whether using an unmodified M&B BRF or one combined with this program. It would separate out the mesh, collision, material, and texture definitions into separate files. This could be used to get the collision definitions copied out of the standard core M&B BRFs.
Improved joining capabilities are another possibility.

Honestly, I don't know if anyone is interested; if there's not much interest, I'll just leave it in it's current functional (I think) state.

 

[Deus Ex]

It sounds quite useful Janus. I don't have time to do LOTS of modeling so it would not be something I would use often, but from what I understand it would be quite useful if one did end up creating a lot of Collision Definitions.

DE

 

[Winter]

It'd be pretty useful to me in keeping Storymod simple. If you look at all the BRFs in my Resource dir, you can see it's a ****in' nightmare. I hope you can somehow make it compatible with BRFView, as BRFView still makes cloning and renaming meshes a lot easier than doing it completely in hex.

Nautically,
Winter

 

[Janus]

The reason I originally decided to make it was because Jik was asking for a way to combine a large collection of separate collision meshes so they wouldn't be in so many little BRFs. So, just what Deus Ex was saying.

Really any problems BRFview might have with them would be due to limitations in the current version of BRFview. Hopefully Lurb does come back and continue it like he was planning.

I know there are some non-mesh BRF contents it safely leaves alone when editing and adding meshes, but I believe some get dumped; not sure which is which though. I believe collision definitions are left alone and not lost by BRFview, but I sure wouldn't swear on it.
For the BRF files containing stuff other than meshes (such as texture and material definition files and collision definition files) there should be no problems since the current BRFview doesn't handle separate files of those other types. I'd keep backups to be on the safe side, to be sure.

As far as combining BRF files with different types of information, that's no problem. You could make one single mammoth BRF with everything in it if you wanted. You'll notice my Arena Expansion only has one BRF; that's because I combined the 3 of them (materials, texture names, and meshes) into one. I did that by hex editing a while back, with the same result as this new tool would give.

EDIT: suppose I should check and confirm what problems BRFview might have with different combinations. Will check on that after a while and post what I find.

 

[Winter]

Yeah, I really don't want to use it unless I can be sure it won't cause me more problems than it solves.

Epitomically,
Winter

 

[simpson]

Sadly my editor will not work with such a joined brf file and i would have to completely change my reading and writng algorithm to make it read such a brf.but i still think this is a useful utility,just dont join the texture and material files to the combined brf so that u can use my editor.

 

[Janus]

Sadly my editor will not work with such a joined brf file and i would have to completely change my reading and writng algorithm to make it read such a brf.but i still think this is a useful utility,just dont join the texture and material files to the combined brf so that u can use my editor.

Why not simply have it search the file for the "texture" and "material" entry points in the file? They have a distinct pattern you can search for. It could then read the data from that section, and store everything before and after the section it's working on. When later writing back to the file it could attach the stored data from before and after the section it was working on so nothing was lost.
Just a thought, anyway.

Some of these reasons are why a "split" function would be a nice feature; I'll work on that when I have time. Still need to test for problems with BRFview.

 

[Janus]

Ok, just got through testing various combinations on BRFview. Turns out that any file which doesn't have meshes at the very start of it will cause BRFview to hang.
Assuming you have a combination with meshes at the start of the file, any other contents besides the starting meshes will be lost when you save with BRFview.

So, based on that, the main purposes now for this would be to combine collision BRFs, or to combine a lot of BRFs for final packaging of the mod just to clean things up. In that second case you should certainly keep the original unmerged files as well.

 

[jik]

Gonna give it a test pretty soon.

I don't think it's so bad to have a BRF count like :
materials.BRF
collisions.BRF (the BO stuff)
items.BRF
objects.BRF (objects being scene objects that would need the BOs)

The only problem further down the road is having your collisions.brf file start to contain stuff you may not need. But I guess if Lurb's tool gets fixed, then we'll be able to strip out the unwanted stuff...

 

[fisheye]

The only problem further down the road is having your collisions.brf file start to contain stuff you may not need. But I guess if Lurb's tool gets fixed, then we'll be able to strip out the unwanted stuff...

You should always keep the original files. That way you can recreate the big file any way you please by just re-joining the old ones together.

Anyone know if load times are reduced if you have 1 BRF instead of 100?

Other than reducing load times I can't think of any reason for this utility. Management gets harder if all your resources are packed ass-to-ass, anonymously into one big file so you can't just get to the one you want.

 

[Janus]

So you would rather have 100 assorted body, mesh, material, and texture files to sort through when you're looking for something, rather than a handful of them to deal with and all finished ones packaged together? You don't have to put all of them in a single file.

I dunno, I was considering starting work on a BRF explorer utility which could parse all resources in a BRF and display them in a tree format, combine them intelligently by loading several files and saving the combination to one file (no seperate sections of the same type), take parts of what is loaded and save them to a new file (split out sections if needed, un-combine stuff if you will). I was going to base this off of the BRFlib.

Maybe there's not much point after all.


EDIT: and it would of course be able to split apart the original files, some of which have collision bodies and meshes together in one file (probably other combinations as well) which BRFview doesn't currently like.

I had already started on it a bit, but am considering dropping the idea now.

 

[fisheye]

So you would rather have 100 assorted body, mesh, material, and texture files to sort through when you're looking for something, rather than a handful of them to deal with and all finished ones packaged together? You don't have to put all of them in a single file.

I dunno, I was considering starting work on a BRF explorer utility which could parse all resources in a BRF and display them in a tree format, combine them intelligently by loading several files and saving the combination to one file (no seperate sections of the same type), take parts of what is loaded and save them to a new file (split out sections if needed, un-combine stuff if you will). I was going to base this off of the BRFlib.

Maybe there's not much point after all.


EDIT: and it would of course be able to split apart the original files, some of which have collision bodies and meshes together in one file (probably other combinations as well) which BRFview doesn't currently like.

I had already started on it a bit, but am considering dropping the idea now.

I think the ideal method is to keep your brfs separated in different directories for organisation, then write a batch file to join (compile) them together when you actually want to start M&B.

 

[Janus]

I think the ideal method is to keep your brfs separated in different directories for organisation, then write a batch file to join (compile) them together when you actually want to start M&B.

Something to join them? That's what the program posted above is for.

Like I said though, some of the core M&B BRF files are different types joined together.

Ah well, setting aside the "BRF explorer" for now then.

 

[fisheye]

I think the ideal method is to keep your brfs separated in different directories for organisation, then write a batch file to join (compile) them together when you actually want to start M&B.

Something to join them? That's what the program posted above is for.

Yes, a batch file to use the program posted above to join them.

 

[Janus]

Yes, a batch file to use the program posted above to join them.

Hmm, that would require command-line functionality which the program doesn't have; it uses a GUI. It's a rather basic one which could definitely be improved, but hey, it works.

 

[cotdamn]

i think its a great idea, from the get go i thought having 10 different collision meshes was really annoying. and anything that has a GUI instead of hex-editing is useful to me.

 

[Janus]

Hey guys, there's no need for this program now. Thorgrim's new BRF utility is going to have this angle covered.
So an un-sticky is in order, I think. Thanks though, Effidian.

 

[jik]

I got here too late...

Well, I'd like to thank you for the joiner. I see Fisheye's point, but I'm not trying to compile all my BRFs into 1. But I would like, say, all my BRFs for the Palisade walls to be in one BRF called Palisade.brf. At the time I was looking at 18 BRFs just for the BO objects.

Your right Fisheye, you should have seperate packs, but when you build a mod, you might want to reduce the excess typing. Back in the days of C programing in DOS C++, my teacher told me, the less code, the less chance of mistakes. Imaging the module_info file with seperate BRFs for each object.... ARRRRGGGHH!!! typing nightmare!

 

[Effidian]

Hey guys, there's no need for this program now. Thorgrim's new BRF utility is going to have this angle covered.
So an un-sticky is in order, I think. Thanks though, Effidian.

Okay...

 

[Thorgrim]

Just wanted to say thanks to Janus for the idea though.

I think the feature will be very handy for things like mini mods, or item packs.

You can just add all the items, materials, texture names, collision meshes, even new shaders to a single BRF, making it easy for other mod makes to incorporate them.

I've yet to check if this actually will work yet... I think I may need to tweak the way BRFs are saved, but if it doesn't work yet, it should be possible in a later version.