Working on v0.8

[jicsmart]

0.7b21dev IMHO this version is for testing proposes.
can convert stringtable.bss but can't working for all files. (at least stringtable.bss may can use with some,no time to check) like u said before.
ps. I can see what is in stringtable.bss

[KAMIKADzE]

0.7b21dev IMHO this version is for testing proposes.
can convert stringtable.bss but can't working for all files. (at least stringtable.bss may can use with some,no time to check) like u said before.
ps. I can see what is in stringtable.bss

Yep, as I mentioned in the post - there's basically no "single standard" for all of the files, I'll need to create converters for all of the "types" (stringtable.bss is a collection of tables, there are also just tables, and some have even different structure, which I haven't figured out yet). I'll try to make the least amount of converters as possible (leave differences on scheme). I could also make a single converter that would decide based on the file name (the files themselves do not contain any kind of "structure-scheme" whatsoever, not even an ID that would distinguish them), but that would be a rather stupid idea IMO.

[KAMIKADzE]

Updated the development version.
Now you can manually add multiple schemes for bss files. That said I haven't added any new "type".
I'll briefly explain the default one:

Code: Select all

"Data_v3": {
    "stringtable": {
      "Keys": {
        "Index": "int",
        "^StringFormatKey": "string"
      },
      "Values": {
        "~StringFormat": "string"
      },
      "Structure": "Set",
      "Actions": {}
    }
  }

"Data_v3" is a cluster for all future ".bss" schemes. This name should always remain the same.
"stringtable" - name for the ".bss" schemes. It will appear in "BSS Converter scheme" dropdown list. This name should be unique.
"Keys" and "Values" - works just like in other schemes. The only difference is that here you need to specify the type of cells, currently available types:

• int
• long
• string

^this tells converter on how to handle data, so make sure that you specify a proper type, and that keys/values go in the right order (I might add order number field in the future, if that will be required).
"Structure" - tells converter which structure to use during conversion. Currently there's only "Set" added, which indicates a set of tables with the same columns (e.g. just like stringtable.bss).
"Actions" - currently has no use, since there's no merging based on those schemes yet. Even though that it's of no use, it should be present in scheme.

Remember that this is a dev version for a reason, and all of that^ is a subject to changes, since I'll try to find a middle ground of versatility/usability/ease/futureproof/etc..

[KAMIKADzE]

Applied a minor update to development version, that covers the recent BDO KR changes.

[jicsmart]

It's not a big deal to release .7b21 or 22.
this 7b20 is good enough.(.7b21dev too)
we can wait for 0.7c or 0.8.

[KAMIKADzE]

Today I've started the work on BDO Patcher repack style, there's nothing to be excited about yet, just a few steps.

Other than that, I've cleaned the mess in File Cryptor, which was already working fine for quite a while, so I decided to update development version with File Cryptor opened for public testing.
I've already briefly explained File Cryptor in THAT post. The result of Encryption will be saved in the same folder as the original file + with the same filename + ".lfc" extension (shortened from Launcher File Cryptor), it won't rewrite any file, even if the file with expected file name already exists. The extension is not required and can be changed or removed at all, the decryption will work anyway, but note that decryptor will rewrite file if the expected filename+extension already exists (this won't be the case in the release version).
Also first option "Include file extension" made its appearance in File Cryptor settings, basically this will save the original file extension along with file, and the resulted file after decryption will gain this extension, if this option isn't checked then the resulted file after decryption will be created without extension. The next option in plan is the inclusion of file name, so that if both will be checked and the original file name was "File.txt", then after encryption "File.lfc", and then you renamed it to "Oh.my" - you'll still get "File.txt" after decryption. Uncheck those options in order to save space (obviously inclusion of extension, and in future - file name, will increase file size insignificantly).
File Cryptor is fully functional as of now, except that it will "freeze" Launcher for the time of Encryption/Decryption (this won't be the case in the release version), so if Windows will say that Launcher is unresponsive - don't close it, you can see that it's working by looking at constantly increasing output file size (the "freeze" won't be noticeable for small file sizes).
There's no size limit for the files that can be encrypted/decrypted, other than the limits imposed by the file system (e.g. NTFS/FAT32/etc.).

Feel free to test File Cryptor as you like. Would be happy if someone could try to crack encrypted file "without knowing the passwords". Also feel free to notify me about any problems, other than those^ mentioned in this post.

[100sual]

With encryption, we can change the file in paz, using the header to point out that it is not compressed. Can you make a tool that returns the bexcel pattern? would be in this case, datasheets.xlsx to bexcel. It would be perfect to get back the translation of the Korean English patch to 100% (or close to that)

[KAMIKADzE]

With encryption, we can change the file in paz, using the header to point out that it is not compressed. Can you make a tool that returns the bexcel pattern? would be in this case, datasheets.xlsx to bexcel. It would be perfect to get back the translation of the Korean English patch to 100% (or close to that)

Not possible like that, languagedata.xlsm doesn't retain all of the data required to produce bexcel. That said - I'm also working on an intermediate format, that will contain all of the required data + will be mergeable with languagedata.xlsm, but there's no ETA for that, just like for repack and everything else, cause I don't have a lot of time to spare on Launcher development lately.

[100sual]

I understand. Thanks for the answer. I just wanted Pearl to re-use the bss files. They were easier to manipulate.

[qwerty]

Tested your file cryptor. Haven't had any problems with it.