- Oct 24, 2019
- 1,391
- 1,087
You can try to retrofit it into whatever the last version of the Renpy SDK that had 32 bit support. I'm a Linux guy so don't follow this sort of trivia, but I do have to use the same method whenever a jerk dev doesn't bother to gen for anything other than a M$ winders platform.
Method 1 involves downloading this SDK and then using it to create a new empty project that you can call Milky_Touch or whatever. Use whatever settings and resolutions you want since it won't matter. Exit the SDK. Go the folder where Renpy stores it's projects to enter the Milky_Touch project folder you just created. Delete the game sub-folder from this project and copy the game subfolder over from your Milky_Touch download. Restart the SDK and then use it to run the Project.
By some miracle everything might just work without a hitch. However the bytecode generated from the source delivered by the dev was done in a newer Renpy SDK and that might cause everything to barf. So you may have to delete all of the rpyc files from the game folder and try running the project again. This will force a recompile.
Problem next is that the dev may have buried the source and everything else in an rpa archive. If so, you will need to download whatever tool Winders folk use to rip these things open. Lather rinse repeat on deleting the rpyc if this was the case. However... dev may have been a jerk and only included rpyc bytecode and not the rpy source files. I don't have Milky Touch in front of me so can't confirm if this is going to be the problem. If so, your rpa ripper probably has the unrpyc decompiler included with it so that you can re-create the source files. Lather, rinse, repeat.
Method 2 involves a bit of sleight of hand that steals the 32 bit Renpy runtime from one of your other VN's to stick in place of the 64 bit runtime.
In your Milky Touch VN folder rename the renpy folder out of the way to renpy.orig or whatever. This is a newer SDK's version which might cause problems if you try to keep using it.
From your other VN copy over the renpy folder to replace it. Rename the MilkyTouch.exe by adding a .bak extension or whatever to it. Copy and paste the .exe from the other project over and rename to to EXACTLY match the filename for MilkyTouch.exe that you just renamed. The result should exactly match the filename of the .py script for Milky Touch at this top folder level.
Go into lib for the other VN and you will find a windows-i686 folder there. Copy and paste that in your Milky Touch lib folder alongside its windows-x86_64 folder. In that windows-i686 folder that you just pasted, you will find a .exe with the filename of the VN that you grabbed it from (eg lib/ClockworkPoision.exe). Rename that to be EXACTLY what you have for the MilkyTouch.exe that you have in the top level project folder.
Assuming you renamed everything correctly you will either see MilkyTouch run or do the barf like a champ thing because the bytecode is for the new version. Follow the steps at that point for Method 1.
Method 3. Trash winders and install Linux. Your laptop will probably thank you profusely and run faster. 32 bit Linux support will not be going away because of the whims of some greedy corporate parasites in Redmond WA.
Method 1 involves downloading this SDK and then using it to create a new empty project that you can call Milky_Touch or whatever. Use whatever settings and resolutions you want since it won't matter. Exit the SDK. Go the folder where Renpy stores it's projects to enter the Milky_Touch project folder you just created. Delete the game sub-folder from this project and copy the game subfolder over from your Milky_Touch download. Restart the SDK and then use it to run the Project.
By some miracle everything might just work without a hitch. However the bytecode generated from the source delivered by the dev was done in a newer Renpy SDK and that might cause everything to barf. So you may have to delete all of the rpyc files from the game folder and try running the project again. This will force a recompile.
Problem next is that the dev may have buried the source and everything else in an rpa archive. If so, you will need to download whatever tool Winders folk use to rip these things open. Lather rinse repeat on deleting the rpyc if this was the case. However... dev may have been a jerk and only included rpyc bytecode and not the rpy source files. I don't have Milky Touch in front of me so can't confirm if this is going to be the problem. If so, your rpa ripper probably has the unrpyc decompiler included with it so that you can re-create the source files. Lather, rinse, repeat.
Method 2 involves a bit of sleight of hand that steals the 32 bit Renpy runtime from one of your other VN's to stick in place of the 64 bit runtime.
In your Milky Touch VN folder rename the renpy folder out of the way to renpy.orig or whatever. This is a newer SDK's version which might cause problems if you try to keep using it.
From your other VN copy over the renpy folder to replace it. Rename the MilkyTouch.exe by adding a .bak extension or whatever to it. Copy and paste the .exe from the other project over and rename to to EXACTLY match the filename for MilkyTouch.exe that you just renamed. The result should exactly match the filename of the .py script for Milky Touch at this top folder level.
Go into lib for the other VN and you will find a windows-i686 folder there. Copy and paste that in your Milky Touch lib folder alongside its windows-x86_64 folder. In that windows-i686 folder that you just pasted, you will find a .exe with the filename of the VN that you grabbed it from (eg lib/ClockworkPoision.exe). Rename that to be EXACTLY what you have for the MilkyTouch.exe that you have in the top level project folder.
Assuming you renamed everything correctly you will either see MilkyTouch run or do the barf like a champ thing because the bytecode is for the new version. Follow the steps at that point for Method 1.
Method 3. Trash winders and install Linux. Your laptop will probably thank you profusely and run faster. 32 bit Linux support will not be going away because of the whims of some greedy corporate parasites in Redmond WA.
is there any possible way i can play this final version on a 32 bit laptop?