Possible next features of QuickBMS

[Shokoniraya]

Sir Aluigi, I know replacing and shifting needs so many works in temp or memory ram
So can you left it for next versions (after some versions later), if it's hard for now?

[aluigi]

I will think about it and if I need a new command-line option for enabling it.

[shekofte]

Luigi Auriemma


What about advantages of high speed solid state drives ?
I mean is it possible in long history of Qbms development , you ignored plans or implementations that may carry out on HDD slowly or in small size ...

the only example i can mention are temporary files ?

Indeed you are more familiar with hardware technologies rather than me .
but as if SSDs are ten time faster than HDDs and the rate of fragmented data is so much lower too

If you set assumption for expensive SSD with high quality options that usually professional gamers choose .. by the way , do you see any highlight on updating qbms commands or new ones ?

I wish some good news ?

[aluigi]

quickbms simply extract files, doesn't matter if they are extracted to a HDD or SSD (at least doesn't matter to quickbms)

My strong suggestion is to use a ramdisk of some gigabytes and extracting everything there, editing, reimporting, and everything else on the ramdisk with backups for works that take many days.

I analyze tons of games and files everyday, gigabytes of data, and I have never used an hard-disk

[aluigi]

@Shokoniraya
Just to inform you that I have successfully implemented reimport3 in my beta.
It works exactly like reimport2, if there is no offset field it automatically shrinks or enlarges the file.

In my tests it works very well, if you want I can provide a beta executable for your tests.

[Shokoniraya]

@Shokoniraya
Just to inform you that I have successfully implemented reimport3 in my beta.
It works exactly like reimport2, if there is no offset field it automatically shrinks or enlarges the file.

In my tests it works very well, if you want I can provide a beta executable for your tests.

Thank you sir aluigi!
yes, please upload beta version, and I will test it on my script

[aluigi]

Perfect.
The beta is available here together with the current differences in the source code (I have fixed almost all the bugs of my TODO list):
http://aluigi.org/beta/quickbms_0.9.3.zip

[Shokoniraya]

Problem

Click on _export.bat, and all text will extract to localisation Folder (Done and good working)

edit a line For example, line 2
if you edit a line and type a line smaller than original and save it and click on _import.bat, then quickbms will stuck!
link of sample file in my test, this file is a best test fo a text file: https://www.mediafire.com/file/38fyeczc ... e.zip/file

[Shokoniraya]

after more test, I found out a something!
bigger size can't work too
size will update, but text will append in last byte (like reimport2!)
and quickbms will stuck on smaller text (if change and type a smaller dialog)

And you better use UTF-16, because most of text editors will show a unreadable text!

[Shokoniraya]

after more tests, i found out more things

seems like shrinking works fine in log and clog
problem is slog, and i used same script in log and clog (clog with add a fake comtype copy compress in file), but slog has problem

[aluigi]

Excellent job.
I have just updated the beta file with all the fixes.
Let me know the results

[Shokoniraya]

and can you set utf-8 (BOM) to UTF-16 in slog text file?

[aluigi]

Can you provide an example?

Here I made a simple test and it seems to work.

[Shokoniraya]

Can you provide an example?

Here I made a simple test and it seems to work.

yes, works fine, but text editors will show a unreadable (ascii codes) as unicode characters
can you set it to UTF-16?
problem is text editors, not quickbms
and all text editors can works fine with UTF-16 without any problem
you better Set output slog files to Little endial Unicode (16)

[Shokoniraya]

i can see unicode characters in hex (quickbms output file) and that means quickbms can export utf-8 as well, but it better be utf 16
because utf-16 has \xFF\xFE (as a header) and it is two-byte and there is no way to read it as ASCII mode

[aluigi]

Ah, you mean the text file generated by slog.
Basically you want the UTF8 BOM (0xfe 0xfe or 0xEF,0xBB,0xBF) or directly the UTF16 output (with the UTF16 BOM obviously).

I guess the best solution would be for me to use the UTF8 BOM at the beginning of the file, I can work on that.

Anyway notepad++ can do the job automatically or by selecting Encoding -> Encode in UTF-8.

[Shokoniraya]

Ah, you mean the text file generated by slog.
Basically you want the UTF8 BOM (0xfe 0xfe or 0xEF,0xBB,0xBF) or directly the UTF16 output (with the UTF16 BOM obviously).

I guess the best solution would be for me to use the UTF8 BOM at the beginning of the file, I can work on that.

Anyway notepad++ can do the job automatically or by selecting Encoding -> Encode in UTF-8.

no! dont use UTF-8 BOM!
i test it with both (without BOM) and (BOM mode at header), but still has problem
just use directly the UTF-16 output with BOM, because UTF-16 can solve all of unicode problems! and as i said, UTF-16 has BOM (i never seen a UTF-16 without BOM, because its need BOM to reading by any text editors and every charcters has their own two-byte hexadecial code)

note: UTF-8 is not a good idea for slog, best option is UTF-16 little endian and done! all of unicode problems will solve!

[aluigi]

It's a problem for me to use utf16.

utf8 is compatible with any editor, even those not supporting it, chars out of range will be visible in a wrong way but everything is visilbe.
While utf16 requires an utf16 editor or the zeroes will cause lot of problems.

What are the problems you are experiencing with utf8?
Are you sure it isn't something related to the codepage?

[Shokoniraya]

It's a problem for me to use utf16.

utf8 is compatible with any editor, even those not supporting it, chars out of range will be visible in a wrong way but everything is visilbe.
While utf16 requires an utf16 editor or the zeroes will cause lot of problems.

What are the problems you are experiencing with utf8?
Are you sure it isn't something related to the codepage?

code and script and other things is just fine

but utf-16 is a better for localization and all text editors (all text editors can work with utf16, but utf make problem)
zeroes will not make any problem, because text files with \xFF\xFE will read as a utf-16 file

a way to solve: export text and turn it to utf-16 in temporary and paste it in folder and Reverse it to ut8-witout BOM in reimporting
thats a good way

What are the problems you are experiencing with utf8?
my characters will show as a ASCII code if i opened a original file without any editing and just exported

Are you sure it isn't something related to the codepage?
i am sure codepage is fine! i can edit in hex editor too!

[Shokoniraya]

UTF-8 with BOM has Problem Too!