- Jan 16, 2018
- 447
- 519
Modded V0.9 cause I was bored and hate the old method when I am doing multiple games in a day.
- Sep 17, 2018
- 4,451
- 5,665
- Jun 10, 2017
- 11,009
- 16,295
I second this.
Intuitively I assume that it permit to works with more that one game at once, or to proceed each game faster, but which one of those, and how ?
Is this a "put on the main folder where all your games are, and it will proceed them all" ?
Or a "put on the main folder where all your games are, then choose which game have to be proceeded" ? [Side note: this one would be great if it's not that]
Or perhaps something totally different ?
- Jun 7, 2018
- 710
- 1,753
Judging by screenshots Haley's combines unpacking and decompiling in one step.
- Jan 16, 2018
- 447
- 519
I just made it so that you extract the .rpa and decompile the .rpyc as a single step. So that its a one button without the extra steps like what 9 does or doing one resting then doing the other. (still one game at a time just faster per game)
- Aug 22, 2018
- 157
- 86
when I run the tool on any of the options whole PC kinda freezes up,I cannot open anything new except alt tab-ing the windows that are already up...why is that?
- Dec 17, 2017
- 848
- 500
View attachment Screenshot_20191121_1.webp
"pt" in the path column is the shortname for the game i use for this. Thats where the unren script must be located. See the lib directory? There is python... See next image:
View attachment Screenshot_20191121_2.webp
I guess youre on windows, or? If the script is in the game root dir like shown in image1 and ".../lib/windows-i686" is there like in image2, then your error message shouldn be there.
All of this is correct and still this error? From the game root dir the scripts finds python in there normaly.
Dammit. Why are the images not shown and only links? Its because webp?
"pt" in the path column is the shortname for the game i use for this. Thats where the unren script must be located. See the lib directory? There is python... See next image:
View attachment Screenshot_20191121_2.webp
I guess youre on windows, or? If the script is in the game root dir like shown in image1 and ".../lib/windows-i686" is there like in image2, then your error message shouldn be there.
All of this is correct and still this error? From the game root dir the scripts finds python in there normaly.
Dammit. Why are the images not shown and only links? Its because webp?
Last edited:
What is the full path in which you have unpacked the game (and UnRen)?
If the path is too long, you can get that error.
- Apr 10, 2017
- 1,098
- 2,505
Could I get your permission to create a batch script like UnRen for it so it would extract all RPC files?
- Apr 10, 2017
- 1,098
- 2,505
- Jan 27, 2017
- 7,822
- 24,411
if you feel the need...
we live in a free world and even more this is a pirate forum, so ¯\_( ͡° ͜ʖ ͡°)_/¯
- Apr 10, 2017
- 1,098
- 2,505
I've posted the modified version here: UnRen.bat v0.8 (Modified) - RPA/RPC Extractor, RPYC Decompiler, Console/Developer Menu Enabler
- Dec 17, 2017
- 848
- 500
Oh my.
There are no real "rpc" files for RenPy.
That is a RPA. Name extension was changed for one letter. Its the same as with the first RPA used by RenPy, who did have "rpi" as extension. Just for info.
This thread is full of variations like this one. And there are more. I we make a tool or UnRen mod for every obfuscating attempt of the game devs, we need a whole forum for just them. But go on. Its your time.
Btw. Someone here dealed with sunshine valley already: post-2559762
There are no real "rpc" files for RenPy.
That is a RPA. Name extension was changed for one letter. Its the same as with the first RPA used by RenPy, who did have "rpi" as extension. Just for info.This thread is full of variations like this one. And there are more. I we make a tool or UnRen mod for every obfuscating attempt of the game devs, we need a whole forum for just them. But go on. Its your time.
Btw. Someone here dealed with sunshine valley already: post-2559762
Last edited:
- Sep 17, 2018
- 4,451
- 5,665
Hi guys,
does anybody have an explanation for the strange thing that happens when extracting Summertime Saga 0.19.1?
Problem (apart from the known stuff like some line indentations being wrong) is that, once everything is working and the game running, some layered images do not work as expected. For instance, the game has an automatic talk recognition, meaning that when a character is shown with a face attribute like e.g. "f_smile", then this is replaced automatically with something like "f_smile_talk" when he says something.
Now this works as long as both images are physically available. In some cases, the game provides only the non-talking face image, and in this case even when the char is talking, the non-talking variant is shown.
This is achieved by an image statement like
renpy.image("char_face_talk_f_smile", "char_face_f_smile")
assuming that the files is named "char_face_f_smile.png" in the images directory.
What I do not understand is that some talk variants of faces are neither existing on disk in the image directory, nor is there such an image statement. Nevertheless, in the unextracted game it works, but not any longer as soon as the game files are extracted. In that case, a blank face is shown.
It should be noted that the files defining (or in this case not defining) the layeredimage and the mapping image statements are different from the file where the problematic dialog occurs. And as soon as the file containing the dialog is extracted (available as *.rpy), the error occurs.
Very strange.
As soon as I manually define such an image statement like the one above, everything works as expected in the extracted game.
does anybody have an explanation for the strange thing that happens when extracting Summertime Saga 0.19.1?
Problem (apart from the known stuff like some line indentations being wrong) is that, once everything is working and the game running, some layered images do not work as expected. For instance, the game has an automatic talk recognition, meaning that when a character is shown with a face attribute like e.g. "f_smile", then this is replaced automatically with something like "f_smile_talk" when he says something.
Now this works as long as both images are physically available. In some cases, the game provides only the non-talking face image, and in this case even when the char is talking, the non-talking variant is shown.
This is achieved by an image statement like
renpy.image("char_face_talk_f_smile", "char_face_f_smile")
assuming that the files is named "char_face_f_smile.png" in the images directory.
What I do not understand is that some talk variants of faces are neither existing on disk in the image directory, nor is there such an image statement. Nevertheless, in the unextracted game it works, but not any longer as soon as the game files are extracted. In that case, a blank face is shown.
It should be noted that the files defining (or in this case not defining) the layeredimage and the mapping image statements are different from the file where the problematic dialog occurs. And as soon as the file containing the dialog is extracted (available as *.rpy), the error occurs.
Very strange.
As soon as I manually define such an image statement like the one above, everything works as expected in the extracted game.
- Dec 17, 2017
- 7,426
- 9,695
"As soon as the file containing the dialog is extracted"...what do you mean by this?
Are you using UnRen to pull out the rpy files and trying to run the game like that?
Don't do that. If you want to read the script, make a copy and UnRen the copy. Don't try running the UnRen'd version.
Also, a little reading of this thread will reveal that the version of unrpyc in UnRen doesn't handle layered images.