^ Well, the AWAD archives were stored as an .awd container last time I checked the filesystem(the disk in which they were stored, not the filesystem of the archives themselves) of the PS2/PC version of Tomb Raider Angel of Darkness.

Eh JIT would be cool but a core rewriting of quickbms is not possible, it takes a huge amount of time and effort for both writing and testing. Really impossible at the moment.

And how about bytecode approach? Would be great to have such function to compile script into binary file and then feed it to quickbms. Maybe it won't be blazingly fast but still can give some speed boost.

To be honest there will be no big core improvements or rewrites in the tool, currently it's stable and works perfectly.

People have problems with the performances of quickbms only when they try to use it not for its original purposes like 3d models conversions, that's NOT the job of quickbms which is an extractor and possible reimporter, for any other usage people have to use a real programming language.

In case of decryption functions that require the reading of every byte from a file and so a similar "for" cycle would be slow in quickbms I suggest to create a dll or dumped function to use with CallDLL.

How about converting readme into chm help file? It is pretty big already and not so convenient to use anymore. I think chm would be much better than basic txt which estimated size of 188 kilobytes already. Lol my first computer had 4-times less RAM than this.

Also I think, quickbms deserves to have its own IDE, because all those bat files such a pain in the ass to create each time, especially when you reversing many different file formats. Once I had more than 20 different scripts in one directory and each of them needed its own bat, also some of them where made for batch processing, some for testing and some for combining few scripts into one workflow, real pain it was...

chm no, but html would be perfect.Maybe for the next version I can create a parser to convert the txt in html and uploading the latter on the website, leaving the txt in the package (better to have both).I will think about it.

Honestly I don't know that thing of the bat files.quickbms is made to work easily with multiple selection of input files so I don't know why people create them, I'm not part of the modding community.

For the file format analysis you need just the console, less (the unix/cygwin tool), a hex editor and the bms language for Notepad++.That's all you need to rule the formats

For the file format analysis you need just the console, less (the unix/cygwin tool), a hex editor and the bms language for Notepad++.That's all you need to rule the formats

Actually it's more complicated than this when you need co crack every file format used by the game. I did it few times already so I can tell you that it is not enough to have only those tools which you mentioned.

You also need:Memory editing tool (ArtMoney or CheatEngine), it helps a lot to figure out the most puzzling data.Raw image viewer and some 2D editor with palette support. Raw image viewer also can help to identify types of data.Some 3D viewing software.Raw audio stream player.And last. You need to write some helper scripts for data collecting, visualizing or converting it into human readable form.

Without all this you will end up in a big frustration with little result. The hardest part is to crack level format. Try to do it with only hex editor, it will be very unproductive job.

I'm referring to using quickbms for extracting files from archives, which is the job of quickbms and for which you need a very minimal set of analysis tools like those I listed (debugging excluded).

Instead from your post I understand that you want a complete suite for modding, so quickbms would be just one of the tools (I hope you don't use it for converting formats).I still don't understand what type of IDE you suggested and what it should contain.If you mean something like integrating all these formats viewer in quickbms... well definitely no. Not the job and purpose of the tool.

If HASH was a sequence of bytes you had no way to use it with Findloc because the "binary" type is handled when the script is parsed and not at runtime (because quickbms is composed by these 2 internal stages).Luckily there you have a "long" HASH so you can try replacing "binary" with "long" and it should work because I implemented this method in Findloc.

However, I want to write one part of the output file with putct by selecting an offset to write the string with(0x58 for example) rather than building from another variable in which the offset is based on. Perhaps it`s (im)possible to do this with putvarchr, or do you have any other ideas?

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