Helping thread :)

[ChronoCross]

Originally Posted by Razor12911

Is there a need to learn LUA code?
-Nevermind-Nirvana-

my mistake. No the old way works fine.
i want to make somethig new interesting with LUA code in FA Next.

[Razor12911]

Well I didn't know there was a need, I didn't check fa.ini until this morning, seemed interesting, and definitely something I have no knowledge on so carry on, good luck.

[Vapor028]

Originally Posted by Razor12911

-Is it possible to use xz compressed files with IC 3.0? if yes how? (btw thx razor for this awesome program)
Unfortunately no.

-next one is how to use 4x4:lzma... i have a bat that runs but its no difference to lzma
it sometimes all depends on what you're compressing. 4x4 allows a compressor to run in parallel mode, meaning more speed at a cost of ratio. 4x4 splits data into blocks then runs a chosen compressor, this block splitting loses you ratio, but like I said it all depends on what you're compressing, if its something that can be compressed properly by lzma and is long, you'll see ratio difference.

Thx for the fast answer.
For the XZ files... is there an IC like program to use?
and for the 4x4 problem i wrote a little wrong... with no difference i mean in terms of speed. its like 4x4 isnt there at all.... it will be subjetive but i think its even slower then lzma alone. maybe something wrong in the bat?

-msrep64+delta+4x4:lzma:a1:mfbt4:d1024m:fb128:mc100 0:lc8

[Gupta]

Originally Posted by Razor12911

Well srep on default, if you're using stdio, it has a setting of expecting no more than 25GB/25 600MB from stdin.
"-sBYTES: explicitly specify filesize (for compression from stdin), default 25gb"
All you need to do is guess or have an estimation of your input and set a value, to be safe, set a high value
-s50gb or whatever, just know that this increases memory allocation so also make sure you have enough memory to allocate such, plus for big inputs, you're better off using x64 version of srep to avoid x86 memory allocation barrier.

specifying correct size probably more good while decompressing
srep will fail if u specify less and use more ram if u specify more, is little bit slow too

probably the reason why it is failing to restore things data correctly is becoz of the fact that i don't even store checksums while processing with srep(-hash-)

[Razor12911]

Originally Posted by Vapor028

Thx for the fast answer.
For the XZ files... is there an IC like program to use?
and for the 4x4 problem i wrote a little wrong... with no difference i mean in terms of speed. its like 4x4 isnt there at all.... it will be subjetive but i think its even slower then lzma alone. maybe something wrong in the bat?

On second thought, I think it's actually possible for IC update, I wonder why didn't I think of this before.
Making update for XZ support.

Originally Posted by PrinceGupta2000

specifying correct size probably more good while decompressing
srep will fail if u specify less and use more ram if u specify more, is little bit slow too

probably the reason why it is failing to restore things data correctly is becoz of the fact that i don't even store checksums while processing with srep(-hash-)

Actually, srep is suppose to fail during compression, removing -hash- will not fix this, to be on the safe side, don't pipe srep when compressing, only do that when decompressing.

[MCWRX]

Hey guys. I am in a bit of a problem right here, this happened to me 2 times since I was compressing game files. I have 5 archives. First 3 unpack without any problems, then when it comes to the 4th one, at very ending of it I get this message - http://funkyimg.com/i/2i9Kc.png The 5th archive unpacks without any errors. I happened to me once before, I couldn`t manage to realize what it was, maybe you could help me?

I was packing with

-msrep:m3f:a16:l512+delta+lzma:a1:bt4:d400m:fb273:mc10000000000:lc8:lp2:pb2

Other archives use pretty much the same algorithms, on some of them I used precomp if it matters.

[aswadd]

Originally Posted by MCWRX

Hey guys. I am in a bit of a problem right here, this happened to me 2 times since I was compressing game files. I have 5 archives. First 3 unpack without any problems, then when it comes to the 4th one, at very ending of it I get this message - http://funkyimg.com/i/2i9Kc.png The 5th archive unpacks without any errors. I happened to me once before, I couldn`t manage to realize what it was, maybe you could help me?

I was packing with

-msrep:m3f:a16:l512+delta+lzma:a1:bt4:d400m:fb273:mc10000000000:lc8:lp2:pb2

Other archives use pretty much the same algorithms, on some of them I used precomp if it matters.

I don't know Much about inno but did you try to extract using cmd to know exactly where the problem is ??
arc x archive.arc --adddir
if specific algorithm is causing this error arc will tell you
if it extracted without any problem so the problem is from inno script itself

[MCWRX]

Originally Posted by aswadd

I don't know Much about inno but did you try to extract using cmd to know exactly where the problem is ??
arc x archive.arc --adddir
if specific algorithm is causing this error arc will tell you
if it extracted without any problem so the problem is from inno script itself

Thank you. Now I will know how to test this.

But it seems that the operation succeeded via the CMD, no errors

What problem can there actually be in my script, is there anyone who would like to take a look? The other 4 archives are unpacking without any errors. Strange.

[aswadd]

Originally Posted by MCWRX

Thank you. Now I will know how to test this.

But it seems that the operation succeeded via the CMD, no errors

What problem can there actually be in my script, is there anyone who would like to take a look? The other 4 archives are unpacking without any errors. Strange.

try to make archive number 4 and 5 one archive so that you'll have only 4 archives Just ignore the problem you can't solve
Update:
-msrep:m3f:a16:l512+delta+lzma:a1:bt4:d400m:fb273:m c10000000000:lc8:lp2b2
you are using large dictionary in your lzma the difference will be a couple of megas
& For Srep you are using a16 why not using a64 it's the fastest & best ratio ~ same ratio as a0/a1 ~

[aswadd]

Guys , I need to understand something
Precomp+msc
msc+precomp
what is the difference ??
is Precomp+msc better to be sure that msc find all media & compress it ?? or Just leaving it msc+precomp because msc will also find all media but will be faster because input is smaller than precomp input ??

[SAM2712]

Originally Posted by aswadd

Guys , I need to understand something
Precomp+msc
msc+precomp
what is the difference ??
is Precomp+msc better to be sure that msc find all media & compress it ?? or Just leaving it msc+precomp because msc will also find all media but will be faster because input is smaller than precomp input ??

Hello aswadd
I think Precomp+msc do the best As precomp do decompress so msc piping is easy to find out maximum media files with effective speed of finding

[Razor12911]

^Exactly what he said.

But it's general knowledge, think of it this way.
can deflate streams store media streams? yes, deflate is a compression algo and it can contain media streams.
can media streams store deflate streams? no, media streams is not a compressor or a packer of some sort therefore it cannot contain deflate streams.

[ChronoCross]

Testing only One idea in fa Next with LUA code.
The first idea:
I take a folder with 62MB into -m0 option "data.arc"
and then split the file with razor's split tool in three parts.
data.part1 30 mb
data.part2 30 mb
data.part3 2 mb
OK well the first idea is said to fa next with LUA code:
that's this three files are "data.arc"(with a trick or patch i don`t know).
well the problem is fa next
search the file in directory and seek all the file.
doesn`t see this three files like into one("data.arc").
The principal idea is not join the files is create an emulation of file or something like that(and you know what?, i don´t know how to do ).
but i fail because, fa next needs data.arc present in the folder and with his size(and his correct hashes).
OK this is the LUA code for fa.ini to join the files (without Split.exe).

onProgramStart(function ()
a = "none"
f = command.arcname
f = io.open(f, "a")
f:write()
f = io.open("data.arc", "r+b")
f1 = io.open("data.part1", "rb")
f2 = io.open("data.part2", "rb")
f3 = io.open("data.part3", "rb")
f4 = f1:read("*all")..f2:read("*all")..f3:read("*all")
t = io.output (f:write(f4))
f = assert (io.open("data.arc", "r"))
f:close()
end)

and the code for extract in cmd

fa x -dp.\ data.arc

well another problem here (help) you need to run the bat two times.
the first is an error like data.arc is not a valid fa next file.
because the code first create data.arc with 0b.
but the second time you run the bat, fa next extract correctly because the program found a joining data in data.arc.
If someone have an idea to fix this or help to the first idea please go on!

[gozarck]

HI ChronoCross Nice idea and a litle complicated for me
the first Idea is awesome, but i can't help you .
I started to read LUA and looks easy to undertand.

Originally Posted by ChronoCross

well another problem here (help) you need to run the bat two times.
the first is an error like data.arc is not a valid fa next file.
because the code first create data.arc with 0b.
but the second time you run the bat, fa next extract correctly because the program found a joining data in data.arc.
If someone have an idea to fix this or help to the first idea please go on!

let me help you in this part.
add some lines in your fa.ini code repeat and until ~=

onProgramStart(function ()
    repeat
	a = "none"
    f = command.arcname
    f =  io.open(f, "a")
    f:write()
    f =  io.open("data.arc", "r+b")
	f1 = io.open("data.part1", "rb")
	f2 = io.open("data.part2", "rb")
	f3 = io.open("data.part3", "rb")
    f4 = f1:read("*all")..f2:read("*all")..f3:read("*all")	
	t = io.output (f:write(f4))
	until f ~= assert ( io.open("data.arc", "r"))
	f:close()
end)

Now can join and extract the files correctly.

[Bulat]

btw, if you not found it - the classic Lua learning book is http://www.lua.org/pil/contents.html

it's third edition is available online