Jump to content
Official BF Editor Forums


  • Posts

  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

12,258 profile views

Frankelstner's Achievements


Newbie (1/14)



  1. I can't believe they did it again. It's the same permutation obfuscation that was used for that one console game: http://www.bfeditor.org/forums/index.php?showtopic=15780&page=5#entry106500This being said, I suppose the same might apply to the audio files in the bf4 DLC too. Thankfully I have left in the option to enable permutations there. Just in case though, can someone run my decoder on the DLC files with permutation activated and see if there are any files?
  2. The res seems to contain 4 sections after the header. 1) Contains structures with a0 bytes each. A chunk id is given with an offset of 58 relative to the structure. 2) Contains structures with c0 bytes each. No ids here. Each structure ends with two "lines" (when using 0x10 alignment in the hex editor) which each read FFFFFFFFFFFFFFFFFFFFFFFF00000000. 3) A string section. 4) Payload of some sort? Header: 8 floats. Unknown purpose. Fourth and eighth float is null. 6 longs. Each long specifies the offset of a structure in the first section. If the section has less than 6 elements, the last few longs are set to null. As a consequence, there cannot be more than 6 guids given in a single res file (or so I believe). What's more, the structures are always a0 bytes and the header has a fixed size too, so one can calculate the offsets anyway without these longs. 2 longs. Absolute string offsets. It works like this: 1) objects/props/puddle/puddle_02_Mesh 2) puddle_02_Mesh (this is a substring of the previous one) 1 int. Hash of the filename or something like that. 4 nullbytes 1 int. Can exceed the size of the res + chunk (even when taken together). Other times is just 1. 1 short. Number of elements in first section, may not exceed 6 (because 6 longs max) 1 short. Number of elements in second section first section: 4 nulls, ffff, 2 nulls struct (3 ints): 5 times 1) small num 2) offset/size? 3) null Times: 1) 1, 110, null. maybe size of floats in chunk 2) 0, 230, null. Offset in res (after strings) 3) 1, 230, null. Same? 4) 0, 231, null. 5) 0, 231, null. long. 41 or 40 int. 30 long. 120. maybe size of floats in chunk guid ffffffff 8 nulls 3 longs, string offsets 1) Mesh:objects/props/puddle/puddle_02_Mesh_lod0 2) objects/props/puddle/puddle_02_Mesh_lod0 3) puddle_02_Mesh_lod0 h32? 16 nulls second section: 8 nulls int, string offset: lambert2 8 nulls small int, 8 8 nulls small int, 9 so maybe that was a struct with 3 ints again. int, 320 8 nulls some very odd bytes now FFFFFFFFFFFFFFFFFFFFFFFF00000000 FFFFFFFFFFFFFFFFFFFFFFFF00000000 About your second tool, note that you need to use the EOF to calculate the last number of faces. I've cleaned up your program and fixed that issue: http://pastebin.com/iciNCS5N Also note that kiwidog is working on the meshes too right now, though I don't know much about his progress.
  3. I've updated the script to handle those 6 EASpeex stereo files correctly. Additionally I've cut down the EASpeex volume in half to get rid of clipping. The codec gives me back floats in a range of about +-50000.0 so I just divide by 65536 (instead of 32768) to get decent samples.
  4. The script now supports the xpack archives. Note that you must replace previous versions of the LZ77.dll as I had to make some extensive changes to it too. Meh, I forgot to make tocRoot2 absolute so the unpatched files were not extracted. I've fixed that though and on the bright side, if you happen to have used the old version you can just run the new one and it will continue where the other one left off.
  5. Aha. The dumper doesn't support the xpacks at the moment as they are noncas (and of course different from the noncas from bf3). I've downloaded the xpack files just yesterday and managed to dump the unpatched noncas, plus I'm about 50% done with the patched noncas. Thus it shouldn't take too long until I finish this. Will post the script when I'm done. I've changed some settings when compiling now. Does this dll fix it? http://www.gamefront.com/files/23943162/easpeex.zip
  6. I think we should elaborate a bit to prevent misunderstanding. So you mean to say that you have used the bf4 audio decoder (the previous version without speex support) to decode the xpack audio? I see a couple of issues. The dumper script does not handle noncas sbtoc yet so maybe the chunks are hiding there. Also, how did you define the chunk folders? Did you merge the DLC files with the other files (which is what I recommend)? In that case however, have you used some tool to determine the difference in output before and after adding the DLC files? About speex, try to replace the try/except at the top with a simple statement, i.e. substitute try: speex = cdll.LoadLibrary("easpeex") isSpeex=True except: isSpeex=False with speex = cdll.LoadLibrary("easpeex") The error message should be a bit more descriptive as to what's going on.
  7. It works fine when placed in the Python27 folder. Anyway, you must have 32bit Python to use the dll. Though wait a sec, that is required for xas too. I don't really have any ideas right now. I haven't tried it myself, but I suppose the decoder should work with the DLC too. Is there any error message in particular or does it just not do anything?
  8. I have added support for Speex. Use this dll: http://www.gamefront.com/files/23940328/easpeex.zip There are 6 stereo files (all other are mono) which are not handled correctly; they are located in Sound\VO\EN\MP\PA. I'm not sure where to start though and if this is worth fixing (the audio is a bit garbled but still comprehensible).
  9. You could place the script in just about any Python folder. Common practice is to make a new script and place it in such a folder, then add two lines to the __init__.py in the same folder (which is empty by default): import myscriptname myscriptname.init() When a round starts this will then call the init function of your script. In your script, set up the timer in the init function. The rest of the script should work out. import bf2 import bf2.Timer import host def init(): timer = bf2.Timer(onTimer, 60, 1) timer.setRecurring(60) messages=("This is an unranked server", "Modified by Belgian_hero and =hero= Shoota{BE}", "Grenadelaunchers and C4 have 0 damage") def onTimer(data): global messages #not sure if this is even needed for message in messages: #just tidying things up a bit host.rcon_invoke('game.sayall "%s"' % message) I haven't tested it, but I hope you get the idea.
  10. I've changed the script a bit so it only gives a message about unknown types but keeps running. I can't find fields of type 49453 right now, though I suppose they are rare and contain nothing useful anyway.
  11. Note that the entries in question are not the ones in the sb, but in the toc. I've changed the unXOR function in the sbtoc.py. The tocs are not encrypted anymore. In fact the game does not contain any encrypted files at all now.
  12. I think the dumper with the pure Python decompression did not decompress chunks which were not part of a bundle. The dll has this all fixed, as you've found out yourself already.
  13. Looks fine to me: http://i.imgur.com/TROhprJ.png
  14. http://www.bfeditor.org/forums/index.php?showtopic=15844&st=0 The ebx files you have are compressed. I assume you have used the bf3 dumper on the unpatched files. That doesn't cut it. DICE changed the compression from zlib (not used for ebx files however which were uncompressed) to their own LZ77 variant which is applied to every single file.
  15. Well there you have it. The files do not start with CED1B20F and are thus not recognized as ebx. There's a chance that the previous pure Python dumper did not decompress all files properly, so you could dump the files again with the dll (which is much faster anyway). Other than that, upload an ebx file so I can take a look.
  • Create New...