Quote:
Originally Posted by BLACKFIRE69
an equal or lesser value is also valid.
ex:
encode: 16 (Threads)
decode: 16, 8, 6, 4, 2, ...
if any user has entered an invalid value for the decoding threads, i'll improve MTX so that it can be corrected by MTX itself in a future update.
(since i'm a bit busy, give me some time for that  )
in the meantime you can test out the beta version of new RazorX. i've used 50p for encoding and 100p for decoding. although this is usually invalid, it's automatically corrected by RazorX.
Code:
[External compressor:rzmt]
header = 0
packcmd = RazorX.exe a -c:64m -t:50p $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = RazorX.exe x -t:100p - - <stdin> <stdout>
(read Important.txt before use)
. |
For you to better understand what happened.
Me and KaktoR were doing tests with RAZOR MTX.
The configuration used was:
Code:
packcmd = MTX.exe a -m:rz {option} -c:64m -t:100p - - <stdin> <stdout>
unpackcmd = MTX.exe x -m:rz {option} -t:100p - - <stdin> <stdout>
As his processor is 6/12 and my processor is 12/24
If it compressed and sent me the file I couldn't extract it because it would have been compressed using 12 threads and I would extract using 24 threads.
So if you make a game backup and upgrade the CPU to one with more threads, there will be an extraction error.
I know I could set it to t2 for extraction, but that loses the meaning of being multi threaded (use only 2 of 24).
The workaround is to set it to 100p use send thread number (get from system) as method parameter and when extract use {option} to set -t parameter.
Thanks for answering!