Seems that apparently comtype_scan2.bat doesn`t work with me anymore.I mean, when I execute the .bat file through command-line... it just doesn`t run on folders that has symbols and numbers. And that`s on Windows XP.

Code:

1. Type this and press enter.C:\Documents and Settings\AnonBaiter\Desktop\quickbms_0.8.0>comtype_scan2.bat2. Even when the .bat file in question is executed(and even when there are parameters involved(comtype_scan2.bat comtype_scan2.bms dump.dat c:\output_folder)), it does nothing.C:\Documents and Settings\AnonBaiter\Desktop\quickbms_0.8.0>

Hello sir Luigi Auriemmaevery moment contact with you is so honorable for me after all dear Luigi i come with a crazy offer !i hope some kind of confirmation from you ?adding a new function or element that i called it DOSWINDOWi want to say the DOSWINDOW is an advanced case of print command !in fact a command that allow users to open as many dos windows they need linked to quickbms !in other words these windows will work very similar to your MEMORY_FILEs or TEMPORARY_FILEs with the exception they are smaller and are manipulative by users for versatile purposes !i believe this concept will increase interactivity of qickbms exponentially !making of them are so simple and just a few functions of like printf , scanf ...the advantage of doswindows is that they can easily arranged by operating system itself and may be they can be colorful also as you know the full screen of a doswindows can be copy pasted as text ......for example user can make a window for hex view of a portion of an archive in a specific offset !windows that list all variables used by quickbms and show their value or their content ! (debugging)or another window for manual editing cells of an array !as well as the process of re importing Archives can become more customizable !i guess there is many benefit ?even the bms script itself can opened in doswindow (colored code) pluse a separate window that contains listed bms functins that they will inserted just by pressing enter button in the code window and another window for list of compression algorithms and one for list of encryptions ... and in the end i have a dream to write bms script while qickbms attached to the archive and by adding each line of code at the same time i see the value of the variable or when i define an offset i see the hex section of that archive offset ...============================DEAR Luigi Auriemma i apologize if my idea looks foolish and the verbose text cause headache .

Many time ago I had in mind to implement some step-by-step debugging feature for showing information like the current content of the variables and the content of the input file at the current offset in some windows.The idea was abandoned because the time and effort for implementing it is not worth the real advantages it gives.For example for me (I mean for the personal use I make of quickbms) it's enough the -V option together with the "less" tool, never had the need of additional debugging in all these years

I'm new to QuickBMS, and while I have tried to search the forum for my doubt, I have found only a single reference to dictionaries (as pairs of key + value, being keys unique, and where you can retrieve values given a key) as a question from chrrox in this thread: http://zenhax.com/viewtopic.php?p=3370#p3370

I tried to create a bms script to handle .obsp files to help Zeleboba as per this post: https://zenhax.com/viewtopic.php?f=9&t=6927, but the file structure includes a dictionary of 64 bits keys + string values in a way that certain keys are used several times in the files content, and supposedly must be replaced by the corresponding strings. I know that such a complex file format maybe not the best point to start coding bms scripts, but I'm used to coding in several languages and I think I understand how to create bms scripts; it is just that the needed dictionary seems a handicap... And that is needed also for another file formats for the same game (The Guild 3).How would you approach that?

I actually don't need to use QuickBMS for this, as I already coded my own tool for this file format, but I'm curious and maybe it could be handy for another file formats in future, for my own use and/or to share it.

And then using getarray accordingly but it's just a waste of time, searching a specific key many times will be very slow.

In the example you provided then you don't have just a list of keys and values, you have a full structure with nested elements (json) which is a completely different thing.*edit* sorry I was referring to your example meant as json output handled as input.

You don't need to create key/value pair to spit out a json output from those obsp files, it's enough to parse them with a nested function and printing the output in json format like you did.It's very easy to be honest, I do that many times with some archive formats

I wouldn't since that's not the job of quickbms Extracting data from a binary file: ok.Handling json, strings and other textual formats: not (or at least not easily and 100% compatible).

I guessed it, but thanks anyway for the answer.

aluigi wrote:

In the example you provided then you don't have just a list of keys and values, you have a full structure with nested elements (json) which is a completely different thing.

Well, in fact the dictionary of strings contains both the filenames and the strings used inside each file, so if just unpacking to extract the files in binary form, it could be done without using the real filenames and full subfolders path, if not using the dictionary. For another file packages (.oppc), the content is a bunch of related meshes, textures and descriptors that forms a single or a multiple 3D element, so just the descriptors uses some nested properties (like json), but the different parts can be assembled into 3D objects by reading into that nested properties how all parts are related (the walls, the roof, etc, with their respective coordinates and other properties).Also the keys are some kind of 64 bits hash (same string in different files uses the same key, so I guess it is a hash), but with an unknown algorithm; unknown for me, it is nothing I have tried, including any type of Checksum, so I am unable to pack different files, if not using same names (by using the same hashes).Anyway, I coded a tool in C#, able to unpack and then even to translate the unpacked files into human readable text files (not polished the last part, as there are at least 2 different byte codes to produce different types of arrays, but at least to give an idea).

Yeah good idea.I solved the problem by simply allowing the -. option to do the job without additional commands.That option is used for continuing the execution of quickbms in case of errors so it fits the case since MEMORY_FILE reimporting is not possible and this is a way to "bypass" it.This feature will be available in quickbms 0.8.2 that I will release in the next days.

Ok guys, do you remember the idea of an alternative reimporting mode that appends the new file at the end of the archive and rewrites the fields containing offset, size and possible compressed size?Quickbms 0.8.2 will have this new mode available as experimental by using -r twice like -r -r

It was very simple to implement this mode by adding few lines of source code and worked immediately in my tests.That doesn't mean it will work in ALL the situations due to the obvious limitations of the various formats existent but if there are no MEMORY_FILEs involved and no operations on the offset/size/zsize fields (so "math OFFSET * 0x800" will not work), it should work correctly.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum