It would be difficult to implement that thing because all the files are just numbers in the bms language.
And the benefits are basically none.
You can just add a comment after each MEMORY_FILE to know what's meant for.
That would be nice if it's a separate tool than quickbms because it needs a different logic.
File rippers are difficult because sometimes there are no ways to calculate the size of the file, and scanning the magic values after the found one would produce many false positive.
I stay away from writing rippers
Instead, regarding the binary String feature implemented in the beta, I just noticed that it's not compatible with those situation where we have something like:
getdstring PATH 0x20
getdstring NAME 0x20
string PATH + NAME
The result is just the original PATH and not PATHNAME because in binary mode the whole variables are concatenated, so the result is 0x20 bytes of PATH followed by 0x20 bytes of NAME.
Not sure what solution I'm going to implement but probably a parameter specified by the user for setting the binary mode.
Currently String has '0' as special prefix for the operator, what about using it also for the binary mode?
Like: string PATH 0+ NAME
Obviously the mode using NUL-delimited strings will remain the default as it is now.