I was also curious if @fitgirl repacks are affected so I made some tests. She was using ztool in period of around 1 year between August 2017 to June 2018, with one more appearing in August 2018. This is from relying on her repacks description info.
I also decided to test 2 repacks from her that use pzlib and one that use among the very first xtool version she started using, to isolate case and make sure only ztool is affected.
Specifically I tested:
Code:
pzlib: rime, mgs5:ground zero
xtool: planet coaster
ztool: hob, dark souls 3, little nightmares
And here are results:
Code:
rime, mgs5:gz => both installed successfully
planet coaster => installed successfully
hob, dark souls 3, little nightmares => all 3 installed successfully
I even installed DS3 2x. Apparently, fitgirl repacks are fine. I don't know why they work as the issue described in this thread is real and replicable. I doubt she is limiting threads to 't1' or using 'cm0' option. Maybe she have different version, or is using ztool in different context(in conjunction with different tool chaining, io vs stdin etc..). But it is good news regardless. Make no mistake, issue is real and replicable(by me), but fitgirl's repacks are not affected. Go figure...
EDIT:
- I found that with arc.exe its less affected than FA GUI version. It still happen but not always. arc.exe also close ztool process correctly upon ctrl+c, GUI keep it hanging.
- If unpacking/testing passes, then subsequent ones will be always successful and to make it bug again it need to fail on another archive(buffer memory).
- I also found that with non-GUI FA, if I keep retrying to unpack or test archive then after several failed attempts it will work.
-cm0 always work reliably and on the first go, no issues
This seem IO/threading issue to me, not sure if it happen only when using FA and ztool together, or ztool in general. Hell it could even be FA's problem. I am clueless. Never had any issue on Haswell so I could blame AMD, yet cm0 option work reliably + I know my system and memory are stable.