Thanks for the quick replies! :)
spiritovod wrote:
CallDLL invokes C/lua/python code and compiles it on the fly. So yes, "return" doesn't exist in bms syntax, but can be used in С or other code, integrated into bms script (which is not the case here).
Alright, good to know, it's not my script, I'll create an issue on their GitHub page. ^^
spiritovod wrote:
As for parallels, I doubt it will work with quickbms if it's not designed for it (and in most cases extraction logic requires sequential execution - I mean not multiple files extraction, but memory allocation).
aluigi wrote:
Ah, there is no multi-threading because all the operations are sequential and need to be completed before going to the next offset/information (it would be also terrible for the I/O input other than impossible to program).
Well, I honestly only understand half of the stuff you're saying and I think I worded it badly, but having e.g. 4 instances of QuickBMS run with each extracting a different file can be significantly faster than having one instance extract all 4 files.
spiritovod wrote:
The reason why I've suggested modifing bms script is because currently it's using offsets as filenames - and while you're extracting all files in a single folder, there is non-zero chance that offsets (and thus filenames) will overlap in some particular cases.
I'm using the auto rename switch, should that not take care of it or am I'm misunderstanding something here?
aluigi wrote:
Yes, quickbms uses two separate streams for separating the important output (stdout/info) from the verbose information for the user (stderr).
Correct me if I'm wrong, but shouldn't stderr only contain something when there was an error? Either way, I'll just workaround the issue by checking if stderr contains the string "error" and if it does, I'll log it completely, otherwise I'll ignore it.