And the other way?
And could you clarify at what point to use gzip?
Format IDX
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Format IDX
With the first script you can't reimport at all.
With the second way you can and you are subject to the file size limits.
With the second method you must use gzip as last step to create the cnt archive, I posted a whole step-by-step for the operation.
With the second way you can and you are subject to the file size limits.
With the second method you must use gzip as last step to create the cnt archive, I posted a whole step-by-step for the operation.
-
- Posts: 15
- Joined: Sun Nov 02, 2014 9:17 pm
Re: Format IDX
I Thank Aluigi for help and cooperation! The unpack and repack of resources works perfectly, but the problem is that unpacked text files are unreadable for some reason.
Here is the example of such compressed file http://rghost.ru/59165766
Here is the example of the same unpacked txt file from the old version which was not compressed and is readable [http://rghost.ru/59166445
Is it possible to decompress this unreadable file as it was in the previous version?
Here is the example of such compressed file http://rghost.ru/59165766
Here is the example of the same unpacked txt file from the old version which was not compressed and is readable [http://rghost.ru/59166445
Is it possible to decompress this unreadable file as it was in the previous version?
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Format IDX
As I already said some posts ago, those text files are not compressed but they are compiled (basically they are the binary representation of the original text).
I can't help with decompilers.
I can't help with decompilers.
-
- Posts: 15
- Joined: Sun Nov 02, 2014 9:17 pm
Re: Format IDX
We unpacked resources in order to translate the texts and names of subjects and objects from chineese into another language. But the problem is chineeze words and sentences have much less symbols than the same English or Russian ones. So after the process of translation the size of these files has been enlarged and it became impossible to reimport these enlarged files. So it is of no sense to unpack and translate the files.
Do we need to unpack, translate, change the size and try to repack the definite files? My experience shows that it all is in vain. So is it possible to create a new archive which will have the same file structure but will not dictate the definite file size? I mean, we could unpack all the archive files, change them (enlarge their size) and then create a new (but in fact it will be just the same) archive which would have the same structure and the same list of files.
data.cnt http://rghost.ru/59275513
data.idx http://rghost.ru/59275522
Do we need to unpack, translate, change the size and try to repack the definite files? My experience shows that it all is in vain. So is it possible to create a new archive which will have the same file structure but will not dictate the definite file size? I mean, we could unpack all the archive files, change them (enlarge their size) and then create a new (but in fact it will be just the same) archive which would have the same structure and the same list of files.
data.cnt http://rghost.ru/59275513
data.idx http://rghost.ru/59275522
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Format IDX
Any solution is not easy but "probably" the simplest one is:
1) finding the exact part in the uncompressed IDX file where are located the OFFSET and SIZE field.
You can use quickbms -V -0 (zero) to find the offset in the IDX file where are located these two fields, for example:
2) take note of the current size of the CNT archive, it will be the new OFFSET field.
3) append the new modified file to the CNT one by using a hex editor or a script like the following:
quickbms script.bms new_file c:\folder_of_the_game
4) open the IDX file with a hex editor and go to the position where are located the OFFSET and SIZE field of the new file you appended and replace these values with the new ones
I think it's easier than what it seems.
1) finding the exact part in the uncompressed IDX file where are located the OFFSET and SIZE field.
You can use quickbms -V -0 (zero) to find the offset in the IDX file where are located these two fields, for example:
Code: Select all
. 00112233 get OFFSET 0x00004455 4
| | | |
| | | size of the field (4 is long)
| | value
| name of the field
offset of the field in the file
2) take note of the current size of the CNT archive, it will be the new OFFSET field.
3) append the new modified file to the CNT one by using a hex editor or a script like the following:
Code: Select all
get SIZE asize
append
log "data.cnt" 0 SIZE
open FDSE "data.cnt"
get OFFSET asize
math OFFSET -= SIZE
print "new OFFSET %OFFSET|x%"
print "new SIZE %SIZE|x%"
4) open the IDX file with a hex editor and go to the position where are located the OFFSET and SIZE field of the new file you appended and replace these values with the new ones
I think it's easier than what it seems.
-
- Posts: 15
- Joined: Sun Nov 02, 2014 9:17 pm
Re: Format IDX
Unfortunately I appeared to be too dumm to follow your instruction. I don't understand why it doesn't work.
I can describe my actions step by step.
We have 3 files: "data.idx" "data.cnt" and "data" (we've unpacked the last file from "data.cnt" with the help of 7zip).
1) According to step 1 I am to find offset and size of the needed file.
quickbms -V -0 script.bms data.idx .\ > INFO.txt (in your message it was script.bms on the previous page)
I create file INFO.txt and seek information about the needed file inside it (FONTS.INI):
Do I understand it properly? This is the information about the location of FONTS.INI inside of "data".
2) According to step 2 I am to note the CNT archive's size, but for what? Did you mean the size of "data.cnt"? May be you meant the size of "data"?
3) Format CNT ("data.cnt") is absolutely unreadable as well as rar or zip. On the contrary I can read "data" as a txt file.
I've stuck ((( I cannot execute neither step 2 nor 3 ((
Would you please make the instruction a little bit more detalized?
I can describe my actions step by step.
We have 3 files: "data.idx" "data.cnt" and "data" (we've unpacked the last file from "data.cnt" with the help of 7zip).
1) According to step 1 I am to find offset and size of the needed file.
quickbms -V -0 script.bms data.idx .\ > INFO.txt (in your message it was script.bms on the previous page)
I create file INFO.txt and seek information about the needed file inside it (FONTS.INI):
Do I understand it properly? This is the information about the location of FONTS.INI inside of "data".
2) According to step 2 I am to note the CNT archive's size, but for what? Did you mean the size of "data.cnt"? May be you meant the size of "data"?
3) Format CNT ("data.cnt") is absolutely unreadable as well as rar or zip. On the contrary I can read "data" as a txt file.
I've stuck ((( I cannot execute neither step 2 nor 3 ((
Would you please make the instruction a little bit more detalized?
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Format IDX
Basically the idea of this trick is appending your modified file at the end of the archive and so you must modify the OFFSET and SIZE values on the index file so that instead of reading the old file it will read the new one without problems of size.
In your example 0xc4c is the position of the index file where is located the OFFSET field of the file you extracted.
So you must replace that value in IDX with the current size of DATA (not data.cnt) because it will be the new offset.
Append your file.ini at the end of DATA.
Go to offset 0xc50 of IDX and write the size of file.ini
Save IDX and DATA, compress DATA as DATA.cnt and you should be fine.
PS: in my previous description I forgot that the cnt file is compressed and not the idx one, that's the reason about the IDX, CNT and no-extension confusion.
In your example 0xc4c is the position of the index file where is located the OFFSET field of the file you extracted.
So you must replace that value in IDX with the current size of DATA (not data.cnt) because it will be the new offset.
Append your file.ini at the end of DATA.
Go to offset 0xc50 of IDX and write the size of file.ini
Save IDX and DATA, compress DATA as DATA.cnt and you should be fine.
PS: in my previous description I forgot that the cnt file is compressed and not the idx one, that's the reason about the IDX, CNT and no-extension confusion.