Eh, unfortunately not all the TotalCommander plugins can be easily supported.When I tested this feature many years ago (far 2010) I had success with many TC plugins but those more complex relying on specific TC features/functions/callbacks can't work correctly. I guess InstallExplorer is one of them.

I'm quite surprised someone uses this feature of quickbms I never received feedback about it.

Anyway regarding InstallExplorer, it's a jurassik plugin that has been superseed by other standalone tools for the specific installers (innounp for InnoSetup is one of the main examples).

Maybe I can take a look at some TC plugins for the next release but it's just for curiosity rather than for real interest (so yeah the WONTFIX tag is probably correct).I have not checked the crash, is it in the quickbms code or in the plugin that it's looking for a missing callback?

Oodle has long history of compatibility problems of its own algorithms, it's enough to check the changelog:http://www.radgametools.com/oodlehist.htmWhat I mean is that data created with a version of oodle may not be compatible with other versions (even newer versions).Quickbms 0.7.7 uses oodle 2.3.0.

Anyway quickbms simply calls OodleLZ_Decompress on the data "as is", it performs absolutely no operation on the bytes of the input data (that happens only if you specify a raw algorithm, not the default behaviour).

the chunks are from the same archive.quickbms decompressed 19gb from the file fine then failed on everything for the remaining 12gb starting at this sample here.this is ps4 sample.looks like it might be the 2.40 version they used.Oodle 2.4.0 is up--New Hydra automatically selects Kraken/Mermaid/Selkie and new Mermaid+ compressor with slightly higher compression!

Unfortunately 2.3.0 was the only oodle dll available on Warframe when I released quickbms 0.7.7Currently the 2.4.1 is available but I don't know when I'm going to work on the next quickbms.In your case it's probably more easy to write a simple tool from scratch, after all it's just one API to call... ok it's not that simple to be honest because in the past the oodle developers changed even the prototype of the main API! :O

Just thought about something... Few times I had problems with break operator, those problems often was solvable, but sometimes they give real headaches, so I have idea about solution for this problem. Why not add labels for the cycles? And when we need to break some cycle then we could point break to the label of that cycle.

Also I think that labels for the script in general are also needed, this could help a lot in writing custom decompress functions, because disassembled code often can have lots of branches and it is not that easy to unwrap such code, there also can be some platform specific optimizations inside that code which gives even more confusion. So labels are must have in such situations.

Compression and custom encryption algorithm should not implemented in bms language.The correct way is dumping the function/dll (maybe in a MEMORY_FILE to avoid external files) and using it with CallDLL.

Labels for the cycles?The language is meant to be simple and as close as possible to the original one.

Then how to fix that very annoying bug in the other way? Sometimes break is pretty much useless in its current state, either it doesn't work as it should or gives unpredictable result, but many decompression algorithms rely on break in the cycles, there is no other solution for such cases.

The work-around I use when I need it (rarely to be honest) is an OK variable set to 1 by default, and set to 0 when I have to break or I set the initial value of the cycle to a value that causes its termination (for example i = 9999 if for i = 0 < 100).

Just curious, what compression algorithms are you implementing in bms language?I bet it's graphic stuff, right?

Compression and custom encryption algorithm should not implemented in bms language.The correct way is dumping the function/dll (maybe in a MEMORY_FILE to avoid external files) and using it with CallDLL.

Dumping function from where to where? From MIPS code to where? Or from PowerPC? Or from ARM? Games exist not only for PC, don't you understand it? And the only way is to disassemble game's native code, find decompression routine and translate it manually into human readable code. If quickbms can do so many things then it should handle the most basic functions flawlessly. Otherwise why you implemented all those functions at all?

"break" wasn't available in the original language.So can't you just translate the reverse engineerd function into C code and use it (yeah "dumping" since there is no need of dll if it's simple) with calldll?

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