This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=7449

Scofield_TR, posted Tue Feb 20, 2018 2:41 pm (32637)

---

Hi friends and .,

Shadow of Mordor, PS4 .arc05 files,There is a problem with going out .Please look.

BMS: http://aluigi.altervista.org/bms/shadow_of_mordor.bms

.arc05 File: https://mega.nz/#!dQ4DibaQ!WneZJEVjRAJZ ... lVmIkb8WFo

Thanks.

aluigi, posted Tue Feb 20, 2018 3:35 pm (32639)

---

Script 0.3.8

Scofield_TR, posted Tue Feb 20, 2018 4:13 pm (32640)

---

aluigi wrote:

Script 0.3.8

Thanks .

Scofield_TR, posted Tue Feb 20, 2018 10:35 pm (32647)

---

Sorry . my little problem. .arch05 file extract out to be awesome.

I'm having trouble re importing this file (en.embb) that came out of it.

Files: http://rgho.st/7FLkg2Rcl

Thanks.

aluigi, posted Tue Feb 20, 2018 11:08 pm (32648)

---

The files in the embb archives are stored sequentially so you can't use reimport2.bat with them.

Scofield_TR, posted Tue Feb 20, 2018 11:19 pm (32650)

---

aluigi wrote:

The files in the embb archives are stored sequentially so you can't use reimport2.bat with them.

what should I do? Sorry I do not understand much.

aluigi, posted Tue Feb 20, 2018 11:26 pm (32651)

---

You can only reimport files that are smaller/equal than the original.
I suggest to use reimport.bat because reimport2.bat will not warn you if the file is bigger and so will be appended automatically to the archive (which is wrong since it's a sequential archive).

Scofield_TR, posted Tue Feb 20, 2018 11:29 pm (32652)

---

aluigi wrote:

You can only reimport files that are smaller/equal than the original.
I suggest to use reimport.bat because reimport2.bat will not warn you if the file is bigger and so will be appended automatically to the archive (which is wrong since it's a sequential archive).

Thanks my friend See you in another question

aluigi, posted Wed Feb 21, 2018 2:32 pm (32664)

---

Ah just a note about the fix I used in version 0.3.8.
In all my samples the compressed (and chunked) files had FLAGS 9 (8|1), while the non-compressed files had FLAGS 0 and SIZE equal than ZSIZE.
Since I don't know the meaning of FLAGS, maybe AND 1 for compression and AND 8 for chunks or viceversa I don't know, I opted for checking if SIZE is equal than ZSIZE.
It should be considered a work-around, even if it's a good one since there are very low chances that SIZE==ZSIZE and it's compressed, so in future I may replace it with the correct code for handling the FLAGS field.
The alternative is replacing "SIZE != ZSIZE" with "FLAGS != 0".

Scofield_TR, posted Wed Feb 21, 2018 3:13 pm (32666)

---

aluigi wrote:

Ah just a note about the fix I used in version 0.3.8.
In all my samples the compressed (and chunked) files had FLAGS 9 (8|1), while the non-compressed files had FLAGS 0 and SIZE equal than ZSIZE.
Since I don't know the meaning of FLAGS, maybe AND 1 for compression and AND 8 for chunks or viceversa I don't know, I opted for checking if SIZE is equal than ZSIZE.
It should be considered a work-around, even if it's a good one since there are very low chances that SIZE==ZSIZE and it's compressed, so in future I may replace it with the correct code for handling the FLAGS field.
The alternative is replacing "SIZE != ZSIZE" with "FLAGS != 0".

I try,thank you very much