Sorry to say but this part-fix works in this one case, but will error in all other situations.
You missed the i-686 line a few above, which is for the case the user has unren copied "into" the
game dir, and not in the games
base dir what is the standard.
Code:
REM Variable setup where unren sits in the directory "game"
set "pythondir=%currentdir%..\lib\windows-i686\"
set "renpydir=%currentdir%..\renpy\"
set "gamedir=%currentdir%"
REM Check if unren is in the games base dir: If FALSE the vars stay like set before
REM and we pretend unren sits in "game"; If TRUE we change the vars slighly
if exist "game" if exist "lib" if exist "renpy" (
set "pythondir=%currentdir%lib\windows-i686\"
set "renpydir=%currentdir%renpy\"
set "gamedir=%currentdir%game\"
This statement is incorrect.
Renpy added just the python 64 bit librarys( \lib\windows-x86_64) for windows and some game devs decide to deliver the game just with them and without the librarys for (old)32 bit systems(\lib\windows-i686).
If we have now a modified Unren for just this case, it will not work on 32 bit games. Like the original unren for 64 bit games. Users will every time need to look what variant the game has. Some have also both.
Unlikely to work if a user wants to use decompiling. The unren version 0.8 works not for newer games since RenPy 7.2 syntax changed nearly 2 years back. You need to use v0.9-dev... but in this version unrypc is broken for good if we have Renpy-7.3 game and newer.
Just as info so nobody wonders.
Yeah, i think that situation is called a clusterfuck. Or worse.
As temporary solution users can also try and use a modded unren from user
VepsrP in the last pages of unren thread. Trys to address this problem and adds a new unrpyc.