Possible next features of QuickBMS

[Zim]

What about add a possibility to:

1. Print a percent sign '%' both via print and string VAR P VAR. Maybe like '\%' or similar to printf (string p) '%%'?
2. Separate (via redirection) print result away from console output of other commands like log (list of output files) etc. As far as I see, currently QuickBMS debug log passes to std_err, and console output of any BMS commands to std_out. Sometimes we wanna inform user by print messages only which might be missed by him because of a huge number of output files
   For example this way:
   
   • Add quiet mode (command-line option) to QuickBMS:
     only print result should pass to std_out, and output of all other commands to std_err together with QuickBMS log;
     
   • Or add redirection feature for any/console outputting BMS commands (I don't think it's worth the effort).

[aluigi]

1)
good idea, I will use %%

2)
currently the error messages are sent to stderr while the output of Print and the essential information (*log and so on) go to stdout.
basically you need an option to replace any stderr usage with stdout?
if you have written a gui that uses quickbms you can just read stderr easily.

[Zim]

No, I meant exactly what I said - an option to separate output of print command from output of any other commands.
So the better way is this "quiet mode" command-line option (like -q I guess):
output of print => stdout
output of any other commands (log, etc) + error/debug messages => stderr

So we will not have any output to stdout at all except forced by print command (in quiet mode we can treat print as a forced output).

Thus we will be able to redirect stderr to file or nul and we'll see ONLY output of print command in the console (stdout) / similarly for our GUI.

We have a verbose mode, so why not to add such "quiet mode" too

Also when I said "what about add" I meant "Could you please"

1)
good idea, I will use %%

Be careful with parsing %VAR1%%VAR2% then

Also support for Array[i] in xmath would be nice too

[aluigi]

ok for the -q option

[einstein95]

Like how there currently is codepage to choose the codepage to decode unicode strings as, can a way to convert a string to another string using a codepage be added? I'm currently dealing with archives which use a Shift-JIS string for the filename and one file always has Japanese in the name.

[aluigi]

I guess it works also in encoding because the g_codepage field is used in both uf8->16 and viceversa.
Have you tried it?

[einstein95]

Hmm... I'm not seeing a way of doing utf8->16 in quickbms.txt, as it only says for doing ascii->unicode and whenever I do that it ends up as garbage.

[aluigi]

The only way is using put or putct on a memory file to perform the conversion, for example:

Code: Select all

set VAR_STRING string "hello"
log MEMORY_FILE 0 0
put VAR_STRING unicode MEMORY_FILE
putct VAR_STRING unicode -1 MEMORY_FILE

[einstein95]

Okay, so I'm using this which should work, but the name just comes out with EEEE instead of the Japanese text.

Code: Select all

codepage 932
getct NAME string 0x2C
log MEMORY_FILE 0 0
put NAME unicode MEMORY_FILE
goto 0 MEMORY_FILE
get NAME unicode MEMORY_FILE

[aluigi]

I don't think I can provide much support about that. The code in quickbms should be correct.

@Zim
Regarding the -w option and the creation of files, I have seen that the current feature (creating files if not existent) is used in some scripts (for example this) so I have opted for the following solution to make everyone happy: if doesn't exist, it asks if you want to create it.
Problem solved

[Zim]

aluigi
Well, as for me, I need it automatically... But of course I can use an old way with append + log 0 0 as a last resort

[aluigi]

I was referring to the usage of -w with "open FDSE unexistent_file.dat 0" that created confusion to some scripts because generated the file from scratch.

[aluigi]

So guys, are you ok with the beta?
Currently there are no additional features and fixes to implement so I'm ready for the release.

The only feature I have in mind (for the next-next release, not the 0.6.7 one) is about a possible Addheader command to add some common file format headers to the *log data, for example WAV, SS2, VAG, gamecube audio header, AVI, DDS and so on.
But in this case I need to know EXACTLY what parameters to allow.
For example in the case of WAV I expect something like: FREQUENCY CHANNELS BITS TYPE
All the fields would be optional with some default values like 44100 2 16 1.
But some formats may need many fields or may be very complex (DDS, AVI, non-PCM WAV and so on), that's why I'm not sure about this new command.
Let me know your feedback.

[Zim]

Well I got some scripts broken, have to check it in detail...

Got an error (var.c)

Error: there is something wrong in the BMS, var %d is a constant number

Found a problem:

Code: Select all

set VAR1 string "VAR2"
set VAR2 string "VALUE"          # Error: there is something wrong in the BMS, var 1 is a constant number
# same error:
# string VAR2 = "VALUE"

In older versions (including 0.6.6a) VAR2 is just reinitialized (I guess) and all is well.

[aluigi]

That message means it works because both VAR2 and "VAR2" are variables (like it was in the old versions) and so there is a collision because "VAR2" is constant.
So it's all ok, nobody should ever use something like that in a script.

[Zim]

I understand, well I hope nobody use it, as for me I can just fix my scripts

Also now it's impossible to use strict way of checking+flushing optional arguments for CallFunction with KEEP_VAR=1 (I need 1 for return value of functions):

Code: Select all

set NULL_arg1 string "FUNC_arg1"
CallFunction FUNC 1 "Arg"          # Error: there is something wrong in the BMS, var 1 is a constant number
StartFunction FUNC
    # e.g.
    if FUNC_arg1 != NULL_arg1
    # we got an argument
    # ...
    # flushing
    set FUNC_arg1 NULL_arg1
EndFunction

Ok, anyway, I can just switch to that non-strict way

Code: Select all

StartFunction FUNC
    if FUNC_arg1 & "FUNC_arg"
    # ...
    set FUNC_arg1 "FUNC_arg"
EndFunction

[aluigi]

I can ask the user to continue if there is a "is a constant" error so that you don't have to change all your scripts. Like a legacy compatibility.
Note that you can easily restore the old method by removing the quotes.

Regarding function arguments I guess I can do something very simple like setting all the arguments to "".
Now I check if it's possible but I think this idea may solve lot of problems.

I would like to make the same also for quickbms_arg* but if I do then the current scripts using the & check will be no longer compatible.

[Zim]

I can ask the user to continue if there is a "is a constant" error so that you don't have to change all your scripts. Like a legacy compatibility.

No, I guess we don't need any such legacy! (also I need automatic execution so any questions are bad for me)
Because:

Note that you can easily restore the old method by removing the quotes.

Awesome, thanks! This fixind everything Just by removing quotes in the beginning.

Regarding function arguments I guess I can do something very simple like setting all the arguments to "".
Now I check if it's possible but I think this idea may solve lot of problems.

I would like to make the same also for quickbms_arg* but if I do then the current scripts using the & check will be no longer compatible.

Well I gues this will be worse in some way because, yes:
1) an argument might be a "" (because sometimes arguments is a variables and sometimes we can't be sure if it's not an empty string)
2) we can't check for arguments no more like & or other similar ways

So I guess it's better to keep it as it is. Everything we have to do is just to remove the quotes in such super rare cases

[aluigi]

Yeah I guess you are right, leaving it as-is avoids problems of compatibility.
Anyway I guess I will insert the question in case of VAR/"VAR" conflict mainly to grant compatibility with old scripts and any possible issue that we can't see yet.
A question is better than a crash with old scripts

[Zim]

Yep, you're right about question. If someone need an automatic execution w/out questions he will just have to fix his script like me