ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Sun Jul 21, 2019 3:36 pm

All times are UTC




Post new topic  Reply to topic  [ 525 posts ]  Go to page Previous 120 21 22 23 2427 Next
Author Message
PostPosted: Sun Mar 31, 2019 9:35 am 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
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?


Top
   
PostPosted: Sun Mar 31, 2019 12:56 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
I will think about it and if I need a new command-line option for enabling it.


Top
   
PostPosted: Wed Apr 03, 2019 10:51 am 
User avatar

Joined: Sun Aug 10, 2014 9:22 am
Posts: 31
Luigi Auriemma
Image

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 ?


Top
   
PostPosted: Wed Apr 03, 2019 3:01 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
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 :D


Top
   
PostPosted: Fri Apr 05, 2019 9:59 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
@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.


Top
   
PostPosted: Sat Apr 06, 2019 9:31 am 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
aluigi wrote:
@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


Top
   
PostPosted: Sat Apr 06, 2019 11:30 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
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


Top
   
PostPosted: Sat Apr 06, 2019 4:04 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
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


Last edited by Shokoniraya on Sat Apr 06, 2019 6:03 pm, edited 2 times in total.

Top
   
PostPosted: Sat Apr 06, 2019 6:01 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
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!


Top
   
PostPosted: Sun Apr 07, 2019 11:01 am 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
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


Top
   
PostPosted: Sun Apr 07, 2019 12:24 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
Excellent job.
I have just updated the beta file with all the fixes.
Let me know the results


Top
   
PostPosted: Sun Apr 07, 2019 1:03 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
and can you set utf-8 (BOM) to UTF-16 in slog text file?


Top
   
PostPosted: Sun Apr 07, 2019 1:13 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
Can you provide an example?

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


Top
   
PostPosted: Sun Apr 07, 2019 1:29 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
aluigi wrote:
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)


Top
   
PostPosted: Sun Apr 07, 2019 1:34 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
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


Top
   
PostPosted: Sun Apr 07, 2019 1:55 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
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.


Top
   
PostPosted: Sun Apr 07, 2019 2:08 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
aluigi wrote:
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!


Top
   
PostPosted: Sun Apr 07, 2019 2:12 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 10553
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?


Top
   
PostPosted: Sun Apr 07, 2019 2:41 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
aluigi wrote:
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!


Top
   
PostPosted: Sun Apr 07, 2019 2:51 pm 
User avatar

Joined: Sat Sep 15, 2018 5:22 am
Posts: 239
UTF-8 with BOM has Problem Too!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 525 posts ]  Go to page Previous 120 21 22 23 2427 Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited