Problem with compressing using freearc
 

Hi there,


I've got a problem with compressing files with Freearc.
While compression passes fine in theory, at the end it produces error I'm using compression method afr:a2+srep:m3f:a0/0+lolz:mmt1:mt2 so why there is an lzma algorithm passed? I don't get it....


Oh, and at the beginning there is an error It occurs on all my PC-s and after changing the parts on my desktop

(before i've had an FX-8350 with 32 GB of DDR3 RAM, now I've got Ryzen5 3600 with 32GB of DDR4 RAM) and changing my Laptop from MSI GP60 to MSI GL65 with i7-9750H and 32GB of RAM. First time I've got an archive witch produces an -12 error on ACU's forge files but second time and copying the compressor's files to another drive produces an error as described before (lzma algorithm error). The same thing happens on Desktop and the Laptop. And before You say something about -12 error, this error occured before on desktop with FX-8350 and it's parts and just to confirm that's not the GPU problem I've wanted to compress the files on my Laptop...


I'm attaching the compression script in hope of resolving the problem.

The problem is your arc.exe command

I don't know exactly what the commands -i2 -dses do.

-dsds is sorting files in some kind of order but I dont know what order exactly. Some time ago I've got a problem wit arc not seeing files and someone recomended it to me, worked fine til now.


I'm checking the command right now.

Add anything after xLZ4 e.g.
[External compressor:xLZ4b]

I had the same issue and it worked for me...

The command didn't work for me, still lzma error occurs.

Well sad to say, it didn't work for me....

are you trying to repack games or just a normal user who wants to compress files to save disk space?

I have original ACU and the rest of the series, but I'm trying not to waste time to download over and over again the same game when i don't have time to play, so I'm trying to repack the game to don't have to download it later..


Ok, the problem might be connected with lolz version I'm using, I'm testing it now and the compression with afr srep m0 and lolz seperately looks like below.


srep
Attachment 26682


lolz
Attachment 26683


m0
Attachment 26681


afr
Attachment 26680

well try: CLI Compressor R6 > https://mega.nz/file/7jI3maDb#4qb35p...ILRYbuNugMv_us

Ok, all the problem was with h letter (a f... "h" letter!!). After deleting the letter the script works fine, but I've got a problem with unpacking. after trying to unpack the game with ASIS installer modified to my needs it just exits with the error in Computer Management/Event Viewer like in the code section.

What "h" letter you mean?

What changes did you make inside the script?

Did you use the correct afr version for ACU (I guess ACU is AC Unity? If so you have to use afr020 for both pack and unpack).

Mainly adding some registry keys depending the component selected (mainly language), and selecting crc file from the {app} folder instead of {tmp} folder. And some graphical changes, nothing more.


So to be clear, I've tested the installer without modifications of any sort clear 7.1.3 and 7.1.6 version and they do the same. The install just dissapear the moment that comes to unpacking DataPC.forge file, when I move the file and recompress the game without it, it stops on another file and so on.


I used afr19, because of error -1073741571 I much appreciate if someone can help me with this if the version 20a7 is required.



As for h letter there was one like this:

and it caused the "Bad Section" error.

You have to use 20a7 for this. But it surprises me that there was no error in recompressing unity with afr019, because it's only for the old games (first to black flag I think).

According to this image (when You run afr.exe v19)
Attachment 26684
AFR19 says that it's afr:a2 method is for ACUnity and ACSyndicate.


and according to Your post that I found from previously solving the problem with error -1073741571 (now the solution didn't work) posted on topic https://fileforums.com/showpost.php?...38&postcount=5
You've sayed that for games before Unity I have to use 19 version.

You've meant that Unity isn't the game that can be compressed with 20a7? or it shouldn't be compressed with that version?

Ok then...

Have you tested DataPC.forge with 019 and 020 pack+unpack with a simple batch file?

I think 20a7 is only for Origins and Odyssey if I remember correct because they use oodle compression and 20a7 is able to unpack this oodle streams.

I can not pack DataPC.forge with 020 because of error -1073741571 on this and any other forge file. As for 019 I can compress it but it crashes on cls-afr.dll while decompression... As for 019 crashing for other forge files I'm packing them now, and Data1 will be ready for unpacking about an hour and 14 minutes from now. Then I'll post an update as an edit for this post or another one if anyone posts one before me updating.


EDIT:
Ok guys, the problem didn't occur with any other forge file with afr019... That's odd... may it be that the forge file is corrupt?


EDIT2: Ok, the problem is definetly the DataPC.forge file, I moved it to another data file and cls-afr crashes on this data file leaving decompressed 320kb DataPC.forge and srep-virtual-memory.tmp of size 880mb that as lockhunter says is locked by cls-srep_x64.exe still working... (What?!)

I have tested this file (I downloaded the game directly from uplay).

It works here without problems.

Checksums of this file
sha1: 41D065BE402E6FDEA19C1398EBA781C957B9CEB6
crc32: 9F402671
md5: b3fc5cc8ba9a69ceaef3abba2e8cf96f

Ok, looks like the problem was that when I tried first I didn't kill all the processes of cls-lolz and cls-srep when previous error (error -1 due to differences in lolz version that packed the files and cls-lolz), now it seems to work fine on all forge files. please don't close the topic till I pack all the files (Currently is packing 4-th of 9 data files) and test them. I'll post an update when I finish.


Oh, and before questions I must answer, 9 files instead of 3 or 4 is due to -12 error on previous desktop config, at the beginning I recieved this error on new config of my desktop with Ryzen 5 3600 and first try was an almost 30GB data1 file with forge files that gave me -12 error. If the 9 part compression were a sucess I'll test the 4 part compression again.


EDIT:
Ok, first run after compressing all six packages with forge files ends with a crash on DataPC_ACU_LGS_BelleEpoque.forge, second one on dlc_11\DataPC_ACU-DLC_Saint-Denis.forge after deleting the files from {app} dir. After leaving the files and running the setup, it still crashes. so the crash is random...

Enough space/ram?

Try with -vr option (takes much longer).

Problem persists with batch decode?

Didn't try batch decoding, how to do that?
Just copy all nessessary files (like those from Freearc, afr, srep and lolz) to one folder and use uncompressing command from Arc.exe?


As for RAM I got 32GB of RAM and 20% of it used MAX(planning to buy another 32GB after coronavirus pandemic).
I've got around 1-1,5TB of free space so that should be enough.
and As I told earlier I have an AMD Ryzen 3600.

Place cls-afr, srep and lolz files along with arc.ini/cls.ini next to arc.exe and run.

Ok, I'll try it this evening (Polish time zone) or tomorrow morning.


EDIT:

-vr option didn't help


when I try to unpack with Arc.exe as You've told there is an error like in the attachement.


Attachment 26701


EDIT2: Ok, my bad, Didn't run it as Admin. Will report later if it will unpack or throw an error.

Ok I've unpacked the three data files that use vr option and here's what I have, in my oponion there is a problem because of percentage but progress shows all ok.
Attachment 26713
Attachment 26714
Attachment 26715

Oh and in the computer management now cls-srep crashes...


But it seems that everything is ok CRC Check is passing. May it be an unarc.DLL or ISDone.dll problem?
I've readed a bit more and it seems that this is a UnArc.dll problem or as I should say a 32-bit problem of cls-afr.dll


CLS-AFR.dll is a 32-bit library as UnArc.dll is, Data Files are using above 32-bit limit of memory so I've used standard AFR_x64 020 version, and it seems that the files are decompressing flawlesly.
I'll test it for about 7 times beside the 3 that already had been done, but for now it seems that everything is ok.