Tool Ren'Py UnRen.bat v1.0.11d - RPA Extractor, RPYC Decompiler, Console/Developer Menu Enabler

[Sam]

If one is interested: I made last year some improvement(imho) to sam9's unren and made a pull request on github, but so far he reacted not to it. Feel free to test it out.

Apologies, I have limited time and can only work on this every now and again, I will take a look as soon as I can set aside some time.

I was planning on converting UnRen to be a python app for v1.0, with the .bat file just creating the .py file, and executing it using RenPy's bundled python exe. This would give a near identical experience to how it is now, yet make things a lot easier and a lot more stable, not having to mess around with powershell's quirks and give room for new features.

If you're interested I can give you maintainer on the repo and a branch. I hope to be able to allocate some time myself to this sometime next month.

 

[Madeddy]

Wrong Sam

Oh. I'm sorry. But this isn't my fault. Totally not. The forum software made me do it. Damn autocomplete..

Wait, there's a Mac/Linux version of UnRen? Shit, why didn't anyone tell me!

See. You're lucky there is this mad, slightly aged saxon who did tell you about this amazing piece of linux software art, or you would have never known about it.

Apologies, I have limited time and can only work on this every now and again...

Ah no mister. Not needed to apologize. I understand it totally if work and real life make time sparse.

 

[Madeddy]

Sry. Scary text wall ahead.

...run with the game's Python install...

Um. Why would anyone do this? There are RenPy games from 2004 even (Yeah. This sounds extrem thinking about supporting such old games.) and guess which py version they run. Or you say we support just newer games... and in 5 years or so the same question again. (You never know how long a tool lives...)

...with the .bat file just creating the .py file, and executing it using RenPy's bundled python exe. This would give a near identical experience to how it is now, yet make things a lot easier and a lot more stable...

I am not sure i understand this focus on the batch detour, but i take a guess and say you want to support also the users who can not much more as double-click. But i am ok with it. I would say we could provide both versions for use. We have the py file anyway. So basically

a) a batch wrapped version​

b) the raw py version​

will make no extra work or at least minimal.

If you're interested I can give you maintainer on the repo and a branch. I hope to be able to allocate some time myself to this sometime next month.

Good idea. This saves us to spread resources and ourselves over X repos and diff. tools.
I am very much for collaborating on this. I would also like to extend this to other interested devs here if there any. If you're ok with it naturally.

 

[Sam]

I am not sure i understand this focus on the batch detour, but i take a guess and say you want to support also the users who can not much more as double-click. But i am ok with it. I would say we could provide both versions for use.

Exactly that, my goal with UnRen was for it to be super simple, light, no dependencies, and have the source always available for anyone to look through; wrapping the .py with the .bat file will achieve all of this.

Good idea. This saves us to spread resources and ourselves over X repos and diff. tools.
I am very much for collaborating on this. I would also like to extend this to other interested devs here if there any. If you're ok with it naturally.

Sounds good, I've added you as a collaborator to the repo, added a new branch, also commented on your PR.

 

[goobdoob]

Um. Why would anyone do this? There are RenPy games from 2004 even (Yeah. This sounds extrem thinking about supporting such old games.) and guess which py version they run. Or you say we support just newer games... and in 5 years or so the same question again. (You never know how long a tool lives...)

On Windows you can't be sure if there's a Python install. At least on reasonably modern Mac and Linux installs you're guaranteed to have at least Python 2.7. My Mac/Linux port of UnRen relies on this. The Windows version of UnRen uses the game's Python.

 

[anne O'nymous]

On Windows you can't be sure if there's a Python install. [...] The Windows version of UnRen uses the game's Python.

Which would be the same for a 100% Python unren.

What make the size of unren is the menu and the embedded scripts. Move this in a Python script, and you don't need the embedded scripts, nor the menu, leaving really few lines in the batch file. Technically, it need only 2 lines. Practically, 12 are enough and it can even be less.

With more lines, you can even have unren put in a "master directory", and make it search by itself the right instance of Python in one of the sub directories. Then you let the Python part deal with the directory selection to make it works on the right game.

 

[Madeddy]

On Windows you can't be sure if there's a Python install.

Thats the main problem. Beside forcing the MS user to install one, there isn't much what could be done.

At least on reasonably modern Mac and Linux installs you're guaranteed to have at least Python 2.7.

Not anymore. First few of the new releases dropped it already. Others will follow till 2024.

We have py3 since 2008 and py2.7 is nearly dead by now.... But some people will still want to drive with steam locomotives till the end of days. It tires me.
---
If we do a unified Unren AND use the RenPy python from game package, we will need to support at least 2 version. py2.7 and with the next RenPy py3.8. Cumbersome imo. Also, what happens if the directory the user wants to work on has no attached RenPy(and py)? BANG! Exit 1

and you don't need the embedded scripts, nor the menu

What would you do instead of the menu for all the choices?

 

[goobdoob]

Not anymore. First few of the new releases dropped it already. Others will follow till 2024.

We have py3 since 2008 and py2.7 is nearly dead by now.... But some people will still want to drive with steam locomotives till the end of days. It tires me.

Not what I said - AT LEAST Python 2.7. That doesn't exclude Python 3.x.

If we do a unified Unren AND use the RenPy python from game package, we will need to support at least 2 version. py2.7 and with the next RenPy py3.8. Cumbersome imo.

On Windows we have to use the Python in the game. On Mac/Linux, we can use the system Python. Either way, we need to support both Python 2 and Python 3.

It's not that hard to make a script that works on both Python 2 and Python 3. The biggest issue is typically print. That's easily solved with
from __future__ import print_function
at the beginning, and using Python 3 style printing.

Other things can be handled with six:

You must be registered to see the links

 

[anne O'nymous]

Also, what happens if the directory the user wants to work on has no attached RenPy(and py)? BANG! Exit 1

If the user is advanced enough to move the rpyc/rpa files outside of the game directory, then he's also advanced enough to know how to deal with this situation. Generally in this case he also don't use unren, but directly the standalone version of unrpa and/or unrpyc.

What would you do instead of the menu for all the choices?

A menu... but not in the batch file.

It's not that hard to make a script that works on both Python 2 and Python 3.

It's more difficult than you think. There's no backward compatibility between Python 3 and Python 2 ; it's in fact the reason why the branch 3.x was created. And __future__ is, alas, far to solve everything.

Anyway, having a Python 3 compatible script for unren is not the good approach.

There's a reason why PyTom will, once ready, maintain a 7.x (Python 2.x) and a 8.x (Python 3.x) branch ; the 7.x will end only when the 8.x will finally be totally stable.
He will surely not just convert the code of Ren'py, but also probably proceed to many refactoring. The migration being the opportunity for him to get ride of a lot of legacy code obsolete since years ; by example the buttons still understand the "clicked" attribute, that was replaced by "action" something like 8 years ago.
This would gave back its strength to Ren'py and make it ready again for a lot of improvements. This without its actual constraints. But this also include that both the RPA and RPYC "format" risk to change ; especially the RPYC one.

Therefore, until we see what will effectively be the 8.x, we have to assume that it will imply a change in the tools used by unren. Which would lead in the end, to a batch also testing if Ren'py have a "pythonlib2.7" folder, or a "pythonlib3.x" one, and launching the right "Python unren" according to the result of this test.
It will anyway be easier than a single script juggling between Python 2.7 and Python 3.x, and between the old and new formats of Ren'py files. Especially since the version for Ren'py with Python 2.7 will stop to need updates.

 

[Madeddy]

Not what I said - AT LEAST Python 2.7. That doesn't exclude Python 3.x.

True. Overlooked.

...Either way, we need to support both Python 2 and Python 3.

Its a option IMHO, not a need. If you say py2 you need also to decide if you mean "just 2.7.x". Some user will try and use it on older rpy packs. But i think we should draw the line here.

If the user is advanced enough to move the rpyc/rpa files outside of the game directory, then he's also advanced enough to know how to deal with this situation...

Its some hypothesis, but i agree. Basically the "if you experiment, then deal yourself with the outcome" approach.

But this also include that both the RPA and RPYC "format" risk to change ; especially the RPYC one.

The RPA stuff isn't this complex "if something changes" and i dont think it will. The compiler troubles me more because this stuff is a bit scary IMO. And...it has already changed as we know.

It will anyway be easier than a single script juggling between Python 2.7 and Python 3.x, and between the old and new formats of Ren'py files.

If we support both, i tend to agree. The 2.7 version should then pretty much "bugfix only" if it reached stable.

Oh. And i nearly forgot the tools: unrpyc uses atm still py2, but how long? And then? Unrpa switched to py 3.7+, i go in RpaKit with 3.6+ and rpatool will possible stay with 2.7+.

Bah...
I am this >||< much distance away from saying "frack this versions hassle and lets ship a py interpreter + needed packs with the script. Perhaps a bit crazy.

 

[drpanda]

I'm having trouble copying into the games exe file which i cannot find what it is

 

[TheSexinati]

Strange.

Recently, whenever I click on Unren, it opens for only around half a second as a small screen and then automatically closes. I am using Windows 7 with Unren 8.

It has always worked except for around a week or two ago.

 

[goobdoob]

Strange.

Recently, whenever I click on Unren, it opens for only around half a second as a small screen and then automatically closes. I am using Windows 7 with Unren 8.

It has always worked except for around a week or two ago.

What happens if you run it from a cmd window?

 

[TheSexinati]

My command prompt does the exact same thing.

 

[anne O'nymous]

My command prompt does the exact same thing.

Er... It's not the behavior it should have. The window should stay on and have no reason to close after the program failed.

 

[TheSexinati]

Er... It's not the behavior it should have. The window should stay on and have no reason to close after the program failed.

Thanks, I'm going to do some searching around to see what the problem is.

Fingers crossed, It's not a virus!

 

[xxxavier]

So by reading the first page there is one thing I don't understand: does 0.9 update work or has issues? And what kind of issues? Don't risk to create problems to the pc, does it? I'm asking because I have the same problem has reported earlier, after I use it to decompile the rpyc it crashes the game and I can start. I'm a noob for those kind of things I admit it, but anyone have a solution for this? does 0.9 work better? Thanks

 

[goobdoob]

So by reading the first page there is one thing I don't understand: does 0.9 update work or has issues? And what kind of issues? Don't risk to create problems to the pc, does it? I'm asking because I have the same problem has reported earlier, after I use it to decompile the rpyc it crashes the game and I can start. I'm a noob for those kind of things I admit it, but anyone have a solution for this? does 0.9 work better? Thanks

unrpyc, which UnRen uses, has bugs in it. The fix for those bugs doesn't always work.

Suggestion - don't run games that you've unpacked rpas/decompiled rpycs. If you want to mod something, remove all extracted rpycs/rpys except the ones you want to modify, then fix those. If you don't know how to fix them, learn Python. Or don't do it.

If you just want to look at the images/scripts, run UnRen on a copy.

 

[xxxavier]

Thanks, I guess I'll try learn python if I can figure it out then

 

[Madeddy]

...And what kind of issues? Don't risk to create problems to the pc, does it? ...

unrpyc, which UnRen uses, has bugs in it. The fix for those bugs doesn't always work.
...

RenPy did change beginning spring last year some of his code, so the decompiling with "unrpyc" did get incompatible because it doesnt understand RenPy anymore. Its like a "new slang" now for RenPy and "unrpyc" speaks just the old slang.

The author of "unrpyc" is currenty in the process of fixing the incompatiblitys. We can expect a immediate bugfix release of "unrpyc". Just a few things left... (Like.. me pestering him with more bug reports.)

Thanks, I guess I'll try learn python if I can figure it out then

You sound like you expect this "learning python" will happen in a few months... with barely a few horus per week invested. Um, no. It's more like "See you in 2 years".