MTX - The Universal Accelerator

[BLACKFIRE69]

MTX v5.0.0.2 Improved version

What's new:

• Fixed a few minor bugs.
• Improved exception handling.
• Returns an error code for each situation.

* Check the first post for more info & downloads.


.

[Masquerade]

@BLACKFIRE69

MTX crashes on when decompressing on systems with strange numbers of cores/threads (e.g. 6c/6t and 6c/12t)

Are you able to fix this? (issues in both EXE and CLS versions)

[KaktoR]

I can only decompress with mtx if t100p is set in packcmd in arc.ini.

If I set t75p (or any other number other than 100) freearc can't decompress the archive.

Is this a bug or am I missing something?

Edit: encode and decode have to be equal. I missed it. If you used t100p in encode you have to use t100p in decode too. Sorry

[Cesar82]

BLACKFIRE69, you could remove the ":" from the parameters in your MTX.
Example, how can I send 4 threads (-t4) as a parameter from pack.bat. It is not allowed to send "t:4" because the ":" are already FreeArc parameter separators.

[BLACKFIRE69]

Originally Posted by Cesar82

BLACKFIRE69, you could remove the ":" from the parameters in your MTX.
Example, how can I send 4 threads (-t4) as a parameter from pack.bat. It is not allowed to send "t:4" because the ":" are already FreeArc parameter separators.

sure,

[External compressorrecompx,mtx_precomp]
header = 0
default = -t100p --logs --basePath=".\..\.." --cfgfile="$basePath$\arc.ini" --tmpPath="$exePath$\temp"

packcmd = MTX\Win64\MTX.exe a -mprecomp048 -c256m {option} - - <stdin> <stdout>
unpackcmd = MTX\Win64\MTX.exe x -mprecomp048 {option} - - <stdin> <stdout>

[BLACKFIRE69]

Originally Posted by KaktoR

I can only decompress with mtx if t100p is set in packcmd in arc.ini.

If I set t75p (or any other number other than 100) freearc can't decompress the archive.

Is this a bug or am I missing something?

Edit: encode and decode have to be equal. I missed it. If you used t100p in encode you have to use t100p in decode too. Sorry

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.

[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)
.

[Cesar82]

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.

[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:

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!

[BLACKFIRE69]

Originally Posted by Cesar82

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.

that won't happen in the next update of MTX. checkout the RazorX beta above,
the following config works without any problems.

[External compressor:rzmt]
header = 0
packcmd   = RazorX.exe a -c:64m -t:12 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = RazorX.exe x -t:24 - - <stdin> <stdout>

OR

KaktoR can use it to encode as,

packcmd  = RazorX.exe a -c:64m -t:100p $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

also, cesar you can use the same to decode, -t:100p

unpackcmd = RazorX.exe x -t:100p - - <stdin> <stdout>

[BLACKFIRE69]

Update!

USAGE:

[External compressor:zstdmt,zstdx,mtx_zstd]
header = 0
default   = -t100p --basePath=".\..\..\" --cfgfile="$basePath$\arc.ini" 

packcmd   = MTX\Win64\MTX64.exe a -mzstd64 -c128m {option} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = MTX\Win64\MTX64.exe x -mzstd64 {option} $$arcpackedfile$$.tmp $$arcdatafile$$.tmp


[External compressor:zstdmt,zstdx,mtx_zstd]
header = 0
default   = --basePath=".\..\..\" --cfgfile="$basePath$\arc.ini" 

packcmd   = MTX\Win64\MTX64.exe a -mzstd64 -c128m -t8 {option} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = MTX\Win64\MTX64.exe x -mzstd64 -t8 {option} $$arcpackedfile$$.tmp $$arcdatafile$$.tmp


[External compressor:zstdmt,zstdx,mtx_zstd]
header = 0
default   = --basePath=".\..\..\" --cfgfile="$basePath$\arc.ini" 

packcmd   = MTX\Win64\MTX64.exe a -mzstd64 -c128m -t4 {option} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = MTX\Win64\MTX64.exe x -mzstd64 -t8 {option} $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

[BLACKFIRE69]

MTX v5.0.0.3 beta Update 1

-- Fixed a minor issue.

Thanks @Cesar82 for pointing this out.


MTX v5.0.0.3_beta Update 01 _ 64-Bit.rar

[BLACKFIRE69]

1. Created MTX2023 from scratch and optimized for speed and efficiency.
  - As a result, it isn't compatible with any previous versions.

2. The bugs experienced in previous versions have been addressed and fixed.

3. MTX can handle scenarios where the #userThreads > #compressionThreads.

4. Simultaneous reading and writing of data takes place.
  - Previous versions required extra waiting time that's no longer necessary in this version.
  - Make sure to specify the '-ds' parameter with the 'arc.exe a'. (arc.exe a -ds ...)

Remark:

1. '--TempPath=' parameter has been removed.
  - Tmp files will now be created in the freearc temp dir instead.

2. '%' sign has been removed from threads (100%).
3. Support for "MTX32.ini" and "MTX64.ini" files has been discontinued.
4. There won't be a 32-bit version of MTX.

1. Recommended setting (stdio mode) but no info will be displayed.

packcmd   = MTX64.exe a -mNz64 -c32m {options} - - <stdin> <stdout>
unpackcmd = MTX64.exe x -mNz64 {options} - - <stdin> <stdout>


2. Info will only be displayed for packing.

packcmd   = MTX64.exe a -mNz64 -c32m {options} - $$arcpackedfile$$.tmp <stdin>
unpackcmd = MTX64.exe x -mNz64 {options} - - <stdin> <stdout>


3. Info will only be displayed for unpacking.

packcmd   = MTX64.exe a -mNz64 -c32m {options} - - <stdin> <stdout>
unpackcmd = MTX64.exe x -mNz64 {options} - $$arcdatafile$$.tmp <stdin>


4. Info will be displayed for both packing and unpacking. 

packcmd   = MTX64.exe a -mNz64 -c32m {options} - $$arcpackedfile$$.tmp <stdin>
unpackcmd = MTX64.exe x -mNz64 {options} - $$arcdatafile$$.tmp <stdin>

.

[L0v3craft]

Tested MTX 2023 with razor. It is a disaster, freezes my computer. Never happened with the accelerator razorx.

Looks like it has created 190k files in the temp folder of freearc, when I have compressed one single file of 2.77GB.

[Cesar82]

Originally Posted by BLACKFIRE69

MTX v5.0.0.3 beta Update 1

-- Fixed a minor issue.

Thanks @Cesar82 for pointing this out.


MTX v5.0.0.3_beta Update 01 _ 64-Bit.rar

Could you get me the 32-bit release on UPX of this version 5.0.0.3?

[BLACKFIRE69]

Originally Posted by Cesar82

Could you get me the 32-bit release on UPX of this version 5.0.0.3?

The MTX project has been rebooted, and it is now starting from version 0.1. The new version of MTX is compatible with both cls-diskspan.dll and DiskSpan-GUI.



The first post has been updated.


.

[Cesar82]

Originally Posted by BLACKFIRE69

The MTX project has been rebooted, and it is now starting from version 0.1. The new version of MTX is compatible with both cls-diskspan.dll and DiskSpan-GUI.



The first post has been updated.


.

1) The --tmpPath= parameter and the $tmpPath$ variable no longer exist?
2) There is no longer support for external configurations in MTX.ini?