Jump to content
Official BF Editor Forums
Sign in to follow this  
rukqoa

Bc2 Mod Tool Kit

Recommended Posts

http://www.mediafire.com/?4gzby112vbrg593

Someone put together this mod tool kit mainly from stuff on these forums (though I don't recall the xml-dbx script).

I'm using it just fine, modding server files and all..etc.

2 Problems I'm facing:

1. Some files get changed when you unpack/pack them. This leads to memory access exceptions. (Others are fine though) This is probably due to the unpacker not being able to tell the difference between data types that are ambiguous. My problem is mostly with vehicle files (though not vehicle_firing files)

2. Still can't figure out how to change deviation stats. I've tried setting everything to zero and still no change. (Is it client-side?)

Edited by rukqoa

Share this post


Link to post
Share on other sites

Just to be sure, by unpacking/packing, do you mean the fbrb files or dbx files?

As for 2, make sure you modify the correct file. The load order is

Dist\...\mp_common

Dist\...\mp_0xx

Package\...\mp2_common

Package\...\mp_0xx

However while I'm not aware of any individual map overriding anything, some vehicles/objects are found in the map only (the stationary gatling gun in particular). Anyway, you need to change the Package files.

I assume deviation works similar to bf2. Server and client may have different deviation values. This only means that you cannot rely on tracers and bullet impact effects. In the end the server decides about hits and hit points, so targeting objects with hit points is a reliable way to test deviation.

Share this post


Link to post
Share on other sites

Just to be sure, by unpacking/packing, do you mean the fbrb files or dbx files?

As for 2, make sure you modify the correct file. The load order is

Dist\...\mp_common

Dist\...\mp_0xx

Package\...\mp2_common

Package\...\mp_0xx

However while I'm not aware of any individual map overriding anything, some vehicles/objects are found in the map only (the stationary gatling gun in particular). Anyway, you need to change the Package files.

I assume deviation works similar to bf2. Server and client may have different deviation values. This only means that you cannot rely on tracers and bullet impact effects. In the end the server decides about hits and hit points, so targeting objects with hit points is a reliable way to test deviation.

I meant something gets messed up when I do dbx->xml->dbx without modification. The file size increases about 3kb (depending on which file). I have a list of files that work/don't work if you think it would be helpful.

Basically, all the vehicles body files don't work, and all the level files don't work. But everything that has to do with weapons seem to work fine.

List of not working

Objects\Vehicles\Land\M1A2\M1A2.dbx

Objects\Vehicles\Air\AH60\AH60.dbx

(Pretty much all the levels.dbx files don't work)

List of working

Objects\Vehicles\Land\M1A2\M1A2_Firing.dbx

Objects\Vehicles\Land\M1A2\M1A2_hmg_Firing.dbx

Objects\Vehicles\Air\AH60\AH60_Minigun_Firing.dbx

(Pretty much everything in Objects\Weapons\Handheld works)

These are server files, not client by the way.

I tried comparing all the key values in the working vs. not-working, and it came up with a few like "index", "enumeration", "name"...etc.

Anyway, this is like the last stop to a full blown mod. Without this, we can't edit any vehicles or levels.

As for deviation, I totally screwed up. I tested it using bullet decals, which means that would be completely pointless because that's client side. Everyone else in the server probably thought I was shooting lasers when I saw completely different patterns on screen. Gah... I guess I'll make the damage 1%, get me a 250 round gun, and shoot the hell out of a quad bike (health 250).

Edit: Re: Deviation, shouldn't the deviation/recoil be whatever I set it to be in the client files? I changed the mp_common and mp2_common on both client and server, and it's still the same ingame for some reasons.

Edit2: Strange, seems like changing SP values for spread/recoil doesn't change anything either in SP...

Edited by rukqoa

Share this post


Link to post
Share on other sites

I meant something gets messed up when I do dbx->xml->dbx without modification. The file size increases about 3kb (depending on which file). I have a list of files that work/don't work if you think it would be helpful.

Basically, all the vehicles body files don't work, and all the level files don't work. But everything that has to do with weapons seem to work fine.

Right now my script numbers strings differently than the game does. This is not much of an issue in itself as any numbering is accepted as long as the actual file makes sense. In general though my files appear to be slightly bigger. I suppose this suggests that the game makes the most common string the smallest number. Fixing the numbering would make life a bit easier though so I'll take a look at it.

The actual issue is caused by "index", "name", etc. as you mentioned, which are basically random hash values between 0 and 0xffffffff. Dbx files have only one number type. The script checks if a number is a reasonably small integer and returns int, otherwise it will be interpreted as a float. This works pretty well for the most part but breaks with "name" because the script rounds floats. I've added some extra lines just for that, but I've but probably missed one or two of these things breaking the files.

I think I'm going to do some bug fixing right now.

Changed the gun US_rgl_XM8_Firing in Package\levels\sp_006: http://i.imgur.com/loLBD.jpg

Edited by Frankelstner

Share this post


Link to post
Share on other sites

Hmm, is it possible to have the dbx->xml script represent floats as 'x.x' and have the xml->dbx script check for the decimal point?

And wow. Apparently, instead of using the deviation data in mp/sp common, they made it so that it's level-specific?!

Share this post


Link to post
Share on other sites
Hmm, is it possible to have the dbx->xml script represent floats as 'x.x' and have the xml->dbx script check for the decimal point?

My script does that already (at least I hope so). The problem is that dbx files have only one number type. It gives me the number of bytes of the number (2,4,8) and that's it. I have to make a guess whether that number is float or signed/unsigned int. I suppose the game has some kind of dictionary, so I have to make one too.

And wow. Apparently, instead of using the deviation data in mp/sp common, they made it so that it's level-specific?!

Only SP and certain weapons I think. Don't expect too much common sense though. The entire Package folder for example is a failure. The game loads the original 1.0 files first and overrides the data with the patched files in Package. At least it's good for quick mods.

On another note, I'm working on my own fbrb extractor. Seems like aluigi who made the quickbms version left out crucial information. http://i.imgur.com/3rYR0.jpg

I'll probably remove .res altogether and use the part after the minus as the new file extension.

Edited by Frankelstner

Share this post


Link to post
Share on other sites

Okay, now I finally solved that one.

Weapons in MP:

RoF, mag size, basic weapon properties like that -> Modify mp_common and mp2_common on server.

Deviation, spread, recoil, camera stuff -> Modify mp_level on client Package.

This is pretty messy. I'd have to pretty much go through all the mp_levels if I wanted to change deviation/spread stuff like that.

Time to write an editor...

My script does that already (at least I hope so). The problem is that dbx files have only one number type. It gives me the number of bytes of the number (2,4,8) and that's it. I have to make a guess whether that number is float or signed/unsigned int. I suppose the game has some kind of dictionary, so I have to make one too.

Hm... so there's no way to tell from the numbers themselves... Well, then would it be possible to just have the xml->dbx script look at the original dbx file so it knows not to use more memory than it should? It should stop the memory access exceptions.

Edited by rukqoa

Share this post


Link to post
Share on other sites

Okay, now I finally solved that one.

Weapons in MP:

RoF, mag size, basic weapon properties like that -> Modify mp_common and mp2_common on server.

Deviation, spread, recoil, camera stuff -> Modify mp_level on client Package.

Well, if modding the individual levels seems cumbersome, just make the files inside the levels blanks and put the info up in mp_common. You can probably merge mp_common and mp_common2 too if you want. As for server/client, you'll want to do it synced for both anyway.

Hm... so there's no way to tell from the numbers themselves... Well, then would it be possible to just have the xml->dbx script look at the original dbx file so it knows not to use more memory than it should? It should stop the memory access exceptions.

Another thing just came to my mind, namely double floats. I'm not quite sure if my script handles these correctly which might be the reason for memory access. However the issue with "index", etc. is still there. There's no warning byte/bit whatsoever to tell integer and float apart (at last I haven't found it yet). "Index" seems to be a hash of some kind and thus rather random in the entire 4 byte range. Because of that the script is inclined to read it as float. Afterwards the number will be rounded causing information loss.

I could just remove the rounding of numbers, but there must be better ways. I'll take a look at it once I've fixed the fbrb mess.

Share this post


Link to post
Share on other sites

Well, if modding the individual levels seems cumbersome, just make the files inside the levels blanks and put the info up in mp_common. You can probably merge mp_common and mp_common2 too if you want. As for server/client, you'll want to do it synced for both anyway.

You can do that? I would love if I could merge all of them, but the fbrb packer I'm using doesn't allow me to merge multiple archives. It looks at the original archive every time it tries to repack things back.

Another thing just came to my mind, namely double floats. I'm not quite sure if my script handles these correctly which might be the reason for memory access. However the issue with "index", etc. is still there. There's no warning byte/bit whatsoever to tell integer and float apart (at last I haven't found it yet). "Index" seems to be a hash of some kind and thus rather random in the entire 4 byte range. Because of that the script is inclined to read it as float. Afterwards the number will be rounded causing information loss.

I could just remove the rounding of numbers, but there must be better ways. I'll take a look at it once I've fixed the fbrb mess.

It's hard to believe that the majority of the files don't contain doubles, especially the weapons AND materials files. If doubles break things, then modding those files shouldn't work (yet they do).

Share this post


Link to post
Share on other sites
You can do that? I would love if I could merge all of them, but the fbrb packer I'm using doesn't allow me to merge multiple archives. It looks at the original archive every time it tries to repack things back.

Sure is possible. As far as I see it the quickbms extractor we have used so far is a shoddy piece of work (I find it hard to assess how much modding attempts have been delayed due to this). The files are extracted with a loss of information making it impossible to put them back in. Now dhwang still tried to make the best of it by comparing the original archive, etc. which is really nice given the situation.

But the script I've posted in the other thread extracts files without any info loss. There's still one minor thing I need to take a closer look at, so I'm not perfectly happy with it yet. I'll probably get it done in the next few hours and then start working on the packer script.

It's hard to believe that the majority of the files don't contain doubles, especially the weapons AND materials files. If doubles break things, then modding those files shouldn't work (yet they do).

If I recall correctly (it's been over two years) there are doubles mainly for object positions on maps. They are indeed quite rare.

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
Sign in to follow this  

×