Black Desert Online Modding Tools (2 Viewers)

BlackFireBR

Content Creator
Joined
Sep 2, 2013
Meta Injector Reloaded v1.5
- Dramatic performance increase.
- Backup restoration options.
- Compatibility with the newest armors textures.
- Automatic copy files to their right location

Download link: Meta Injector Reloaded
Source code: https://www.undertow.club/attachmen...3/?temp_hash=edbb04fc41f14d4d434733fc47fe7554

This version, the program was entirely remade.

We no longer use bdmod.exe since finally I figure it out how the program use to work so I programmed one that does exactly the same thing, but it patches all the files in a single run, and it handles everything in memory instead of dealing with reading and writing files all the time.

Result: The performance is tremendously better now. You can easily patch thousands of files in a few seconds.

The program is now able to patch for new textures from armors that weren't released at the time bdmod.exe was created (which causes it to fail, obviously)

We no longer use old meta files and there is an option now to select a backup to restore from a list of backups that the program makes every time the number of bytes of the meta file changes (due updates).

Now there is only 1 part, not 2, because both parts now were merged in one super efficient algorithm.

Files that were failing to patch in "Part 1" in the previous version are most likely to still fail (the hash for those files simply is absent in the meta file, trust me, I tried everything I could to find them).

Some other files that failed because there was no .PAZ file at the time that contained them, can actually now be found.

Now there is a super cool feature, once you are done with the patch, you can chose to copy the files or move them to their right location. Even if you "files_to_patch" is a mess, it will create the appropriate folders and places all the files in their right location, you don't need to move anything to anywhere anymore.Just choose 1 to copy the files, or 2 to move them.

Here are the new instructions:

1 - Extract the zip file to your PAZ folder.

2 - Put all the files and folders you want to patch in the "files_to_patch" folder.

3 - Run Meta Injector Reloaded.exe

4 - After the patch, choose 1 to copy the files from \files_to_patch\ to the place they need to be or 2 to move them.

Uninstall:
Run Meta Injector Reloaded.exe and select the "Restore backup" option.
The latest ones are the most up to date.


Test this new version and give me some feedback please.

Peace.
 
Last edited:

Kenith

Club Regular
Joined
Mar 7, 2016
It works well and fast

1.png


pew_99_ub_0004_dec - my favorite UW Black Garter Belt
phw_00_xx_0077 - New cos for Sor
2.png
 

kkoraz

Vivacious Visitor
Joined
Apr 12, 2016
sweet - so with 1.5 this modder should even if a new patch borks the armor swapper? kinda how resorep used to work after patches even if the armor swap didnt
 

BlackFireBR

Content Creator
Joined
Sep 2, 2013
sweet - so with 1.5 this modder should even if a new patch borks the armor swapper? kinda how resorep used to work after patches even if the armor swap didnt
No, if they patch one, both of them will stop working, they use the same principle.

Resorep used to do something completely different, that's why it was still working.

The advantage of v1.5 is that, if they include new stuff the game didn't have before, you will be able to use the tool for those new files too.
 

krazzie

Potential Patron
Joined
Nov 11, 2015
So I am trying to figure out, how do I make the cloth parts of the Charles Rene outfit for Maewha disappear? I remove them in Photoshop and re-save them out as DXT5, but all it does is make the texture white. O.o Can someone tell me how it's done? Thanks.

EDIT: Nvm, I just made an amateur mistake, I forgot to edit the alpha channel as well lol. :P

Anyway, here's a peak at what I did, I am going to post more in the main forum when I have more pics ready :3

Mind if you share that outfit please? I'm liking it.
 

Jensen

Potential Patron
Joined
Jun 4, 2016
Yeah, that's definitely the reason why this is happening.
Unfortunately this means that this texture can't be patched.
You can try the solution I mentioned above. You'll get the same effect you want.

installed 1.5 and tried again, all works fust fine now
2016-07-13_1628887092.JPG
great work, cheers
 

temp33

Potential Patron
Joined
May 21, 2016
Hi, BlackfireBR. I just found this thread and say thank you. you are the hope and the light!

by the way, I got two questions.
1.
I fail to apply a file named 'pew_00_ub_0033.dds'. this is the upper side of Karlstain outfit.
the injector says 'unfortunately, there is no way to make them work.'
does it mean that
- it can be applied but not in the current injector version?
OR - it will never be appiled cause of the client protection?
OR - I tried applying a wrong(glitch, error) texture file?

2.
what if I try to edit the texture in the \character\texture folder ?
is it applied in tha game in real-time? or should I relaunch the client?
 

killabilly

Potential Patron
Joined
Apr 4, 2016
Sure, as soon as I figure out how to remove these stupid dots from what's left of the cape lol. I just left a post in the armor swapping thread asking on how to do that because I can't seem to get rid of them. O.o

Thirded!

For removal of dots, maybe try combining with textures used by Jeany?
 

BlackFireBR

Content Creator
Joined
Sep 2, 2013
Hi, BlackfireBR. I just found this thread and say thank you. you are the hope and the light!

by the way, I got two questions.
1.
I fail to apply a file named 'pew_00_ub_0033.dds'. this is the upper side of Karlstain outfit.
the injector says 'unfortunately, there is no way to make them work.'
does it mean that
- it can be applied but not in the current injector version?
OR - it will never be appiled cause of the client protection?
OR - I tried applying a wrong(glitch, error) texture file?

2.
what if I try to edit the texture in the \character\texture folder ?
is it applied in tha game in real-time? or should I relaunch the client?
1 - It will never be applied because the entry for that file simply doesn't exists in the pad00000.meta file. I don't know how the game loads the file because the .meta file is supposed to have an entry for each file of the game, but it simply there isn't that entry anymore. I'm still trying to figure it out why those entries are missing, and how to find them (if there is a way)

2 - No, you have to restart the game every time you make any changes.
 

temp33

Potential Patron
Joined
May 21, 2016
1 - It will never be applied because the entry for that file simply doesn't exists in the pad00000.meta file. I don't know how the game loads the file because the .meta file is supposed to have an entry for each file of the game, but it simply there isn't that entry anymore. I'm still trying to figure it out why those entries are missing, and how to find them (if there is a way)

2 - No, you have to restart the game every time you make any changes.


alright. the most hopeless answers to the both questions. haha :D
but I will admit the situation and still thank you for what you have done.
and I pray for you finding the missing entries even if it takes for years.
 
Last edited:

temp33

Potential Patron
Joined
May 21, 2016
sorry BlackFire. another question? :P

should we uninstall the injector before an update to the client? or do we not have to uninstall?
 

BlackFireBR

Content Creator
Joined
Sep 2, 2013
sorry BlackFire. another question? :P

should we uninstall the injector before an update to the client? or do we not have to uninstall?
Yes you should. Same thing as the other mods.
If you don't uninstall you will get the corrupted message and you're going to have to wait until the game re-checks your all your files.
It's not a problem if you don't, it will just take more time because the launcher will check everything just to re-download the pad00000.meta file in the end
 

temp33

Potential Patron
Joined
May 21, 2016
Yes you should. Same thing as the other mods.
If you don't uninstall you will get the corrupted message and you're going to have to wait until the game re-checks your all your files.
It's not a problem if you don't, it will just take more time because the launcher will check everything just to re-download the pad00000.meta file in the end

THank you!
 

Gone4Good

Content Creator
Joined
Sep 25, 2014
BlackFire you are one busy man to keep up with all these updates. I found out today that resorepless mods weren't reading the textures anymore, came here, and saw this. I am not looking forward to future updates for this game. -_-
 

Kera

Vivacious Visitor
Joined
Mar 29, 2016
Still having issues with 1.5 with the one stubborn dds file, did some digging in the source code trying to figure out what was up. Found out the headers weren't included in the 1.5 src drop, so no chance to build and/or debug it.

That said, since I do not know specifics about the composition of the .meta file structure which you might, I am not sure it is a problem, but it looks like the patcher assumes that the data stays int aligned throughout the file, since it scans the file in as an array of ints and then compares those ints to the hash rather than working with individual bytes. If something caused the serialization to shift by a word, it would make the scan stop working until the next word shift to re-align it.

Example, in case I am unclear, using 32 bit ints (since the hashes seemed to be signed 32 bit ints, though negative hash values seemed to be 16 bits of FFFF FFFF and then 16 bits of value?):

Search int value (as hex): 00AB CDEF
File contents: 0000 00AB CDEF 1234

In this case, the search value would be in the file, but the scan would not find it since the two individual int values are 0000 00AB and CDEF 1234, whereas scanning for the byte pattern 00AB CDEF would find the pattern starting at the second word.

The specific problem I am trying to solve is with pkw_00_uw_0001.dds, which is the maehwa default underwear texture. There is a second texture pkw_00_uw_0001_dec.dds that is the same texture with an alpha layer, which seems to have some usage in game, since when it is patched in as a blank texture with 100% alpha, some of the trim goes away as well as the bra, but not the panties. If I enable resorep to determine what textures are being loaded, it shows both being loaded. I was thinking the two could be referenced in the same data block, they might not be strictly aligned to int within that block, even if the block as a whole is a multiple of int in size to not cause alignment errors with the rest of the file.
 
Last edited:

BlackFireBR

Content Creator
Joined
Sep 2, 2013
Still having issues with 1.5 with the one stubborn dds file, did some digging in the source code trying to figure out what was up. Found out the headers weren't included in the 1.5 src drop, so no chance to build and/or debug it.

That said, since I do not know specifics about the composition of the .meta file structure which you might, I am not sure it is a problem, but it looks like the patcher assumes that the data stays int aligned throughout the file, since it scans the file in as an array of ints and then compares those ints to the hash rather than working with individual bytes. If something caused the serialization to shift by a word, it would make the scan stop working until the next word shift to re-align it.

Example, in case I am unclear, using 32 bit ints (since the hashes seemed to be signed 32 bit ints, though negative hash values seemed to be 16 bits of FFFF FFFF and then 16 bits of value?):

Search int value (as hex): 00AB CDEF
File contents: 0000 00AB CDEF 1234

In this case, the search value would be in the file, but the scan would not find it since the two individual int values are 0000 00AB and CDEF 1234, whereas scanning for the byte pattern 00AB CDEF would find the pattern starting at the second word.

The specific problem I am trying to solve is with pkw_00_uw_0001.dds, which is the maehwa default underwear texture. There is a second texture pkw_00_uw_0001_dec.dds that is the same texture with an alpha layer, which seems to have some usage in game, since when it is patched in as a blank texture with 100% alpha, some of the trim goes away as well as the bra, but not the panties. If I enable resorep to determine what textures are being loaded, it shows both being loaded. I was thinking the two could be referenced in the same data block, they might not be strictly aligned to int within that block, even if the block as a whole is a multiple of int in size to not cause alignment errors with the rest of the file.
My bad, here is the Source Code with all the files you need and some other helpful stuff:

https://www.undertow.club/attachmen...3/?temp_hash=edbb04fc41f14d4d434733fc47fe7554

This is a very valid point, and I thought about that a lot, since you seem interested to know how the meta file is structured, let me explain to you what I figured it out so far.

This is a very simplified version of the pad00000.meta file:
meta1.jpg



This is a small version of a meta file, with only 3 .PAZ files, 3 folders and 4 files. This is the basic structure of the meta file. The official meta file follows the same pattern, it just has more files in it ( a lot more).

meta2.jpg


Before we proceed, this is a few things we need to clarify:
- Each BIG Block represents 4 bytes.
- Each small block represents one byte.
- Red blocks with white background means this is encrypted and they will not appear like this, unless you decrypt those bytes.
- DUMMY is a number that I don't know what's for.
- ZSIZE and SIZE are still a mistery for me. Maybe is the size of the files.
- I'm not sure if I got the "file names" part right, it's strange they didn't put the fileNumber before the file name like they did with the folder names. If you want to see if I missed something, please see the quick bms code I posted in the end of this post.

This is the same file as the first image, but with all the numbers converted from hex to dec:
meta3.jpg

Meta injector, works only to find those "FILE_HASH" numbers. As you can see, before them, there are only ints, so even though some bytes get "shifted" after the strings with the folder names and file names, this is irrelevant because the information we are interested is before that, where there was no possibility for shifting.

And even if there was the 16bit - 32 bit problem you mentioned. I manually searched for those bytes using the hex editor, and the hashes are simply not there. And all the others the program finds them just fine.

Now let's understand how the game knows which file to load:

Let's pick the first FILE_HASH: 631490897:

- We can see it belongs to a file, which folder num is 2
- When we search for folder num = 2 in the "folders_part" of the file, we find that the name of the folder is "character/" ,so the file is in the "character" folder".
- next, we know the file number is 0, so the game will look in the "file names part" and when it finds the first '\0', if will know that it's the end of the file name we are looking for. (If file num was == 2, we would have to count 2 '\0', and everything that is between the 2nd and the 3rd '\0' is the file name)

So we discovered that the file with the hash 631490897 is "multiplemodeldesc.xml" and it's located in "character/"

One thing you should be aware of, when converting from hex to dec.
For example, the FILE_HASH we just used: 631490897
When you convert it to hex, you get this:
hex.jpg


But when you look at the meta file, you are not going to find 25 A3 C9 51, instead you need to find 51 C9 A3 25
hex2.jpg


So everytime you convert to hex, remember to change the order in blocks of 2 bytes.

Warning, don't do this mistake:
25 A3 C9 51 -> 15 9C 3A 52
it's:
25 A3 C9 51 - > 51 C9 A3 25

In my program, I read all bytes in blocks of 4 bytes (ints) so the conversion, for the program, is not necessary, but it is if you are doing some tests by hand and you want to check the numbers.

Lastly, but the most interesting thing. Let's take a look at the hash of the files that Meta Injector fails to patch:
fail2.jpg


Here are the conversion to hex:
Decimal - Raw conversion - Separated ------- Converted to Little Endian Notation
79844008 ---- 4C252A8 ----------- 4 C2 52 A8 --------------- A8 52 C2 04
5067198 ------- 4D51BE ------------- 4D 51 BE ------------- BE 51 4D 00
57369800 ---- 36B64C8 ----------- 3 6B 64 C8 --------------- C8 64 6B 03
87826479 ---- 53C202F------------- 5 3C 20 2F -------------- AF 20 3C 05
10383715 ---- 9E7163----------------- 9E 71 63 ---------------- 63 71 93 00

Apparently all the dec numbers that when converted to hex, have less than 8 digits, the entry simply doesn't exist in the meta file. (You can try to find it yourself if you want). Also, the folder number with that fileNumer as well is also non existent.
Example:
folder: 2745 file: 59798 = B9 0A 00 00 96 E9 00 00 (Doesn't exist)

but
folder: 2745 file: 59797 = B9 0A 00 00 95 E9 00 00 (Exists): Hash: BE 1D 0A 67 -> 670A1DBE -> 1728716222

All this information about the meta file, I learned by studying the blackdesert.bms file:
Code:
# Black Desert (script 0.2.2)
#   super thanks to Ekey
#   http://forum.xentax.com/viewtopic.php?f=10&t=10879
# script for QuickBMS http://quickbms.aluigi.org

# set the following to 1 for extracting the old archives
math OLD_ENCRYPTION = 0

quickbmsver "0.7.4"
comtype blackdesert

get EXT extension
if EXT == "meta"

    # pre-allocation, improves speed (doesn't matter if the values are bigger)
    putarray 0 0x4000  ""   # PAZs
    putarray 1 0x2000  ""   # folders
    putarray 2 0x80000 ""   # files

    get DUMMY long
    get pPAZCount long
    for i = 0 < pPAZCount
        get PAZ_NUM long
        get HASH long
        get PAZ_SIZE long
        string PAZ_NAME p= "PAD%05d.PAZ" PAZ_NUM
        putarray 0 PAZ_NUM PAZ_NAME
    next i

    get FILES long

    savepos OFFSET
    xmath TMP "OFFSET + (FILES * 0x1c)"
    goto TMP

    get FOLDERS_SIZE long
    savepos TMP
    math TMP_SIZE = FOLDERS_SIZE
    callfunction SET_ENCRYPTION 1
    log MEMORY_FILE TMP FOLDERS_SIZE
    encryption "" ""

    math TMP += FOLDERS_SIZE
    goto TMP

    get NAMES_SIZE long
    savepos TMP
    math TMP_SIZE = NAMES_SIZE
    callfunction SET_ENCRYPTION 1
    log MEMORY_FILE2 TMP NAMES_SIZE
    encryption "" ""

    #print "collect folder names..."
    math FOLDERS_SIZE -= 8  # lame
    math i = 0
    for TMP = 0 < FOLDERS_SIZE
        get INDEX_NUM long MEMORY_FILE
        get SUB_FOLDERS long MEMORY_FILE
        get NAME string MEMORY_FILE
        if NAME == ""
            break
        endif
        putarray 1 i NAME
        savepos TMP MEMORY_FILE
    next i

    #print "collect file names..."
    math i = 0
    for TMP = 0 < NAMES_SIZE
        get NAME string MEMORY_FILE2
        if NAME == ""
            break
        endif
        putarray 2 i NAME
        savepos TMP MEMORY_FILE2
    next i

    goto OFFSET
    for i = 0 < FILES
        get HASH long
        get FOLDER_NUM long # 48c
        get FILE_NUM long   # 9ea5 e18d
        get PAZ_NUM long    # 9ec c20
        get OFFSET long     # 4603c 261cc
        get ZSIZE long      # 4a70 1970
        get SIZE long       # 5f13 2000

        getarray PAZ_NAME 0 PAZ_NUM
        getarray NAME 1 FOLDER_NUM
        getarray TMP 2 FILE_NUM
        string NAME += TMP

        open FDSE PAZ_NAME 1

        math TMP_SIZE = ZSIZE
        callfunction SET_ENCRYPTION 1
        if SIZE > ZSIZE
            clog NAME OFFSET ZSIZE SIZE 1
        else    # yeah SIZE is < ZSIZE
            log NAME OFFSET SIZE 1
        endif
        encryption "" ""
    next i

else    # PAZ

    get DUMMY long
    get PAZ_FILES long
    get NAMES_SIZE long

    savepos OFFSET
    xmath OFFSET "OFFSET + (PAZ_FILES * 4 * 6)"
    math TMP_SIZE = NAMES_SIZE
    callfunction SET_ENCRYPTION 1
    log MEMORY_FILE OFFSET NAMES_SIZE
    encryption "" ""

    math i = 0
    for TMP = 0 < NAMES_SIZE
        get NAME string MEMORY_FILE
        if NAME == ""
            break
        endif
        putarray 0 i NAME
        savepos TMP MEMORY_FILE
    next i

    for i = 0 < PAZ_FILES
        get HASH long
        get FOLDER_NUM long
        get FILE_NUM long
        get OFFSET long
        get ZSIZE long
        get SIZE long

        getarray NAME 0 FOLDER_NUM
        getarray TMP 0 FILE_NUM
        string NAME += TMP

        math TMP_SIZE = ZSIZE
        callfunction SET_ENCRYPTION 1
        if SIZE > ZSIZE
            clog NAME OFFSET ZSIZE SIZE
        else    # yeah SIZE is < ZSIZE
            log NAME OFFSET SIZE
        endif
        encryption "" ""
    next i

endif

startfunction SET_ENCRYPTION
    if OLD_ENCRYPTION != 0
        encryption aes_128_cbc "\xF3\xA1\x0D\xF2\x47\xCC\x30\xC5\xEB\x11\x12\xAE\x07\x01\x52\x13"
    else
        encryption ice "\x51\xF3\x0F\x11\x04\x24\x6A\x00"
    endif
endfunction


If you need help understanding quickbms scripts, please refer to http://aluigi.altervista.org/papers/quickbms.txt, everything you need is there.


If anyone else can help me out to understand why this is happening, please let me know. You have all the tools and knowledge I have right now.
 
Last edited:

Users who are viewing this thread

Top


Are you 18 or older?

This website requires you to be 18 years of age or older. Please verify your age to view the content, or click Exit to leave.