Possible next features of QuickBMS

[aluigi]

What you mean with text files?

The problem described by michalss with the DLL was about the memory allocation method which is custom in quickbms and created a conflict when the dll is used in other tools.

[Shokoniraya]

What you mean with text files?

The problem described by michalss with the DLL was about the memory allocation method which is custom in quickbms and created a conflict when the dll is used in other tools.

mean?
i mean, can we write code for export and import text files from a binary file?
i know that i asked before. but i just really glad to see that quickBMS can turn to a better tool for modders or file editors (actually thanks to you for all of this stuff)

i just want to know can i write a script for export text in a .txt file in new version? from a file like decompressed localization file?
because i know some algorithm for some localization file and dont know any other programming skill

and one other think; i know, in this times, maybe i asked alot and sorry for that, really i am

[aluigi]

Ah, that's already possible with the Slog command.
It does magic things BUT reimporting is limited to the original string size if the strings are in sequential order (since you can't allocate new space in the middle of the file).
If the strings is referenced by offset, reimport2 can import a new string of any length.

You can find all the information about Slog in quickbms.txt:

Code: Select all

SLog NAME OFFSET SIZE [TYPE] [FILENUM]

    This command allows to export strings to an output file and being
    able to reimport them later with reimport.bat.
    The reimporting feature of this command has the same limitations of
    the global one, so you cannot reimport strings that are longer than
    the original.
    Currently QuickBMS will simply tell you that the new string is longer
    without interrupting the importing so pay attention.
    The space between the end of the new and old string will be filled
    with zeroes but this behaviour "may" be changed in future to avoid
    situations in which there are sequential NULL delimited strings and
    using zeroes will causes problems in the software that reads the
    file. Anyway in these situations you can just insert the spaces by
    yourself in the new string.
    The dumped strings are handles as C strings, basically the '\' char
    (backslash) is an escape that allows you to specify any byte you
    desire, the \r and \n you will see are just the 0x0d and 0x0a bytes
    that allow to insert the whole multiline string in one line.
    Each line is an exported string.
    Notepad++ highly suggested.
    Small tip: Use INS (the replace character) mode of your text editor
    for editing the string file to reimport so that you will have no
    problems with longer new strings.
    The SLog function is new so any feedback and suggestion is highly
    appreciated.

    Arguments:
        NAME    Name of the output file. It will be created from scratch
                the first time and then will be used in append mode from
                the second line on. Automatic, simple and error-proof.
                The output file is just in UTF-8 with Windows line feeds
                ("\r\n") and the conversion of unicode strings is performed
                by QuickBMS automatically with the codepage in use
        OFFSET  The offset where is located the string you want to dump.
                >=0 works just like the other *log commands and dumps
                    the string located at that OFFSET, it doesn't change
                    the current offset
                <0  dumps the string at the current offset and updates it,
                    so it advances in the file
        SIZE    >=0 it works just like the Getdstring command allowing
                    you to dump a string of a certain amount of bytes
                <0  just like the Get command
        TYPE    This is the type of data to read just like the Get
                command, if not specified it's considered String. You can
                dump most of the types and even the non-string ones so if
                you use the Long type you will have the decimal value easy
                to edit inside the output file
        FILENUM the input file

    Examples:
      # the test file is available here http://aluigi.org/bms/slog_test.dat
      set STRINGS_FILE string "strings.txt"
      slog STRINGS_FILE -1 0xb string
      slog STRINGS_FILE -1 -1
      slog STRINGS_FILE -1 -1 long
      endian big
      #slog STRINGS_FILE -1 -1 unicode
      slog STRINGS_FILE -1 0x18 unicode
      slog STRINGS_FILE 0x2e -1

You can set NAME as "" and quickbms will automatically use a txt output filename:
slog "" -1 -1

[Shokoniraya]

yes, thats the problem, cant import in bigger size
you know... some files does not have any offset, any...
my question is: quickBMS will support this option in future?

i dont say change reimport2, as i know, reimpor2 already is done and perfect for do with offset in normal files
but i say add a option like reimport3 mode for break this limits, if you worry maybe file will turning to an corrupt, i must say when i editing a localization file in hex, file can work verry well in game and just has SIZE, not offset.
please do somthing or at least say quickBMS will support this option in future?

[aluigi]

It's technically impossible.
Sequential data doesn't have an offset and it's impossible to inject bigger data without breaking the whole rest of the format.
Yeah sure some very very simple formats that are 100% sequential would have no technical problem but it's a very very limited case, by experience they are rare, and in that case would be easier to do it by hand with a hex editor.

[Shokoniraya]

It's technically impossible.
Sequential data doesn't have an offset and it's impossible to inject bigger data without breaking the whole rest of the format.
Yeah sure some very very simple formats that are 100% sequential would have no technical problem but it's a very very limited case, by experience they are rare, and in that case would be easier to do it by hand with a hex editor.

just add a command option for breaking the whole rest of the format (for very very simple files like text without offset!
just add a option! not change other option
please do something about that, it is really on my mind and there is a lot of file and i cant make it possible with reimport2! just add a command options to break it! a command like -texter
really on my mind !

every time and every second and every hour! on my mind!

[aluigi]

What I meant with my example is a file with sequential unreferenced (no offset and no size) that you can edit even with notepad++.

ANY other type of file that uses references (offset or size) CANNOT be forced OR requires accurate manual hex editing or just rebuilding from scratch.

Hope it's clear now

[Shokoniraya]

for example
look at this zip file (its possible to make good scripts for texts, if you accept it

should i do these with all of simple text whit hex ! one by one! my time! my head! or maybe i get a wrong number, then game will close! taking a loooooong! (that is why its really really really on my mind!!!)
but hex is OK for big archive or 20 or 30 files, because we dont want to edit all files in archive, just for modding a texture or replace a binary template, just if file dont have any offset... but what about text? or a lot of simple files? yeah, easy with hex but taking soo long, i am working on modding a game and has 153214 simple file without offset! take 15 week to set all of them or more! my mind! game has .png and its not dds and cant add same size!
please do something in new release!

add a option with name ( -reraw ) or anything you want (or a better idea! add in bms... rlog? like slog or clog? (rlog = raw log) )
and add this things to this options:
-add replace raw file (not add a new offset in end of file)
ikow, ikow... maybe some archives will be corrupt for that, but people must use reimport2 (-r -r) in archives, not this option (because maded for files without offset, right?)

and its possible, and i cant believe... and because i know its possible... (in real, not by believing, can do it)

[michalss]

for example
look at this zip file (its possible to make good scripts for texts, if you accept it !)

should i do these with all of simple text whit hex ! one by one! my time! my head! or maybe i get a wrong number, then game will close! taking a loooooong! (that is why its really really really on my mind!!!)
but hex is OK for big archive or 20 or 30 files, because we dont want to edit all files in archive, just for modding a texture or replace a binary template, just if file dont have any offset... but what about text? or a lot of simple files? yeah, easy with hex but taking soo long, i am working on modding a game and has 153214 simple file without offset! take 15 week to set all of them or more! my mind! game has .png and its not dds and cant add same size!
please do something in new release!

add a option with name ( -reraw ) or anything you want (or a better idea! add in bms... rlog? like slog or clog? (rlog = raw log) )
and add this things to this options:
-add replace raw file (not add a new offset in end of file)
ikow, ikow... maybe some archives will be corrupt for that, but people must use reimport2 (-r -r) in archives, not this option (because maded for files without offset, right?)

and its possible, and i cant believe... and because i know its possible... (in real, not by believing, can do it)

You kidding us or what, to there is already option to replace raw file in archive for god sake, luigi told this many times, dont get what you want anymore and i highly doubt you know it yrselfe... qbms can do exatly you asking so what is the point to get this any futher.. Extract files where are no any offset, etc.. is only matter of the script not capability of qbms..!

[Shokoniraya]

not kidding, i swear! then where is the option? where?
can you tell me how can i import more size with a file without OFFSET? then tell me...

i want to kill my self

[aluigi]

In the 3 files you provided in text.zip only text.localer is a format-less sequence of strings, just the one I said in my last post.
It's the only file that you can edit (rebuilding is better) without screwing the format.
If you don't want to make the work by hand you should write a program by yourself.
Even a script for quickbms may do the job because the format is extremely simple, one for extraction and one for rebuilding (yeah "rebuilding" not "reimporting").

This script automatically does both:

Code: Select all

endian big
get EXT extension
get ARCHIVE_SIZE asize
if EXT == "localer"

    for OFFSET = 0 != ARCHIVE_SIZE
        get SIZE short
        slog "" -1 SIZE
        savepos OFFSET
    next

else

    log MEMORY_FILE 0 0
    append
    for OFFSET = 0 != ARCHIVE_SIZE
        get TMP line    # removes the tabs/spaces at the end
        strlen SIZE TMP
        put SIZE short MEMORY_FILE
        putdstring TMP SIZE MEMORY_FILE
        savepos OFFSET
    next
    append
    get SIZE asize MEMORY_FILE
    get NAME basename   # removes .txt
    log NAME 0 SIZE MEMORY_FILE

endif

The reason why the rebuilt text.localer is different than the original is simply because "get TMP line" removes tabs and spaces at the end of the input, like the string "Successfully defended. "

[Shokoniraya]

then add such tag in new version for test, ok sir aluigi?
i want to say thank to you

just a test on new version,
in new version, add raw replacer tag to break this limit in reimport 2 (add a command tag, like -w and others), for test
its verry useful for text and single raw

[aluigi]

@Shokoniraya
I don't know how to tell you in other ways so I give up with you.

Write your own program for rebuilding and doing your custom editings.
Hopefully now it's all clear.

P.S.: I want to give you an answer anyway, that type of editing you have in mind (replacing 10 bytes with 100 by shifting the content of the file of 90 bytes) is not simple and extremely inefficient to do since quickbms works on the file on disk and putting new data in the middle means copying the portion of file from that position till its end byte per byte. Do it for N strings and you can imagine the operations performed, all for something that "may" work on the 0.01% of the situations.
That's why I suggested you to create your own rebuilder.

[Shokoniraya]

@Shokoniraya
I don't know how to tell you in other ways so I give up with you.

Write your own program for rebuilding and doing your custom editings.
Hopefully now it's all clear.

P.S.: I want to give you an answer anyway, that type of editing you have in mind (replacing 10 bytes with 100 by shifting the content of the file of 90 bytes) is not simple and extremely inefficient to do since quickbms works on the file on disk and putting new data in the middle means copying the portion of file from that position till its end byte per byte. Do it for N strings and you can imagine the operations performed, all for something that "may" work on the 0.01% of the situations.
That's why I suggested you to create your own rebuilder.

ok, its end here... thanks you anyway

[Shokoniraya]

Alugi, i think You are not understand
i just say enable a tag for slog! no log!

if text have offset, then we dont need to do it with this tag, because we can do it with reimport2 and make a new offset in end of file at last offset (end of the file)
if text dont have any offset, then enable tag in cmd and replace raw_file (set a error in black screen and tell please use this tag if string dont have offset and imported string is bigger then original)

i mean new tag must replace raw file(text string) in slog! in offset, we can use -r -r!
in other hand, slog created for text, not archive. then you can do

im talking about text without any offset, not archive! YOU totally GOT THIS WRONG! (text, not archive!)

Archive is ok, text is problem!

[aluigi]

@Shokoniraya
Why did you remove your posts???
It's very unpolite and an offense to all the people who spent and wasted their time with you.

You are going really too far with this thing and with all your posts about the same things that have been already explained, but you don't understand.
Please stop and learn a programming language.
DO NOT USE quickbms.

*edit*
All your edits have been restored, do not do it again. thanks.
Don't get me wrong, I'm very happy when people provide suggestions, feedback and new ideas, but in this case what you need is a programming language.

[Shokoniraya]

@Shokoniraya
Why did you remove your posts???
It's very unpolite and an offense to all the people who spent and wasted their time with you.

You are going really too far with this thing and with all your posts about the same things that have been already explained, but you don't understand.
Please stop and learn a programming language.
DO NOT USE quickbms.

*edit*
All your edits have been restored, do not do it again. thanks.
Don't get me wrong, I'm very happy when people provide suggestions, feedback and new ideas, but in this case what you need is a programming language.

thank you! that was exactly what I wanted to know!
thank you aluigi, for give such good tool for archive
Ghost Dead told me use Lua, and i saw a lot of guys using lua for text and im going to learn Lua,

thank to GHOST DEAD too, because he showed me the best language for text

[aluigi]

Learning Lua will give you also a big advantage in modding because most games use Lua inside.

[aluigi]

QuickBMS 0.9.1 is finally out
http://quickbms.com

(or directly the https link if you are on untrusted wifi: https://aluigi.altervista.org/quickbms.htm)

[michalss]

QuickBMS 0.9.1 is finally out
http://quickbms.com

(or directly the https link if you are on untrusted wifi: https://aluigi.altervista.org/quickbms.htm)

Man it works looks like compress algos works ok now Nicely done .. Thx a lot