spider91, posted Sat Aug 29, 2015 9:32 am (6964)

---

Can you add an option to automatically rename files that already exist (like type "r" when quickbms asks what to do with existing files)?

aluigi, posted Sat Aug 29, 2015 12:15 pm (6972)

---

The slog command works in append mode so the same output name means that the new data will be concatenated to that file.
You have to generate a new sequential output filename if you want to avoid this behaviour.

But why do you want to save each string in a separate file?
In that case it's better to use the Log command.

Or are you referring to something different?

spider91, posted Sat Aug 29, 2015 12:36 pm (6975)

---

I don't need separate files for each string. I need only one file, but there is no string sizes and endline characters. Take a look at example.

http://www32.zippyshare.com/v/1ufkrFh8/file.html

aluigi, posted Sat Aug 29, 2015 3:21 pm (6985)

---

Code:

get NAME basename
string NAME  = ".txt"

get STRINGS long
for i = 0    get OFFSET long
   slog NAME OFFSET -1
next i

spider91, posted Sat Aug 29, 2015 9:42 pm (7005)

---

Thanks, didn't knew it add's endline characters by default.

And is there a way to use ID in hex like tag in output txt? For example add ID field to each offset (get OFFSET long and after that get ID long) than output it like .ini files

Code:

00000001=string1
00000002=some another string
00000003=final string
...
00FFFFFF=end string

aluigi, posted Sun Aug 30, 2015 11:58 am (7017)

---

No, every line is the whole string read from the file (multilines are escaped with \).
So the ID is the line number itself.

Zim, posted Thu Sep 03, 2015 3:59 pm (7161)

---

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, posted Fri Sep 04, 2015 4:09 pm (7166)

---

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, posted Fri Sep 04, 2015 5:41 pm (7175)

---

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"

aluigi wrote:

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, posted Sat Sep 05, 2015 7:05 am (7192)

---

ok for the -q option

einstein95, posted Tue Sep 08, 2015 11:32 am (7298)

---

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, posted Tue Sep 08, 2015 5:52 pm (7313)

---

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, posted Tue Sep 08, 2015 9:26 pm (7322)

---

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, posted Wed Sep 09, 2015 1:35 am (7326)

---

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

Code:

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

einstein95, posted Wed Sep 09, 2015 2:05 am (7329)

---

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

Code:

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, posted Wed Sep 09, 2015 10:59 am (7342)

---

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, posted Wed Sep 09, 2015 9:57 pm (7359)

---

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, posted Wed Sep 09, 2015 10:12 pm (7360)

---

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, posted Fri Sep 11, 2015 12:44 pm (7404)

---

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, posted Sun Sep 13, 2015 2:19 pm (7451)

---

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

Got an error (var.c)

Quote:

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

Found a problem:

Code:

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, posted Sun Sep 13, 2015 3:40 pm (7453)

---

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, posted Sun Sep 13, 2015 3:58 pm (7454)

---

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:

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:

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

aluigi, posted Sun Sep 13, 2015 4:29 pm (7455)

---

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, posted Sun Sep 13, 2015 5:32 pm (7459)

---

aluigi wrote:

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:

aluigi wrote:

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.

aluigi wrote:

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, posted Sun Sep 13, 2015 5:37 pm (7460)

---

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