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

[Nemo56]

Is it just me or my command prompt decided I'm need to used magnifying glass ?
Does anyone know how to resized it ? I'm using UnRen-1.0.11d
View attachment 2701774

This has nothing to do with unren.

You must be registered to see the links

 

[fried]

is it intended that all temporary files from the unren action are left in the folder?

the previous versions deleted them

View attachment 2701986

and if i use option 8 - the dev/console/rollback are not activated
i have to extra use option 7

Whoops, I accidentally shared the debug version.

Download updated, thanks. It will automatically clean things up on the next run.

 

[Boehser Onkel]

Whoops, I accidentally shared the debug version.

Download updated, thanks. It will automatically clean things up on the next run.

thank you

 

[somewherexxx]

I don't know about the dude you were quoting, but I'm getting it with the 1.0.10b I just downloaded

i solved multiprocessing error by deleting that folder from lib\python3.9\
and then used unren
dunno what was that doing there , maybe dev of game put it there intentionally to sabotage unren

 

[josemaloco]

i solved multiprocessing error by deleting that folder from lib\python3.9\
and then used unren
dunno what was that doing there , maybe dev of game put it there intentionally to sabotage unren

That was it, thanks for the tip.

The game Lycoris Radiata has it for example.

 

[Night Hacker]

I just used unRPYC on some scripts and this is a bit off topic, but I am noticing someone using "if True" after every menu choice question. This makes no sense to me at all as that just means to display the menu choice if True... ummm... and True will always be True... am I missing something here? Looks to me like someone is learning to code and getting this wrong. It seems obviously wrong, but I am thinking... maybe I am missing something here?

 

[Night Hacker]

i solved multiprocessing error by deleting that folder from lib\python3.9\
and then used unren
dunno what was that doing there , maybe dev of game put it there intentionally to sabotage unren

Which folder would that be that you deleted? (sorry, I missed it)

 

[VepsrP]

I just used unRPYC on some scripts and this is a bit off topic, but I am noticing someone using "if True" after every menu choice question. This makes no sense to me at all as that just means to display the menu choice if True... ummm... and True will always be True... am I missing something here? Looks to me like someone is learning to code and getting this wrong. It seems obviously wrong, but I am thinking... maybe I am missing something here?

probably elif true.
This is a problem of processing compiled code in new versions of the engine. There, the usual else has a True condition that needs to be handled differently than any other normal condition. This tool uses a decompiler that has not been updated for a long time, fried does what he can to keep the tool up to date. But in my version, this place is handled correctly. It can also be in the selection menu, where, if there is no condition, "if true" is put in the compiled code.

 

[somewherexxx]

Which folder would that be that you deleted? (sorry, I missed it)

game folder
open game then u see
\game
\lib
\renpy

inside \lib folder is \python3.9\ and in it is folder multiprocessing
so just delete that multiprocessing folder entirely with all files with in it

 

[Night Hacker]

game folder
open game then u see
\game
\lib
\renpy

inside \lib folder is \python3.9\ and in it is folder multiprocessing
so just delete that multiprocessing folder entirely with all files with in it

Ah, I thought that is what it might be. I looked inside my python folder, but didn't see that and figured I may not have fully understood you. Thanks. I don't really need this fix at the moment, but it's a good tip to keep in mind for the future. Thanks.

 

[Night Hacker]

probably elif true.
This is a problem of processing compiled code in new versions of the engine. There, the usual else has a True condition that needs to be handled differently than any other normal condition. This tool uses a decompiler that has not been updated for a long time, fried does what he can to keep the tool up to date. But in my version, this place is handled correctly. It can also be in the selection menu, where, if there is no condition, "if true" is put in the compiled code.

Interesting. I'm an old C programmer so seeing that in code didn't make sense to me (still doesn't to be honest).

I always have

if condition:
   #do stuff here
else:
   #do alternate stuff

works fine.

 

[VepsrP]

Interesting. I'm an old C programmer so seeing that in code didn't make sense to me (still doesn't to be honest).

I always have

if condition:
   #do stuff here
else:
   #do alternate stuff

works fine.

Yes, but I'm not talking about the source code, but about how it is written to the ast tree, which is essentially compiled python code. If I remember correctly, the tree does not specify if or else, it is determined by the order and level of nesting. And each element has its own condition. "True" for "else" and more meaningful for everyone else.

 

[Night Hacker]

Yes, but I'm not talking about the source code, but about how it is written to the ast tree, which is essentially compiled python code. If I remember correctly, the tree does not specify if or else, it is determined by the order and level of nesting. And each element has its own condition. "True" for "else" and more meaningful for everyone else.

Well NO compiled code looks like the original source. Not in C, not in Python or anything else.

I just couldn't figure out why there's "elif True" or "if True" after menu options, it doesn't make any sense and isn't needed. It's just poor coding (you can read more about conditional statements

You must be registered to see the links

)

 

[VepsrP]

Well NO compiled code looks like the original source. Not in C, not in Python or anything else.

I just couldn't figure out why there's "elif True" or "if True" after menu options, it doesn't make any sense and isn't needed. It's just poor coding (you can read more about conditional statements

You must be registered to see the links

)

python is an interpreted language, it is not compiled into machine code, but rather into a kind of preprocessing in C languages or something like that, I will later show you the ast tree located in rpyc files and encoded with byte code.

 

[VepsrP]

Well NO compiled code looks like the original source. Not in C, not in Python or anything else.

I just couldn't figure out why there's "elif True" or "if True" after menu options, it doesn't make any sense and isn't needed. It's just poor coding (you can read more about conditional statements

You must be registered to see the links

)

Spoiler: AST tree

You don't have permission to view the spoiler content. Log in or register now.

Here is a piece of AST tree dump. As you can see, the IF element contains two entries in tuples. The first element of each tuple is the condition under which this entrie will be executed.

First checks "taboopatch" variable.

<renpy.ast.PyExpr
    .filename = 'game/Day Scripts/day1script.rpy',
    .linenumber = 32,
    .py = 3
    > = 'taboopatch',

Second indicates execution in any case, if the previous conditions were not executed.

'True',

because of this "True" decompiler in this tool does not process these places correctly, which is why such strange conditions are obtained. They were not written by the authors of the games, but by the decompiler after incorrect processing of this construction.

 

[dikau]

... the ast tree ...

The abstract syntax tree tree ?

 

[Night Hacker]

Spoiler: AST tree

You don't have permission to view the spoiler content. Log in or register now.

Here is a piece of AST tree dump. As you can see, the IF element contains two entries in tuples. The first element of each tuple is the condition under which this entrie will be executed.

First checks "taboopatch" variable.

<renpy.ast.PyExpr
    .filename = 'game/Day Scripts/day1script.rpy',
    .linenumber = 32,
    .py = 3
    > = 'taboopatch',

Second indicates execution in any case, if the previous conditions were not executed.

'True',

because of this "True" decompiler in this tool does not process these places correctly, which is why such strange conditions are obtained. They were not written by the authors of the games, but by the decompiler after incorrect processing of this construction.

Ah! Okay, that makes more sense to me now. Well, in that case, not a big problem, the code will still run... it's just, after decades of programming, my brain was having difficulty looking at that! LOL

 

[VepsrP]

The abstract syntax tree tree ?

I don't remember the transcript, so for me it's ast tree

 

[Sancho1969]

Spoiler: AST tree

You don't have permission to view the spoiler content. Log in or register now.

Here is a piece of AST tree dump. As you can see, the IF element contains two entries in tuples. The first element of each tuple is the condition under which this entrie will be executed.

First checks "taboopatch" variable.

<renpy.ast.PyExpr
    .filename = 'game/Day Scripts/day1script.rpy',
    .linenumber = 32,
    .py = 3
    > = 'taboopatch',

Second indicates execution in any case, if the previous conditions were not executed.

'True',

because of this "True" decompiler in this tool does not process these places correctly, which is why such strange conditions are obtained. They were not written by the authors of the games, but by the decompiler after incorrect processing of this construction.

Ultrahack (for example) doesn't have this issue. Just saying it doesn't have to be the way you describe. It's been brought up before, along with some other syntax bugs that need to be addressed. The old original unren had these same conditional syntax issues. Night Hacker, you can possibly obtain different results depending on the decompiler you are using... just know it's a thing. I get many original scripts from various developers and always compare a decompiler or two against them to insure I personally don't have syntax abnormalities in my work (just an FYI).

 

[VepsrP]

Ultrahack (for example) doesn't have this issue.

This is because I spent quite a lot of time correcting all these inaccuracies, how long do my abilities last, as well as as other users find them.