ZenHAX

Yes it's in my TODO list as last thing to implement before the release.
That feature would be interesting but I have some doubts about its implementation.
For example let's say that all the strings are dumped in a text file one-per-line and one of them is a multi-line string... in that case the reimporting would be not possible.
An alternative is placing a certain sequence of chars to divide each string like "###" or similar to limit the problem.

Then there are the size limitations because it would be just a reinjecter (the only choice for being a generic tool).

Basically the main benefit in this feature is just the possibility to translate games without using a hex editor.
That's the only benefit because the rest is just like a hex editor work.

true but \r or \rn can be easy to detect and simple implement replace it with something like [\r] or similar. I guess this is easy. Well to be honest everything is better then use HEX

That's a good idea too that allows to have everything in one line.
By using [\r][\n] I can even avoid to "parse" the string because it will be enough to make a replacement.

I have just noticed that after having added over 30 new algorithms the size of the final exe is almost 13 megabytes :O

Also 1 more thing, need to be able to specify the encoding as well mate.. Commons are Unicode, UTF8, ASCII, etc...

I have had some problems while trying to implement the unicode charset handling in the past.
Basically doesn't matter what charset I chosed because the result was ever the same or not matching the expected one.

I guess that this week I will release the new quickbms and then I will work on the string-related stuff for the next-next version.

I would like to add some compressions that may be available in RPGViewer and not in quickbms but I don't know the games and samples of these compressions, if you know them or remember something feel free to let me know.

Currently quickbms contains 517 algorithms

I have also finished the tasks I had for my TODO.

I'm evaluating the possibility of moving the source code of quickbms in another ZIP, maybe a quickbms_src.zip so that only who needs it will download it.
The reason is that currently the compressed "src" folder is over 4 megabytes and is totally useless (if not even confusing) to the final user.

agrees

QuickBMS 0.6.2 will be released in the next hours.
The RSA encryption, export/reimport of strings, charset encoding and that sort of offzip-like scanner idea will be implemented in another version.

QuickBMS 0.6.2 is now available:
http://quickbms.aluigi.org

The -d option is very useful but I guess that most of the users don't know it.
Unfortunately doesn't exist a way to automatically understanding when activating it so I have to leave it disabled by default.

I was thinking to automatically enabling it when, in GUI mode, the user select multiple files.
But I don't know what the script does and if the archive already include the full paths so if you handle archives that use the archive name as path, then it's good, but in all the other cases it's bad (for example a simple file decompressor).

Mah, just making some brainstorming but I think I will leave everything as is and it's job of the script to create the folder path based on the archive name when necessary (I guess it's not a very diffused technique).

I have just released QuickBMS 0.6.3:
http://quickbms.aluigi.org

Note that the support for string operations is not available yet because I really have no idea of how to implement it due to various things (automatic append mode, handling of unicode and non-unicode strings and so on).

I was thinking to something like the log command:
slog NAME OFFSET SIZE FILE_NUM UNICODE

But what to do if the data at that offset is unicode?
How to handle the append mode and the consequent warning to the user who should press 'a' to continue?

One idea may be to dump just unicode data by performing a conversion of the ansi/utf8 strings.
So, extraction: bytes -> unicode and unicode -> unicode
reimporting: unicode -> bytes and unicode -> unicode

I wanted to allow a way for dumping a string as-is like the getdstring command, but it's not compatible with the slog command.
It would have been used in situations like:
get STRING_SIZE long
getdstring STRING STRING_SIZE

that otherwise should be handled as:
get STRING_SIZE long
savepos OFFSET
slog FILENAME OFFSET STRING_SIZE
math OFFSET + STRING_SIZE # or goto STRING_SIZE 0 SEEK_CUR
goto OFFSET

Mah, let me know what you think

QuickBMS 0.6.3a
A small bugfix that is very important for the scripts that use the Strlen command.
Upgrade asap.

Is there any way to get a string of specified length (like getdstring) without stopping at a null byte? For example if I have something like:

68 00 65 00 6C 00 6C 00 6F 00          h.e.l.l.o.

And I want to get the string "hello".

If there is no way to do this can it be added in? Workarounds are possible but probably pretty tedious.

getdstring doesn't stop at NULL bytes.
Probably what you want is:

getdstring NAME 10
set NAME unicode NAME

"get NAME unicode NAME" gives an error but "set NAME unicode NAME" is probably what you meant, since that works.

Still a bit of an issue though. If I have:

4A 00 61 00 6E 00 00 00 00 00 46 00 65 00 62 00          J.a.n.....F.e.b.

Then it just gets "Jan". This solution doesn't seem to handle more than one byte in a row.

Yeah I meant set and not get
In your example is correct that it gets only Jan because it's considered a string.
In that case I would just use:
get NAME1 unicode
get NAME2 unicode

Hmm, ok. I guess I can work with that, it's not a huge issue. Thanks

Maybe give me some feedback about the decoding of utf16 unicode in utf8.
In the latest version of quickbms there is a codepage command that allows to choose the preferred charset (and it works) but I would like to have some opinion and feedback.

Here's something I thought might be useful in some cases: could it be possible to change the default FILENUM all operations are performed on? Something like this:

get NUM1 long # reads long from input file
deffilenum MEMORY_FILE
get NUM2 long # reads long from memory file

I think it would be easier for functions etc. to set the FILENUM like this rather than writing MEMORY_FILE after each command.