Encon

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]I haven't tested that file yet, but my speculation that somehow renaming fixed corruption would be the new file is larger than the old one? When new file file is larger, it goes to a different mechanism..[/color]

That might be the case, yeah. I don't remember what the file sizes were when I replaced them, but I just used a different item's sprite files to do it, so it's definitely possible they were larger files.

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]There isn't any known issue, but I have changed a lot in the code. So it could be regression happening. If you have reproducible problematic patch file, send them to me.[/color]

Well, there isn't any duplicate file detection because it would decrease performance.

https://www.mediafir...rymv44z6l2122c9

The "Corrupted" folder is the original patch that failed, I believe it was the textureÀ¯ÀúÀÎÅÍÆäÀ̽º[email protected] and [email protected] files that were corrupt. The "Clean Repatch" folder was my attempt to fix it by repatching the original files, but it failed to repatch them. I left the original data files in there as well so you can see that the originals weren't corrupt.

As a note, I found out that if I add a patch with a different file using the same name, then patch the original file again, it usually fixes it. So for example, if HeadgearA.spr gets corrupted, I could just rename RandomHG.spr to HeadgearA.spr, patch it, then patch in the original HeadgearA.spr again and it wouldn't be corrupted anymore. It definitely seems like there's something preventing it from repatching identical files, so maybe it's integrated into the GRF library you're using or something.

http://superuser.com/a/605012

^ That explains how to make the patcher run as admin automatically, for all those that have been asking. It requires the Windows SDK (which is free) to do so, but it only take a few minutes to set it up.

By the way, Aeomin, there seems to be some kind of issue with the newest version (2.6.4.8) giving corrupt patches. I know for a fact that the files I'm patching aren't corrupt (if I put them in a GRF myself they work fine, and even viewing in Windows via thumbnail shows up fine), but as soon as I patch them using the latest Thor they'll be corrupt. It only happens with a few select files, but if I try to re-patch them (again, using the clean, non-corrupt files), they'll still be corrupt. If I try patching those same files in again with a new file name, they'll suddenly be okay.

Which leads me to 2 questions:

1) Is there a known issue with certain files or file names not being packed properly by Thor? It seems to happen with various file types (.spr, .bmp, etc), so I'm not sure exactly what causes the corruption. It's definitely not a problem with the original files, though.

2) Does the new patcher have some kind of check to avoid duplicate files being patched in? It seems odd that I can't just re-patch the clean files to fix them, and doing multiple patches so I can rename corrupt files is a little excessive.