I have done everything as instructed and managed to run and finish the patcher without issues, but output folder remains empty, even when it says "all done, check output folder". Currently only way to do this is the wls method, but it takes so much time since i remove/uninstall it after using it as i don't want to keep it.

Am i just doing something wrong?

Does it still work with version 0.1.2 of the patchset?

Also, you can try editing apply-patches.sh and commenting out line 25 by putting # at the beginning. This will stop the script from deleting the "work" directory and you'll find the unzipped mods in there.

No it did not work in 0.1.2 either. i noticed that after running the patcher, work folder had all of the mods except the main ir3. So for whatever reason it didn't delete all of them.

Thanks for the workaround, commenting out line 25 worked nicely and got all of them updated, including the main mod.

Unfortunately, I've done some testing and it works perfectly on my end. (Albeit slowly. Why is running zip/unzip on Windows with an SSD so much slower than doing it on Linux with a HDD?) I wonder if you're running out of storage space or something..

This is why I left the WSL instructions up, because I can't account for everyone's PC environment. Even though it's a bit heavy, WSL does a good job of being a genuine Linux environment.

In 0.2.1, the script will have some new command line options which essentially automates the workaround you did. You'll be able to run the script as

./apply-patches.sh --keep

and it will keep the patched mod directories inside "work", instead of zipping them into "output".

You can always view valid command line options by running

./apply-patches.sh --help

What's the status on this issue? I assume you've been using the Patchset without any problems, but I just wanted to check before I closed off this thread.

I don't know about him, but i'm using it on windows with the git bash thing and it works for me.

Sorry for late reply. it still doesn't work without the workaround method, im getting this one now "ERROR: IndustrialRevolution3_4.0.0.zip wasn't created for some reason"

Using the "./apply-patches.sh --keep" workaround still works however

Does it work if you use the "tar" command? How to test:

• Open CMD, PowerShell or Git Bash in the "work" directory which contains IndustrialRevolution3_4.0.0.
• Run tar -a -c -f "IndustrialRevolution3_4.0.0.zip" "IndustrialRevolution3_4.0.0"
• Zip archive should appear inside "work"

yes that works, but i need to first use that workaround to actually get that IR3_4 folder, but i guess you wanted to see if the issue is in repacking process?

Normally on Windows, the script will run this command:

powershell Compress-Archive "IndustrialRevolution3_4.0.0" "IndustrialRevolution3_4.0.0.zip"

This is the most flexible method that works going back to Windows 7. But for some reason it doesn't work for you, every other part of apply-patches.sh is running fine.

The "tar" utility is included in the newer Windows and it can make ZIP files, but strangely enough it doesn't work for me on Linux (probably because I don't have "zip"). So I'll need to make a check for Windows and do some testing there, and hopefully the amended script will be in the next release.

If you want to fix the script yourself, paste these lines into Line 130 (so they go after the 7z branch):

    elif type tar &>/dev/null; then
        zipCmd=('tar' '-a' '-c' '-f')

That didn't work, still the same error. Also i tried removing those additional mods that are not mandatory and im getting more info now.

Unzipping IndustrialRevolution3_3.1.30.zip...
Patching IndustrialRevolution3_3.1.30...
mv: cannot move 'work/IndustrialRevolution3_3.1.30' to 'work/IndustrialRevolution3_4.0.0': Permission denied
Re-zipping IndustrialRevolution3_4.0.0.zip...
ERROR: IndustrialRevolution3_4.0.0.zip wasn't created for some reason

That permission denied error wasn't there when i had those additional mods in

If you open Git BASH from the top Patchset directory and run

chmod -R +w .

to enable write-permission for all directories and files, does this change anything?

no. though now there is no permission denied error.

Since im the only one with this issue and workaround still works, then its ok to not spend too much time on this one. its not that important to have them in packed form