Tool Ren'Py UnRenGUI, UnRen-forall(v9.4), UnRen-Powershell-forall(v9.4), UnRen-old

[Madeddy]

Thanks for taking a look!

...in the RevertableDict class __module__ = "renpy.python", then errors appear in some files, and if __module__ = "renpy.revertable", then in others...

Well...SHIT!
That's what i feared.

...in some compiled files there is simply the old format of this class and it is not possible to decompile both variants at the same time, since the __module__ variable can be set only once.

Hm, do you think its possible to build a switch between both? If one variant fails we catch the exception and run it in the other... Or we put the files with this exception in a list and run it in the end with the other module.

 

[dikau]

Madeddy, isn't there already a

You must be registered to see the links

? (also see line 119-120)
I guess that is what Vepsr trying to say on the post above you

 

[Madeddy]

No. Not as i understand it.

1. VepsrP unrpyc version depends in some places on renpy, while the normal unrpyc does not.
   He imports some renpy modules and functionality to avoid some traps which code changes in renpy cause or some game devs set in their code, to prevent decompiling.
2. His unrpyc has many such switches to support py2 and py3 withhin the same version. My versions i work on have the one python or the other.
3. The "switch" you pointed too is IMHO one of them.
   1. He try's to imports from directory renpy the py module revertable(renpy.revertable) which exists only since version 7.5 and 8.
   2. Before this (v7.4) the code from revertable was part of renpy.python, so this is imported if revertable isnt there. This means its a old renpy version (7.4 or older) and in py2.

Also, something isn't right about this statement that renpy.python decompiles file 1, but errors on file 2 and with renpy.revertable it's reverse. I testing now for days with the game estrada777 posted here: https://f95zone.to/threads/unren-ol...-0-unren-powershellhack-v6.92717/post-9363734
Using renpy.revertable gives me just one error type in three files and using renpy.python gives me the same error(!) in the same three files and another one for five more files.

Spoiler: Example code of the two error types

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

Like said, the first error appears with renpy.revertable and with renpy.python both appear. Thats with the py3_v1.1.8 branch version from my github.
Testing with VepsrP unren ultrahack on the same game fails also. The same error i get and a new error type. See here: https://f95zone.to/threads/unren-ol...-0-unren-powershellhack-v6.92717/post-9368018

Looks like we both fail so far on the same dumb error. Maddening.

 

[dikau]

I'm sorry if I muddled your discussion with VepsrP

Here's from what I understand:
1. If a developer created a game on older engine and later update their game with newer engine, but he didn't "force recompile" his game, then this things happen, old rpyc still in the game
2. even though the newer engine can still process the old rpyc(s), but Vepsrp said that the unrpyc scripts he uses can't support that type of scenario (at least right now?).

which is weird tho... because his unrpyc uses the game's engine python so it should also process those old rpycs. Maybe worth checking out how

You must be registered to see the links

module works to see how the engine can process the old rpyc(s).

 

[VepsrP]

I'm sorry if I muddled your discussion with VepsrP

Here's from what I understand:
1. If a developer created a game on older engine and later update their game with newer engine, but he didn't "force recompile" his game, then this things happen, old rpyc still in the game
2. even though the newer engine can still process the old rpyc(s), but Vepsrp said that the unrpyc scripts he uses can't support that type of scenario (at least right now?).

which is weird tho... because his unrpyc uses the game's engine python so it should also process those old rpycs. Maybe worth checking out how

You must be registered to see the links

module works to see how the engine can process the old rpyc(s).

The trick is that un.rpyc only forms once how to handle these Revertables. The processing is done by the "renpy" created by the magic module, and not by the game engine, so if the signatures do not match, then the fake_package "renpy" does not know how to process it and throws an error. Lines 188 and 219 "class_factory" variable, which determines which Revertables will be processed and which will give errors.

 

[VepsrP]

No. Not as i understand it.

1. VepsrP unrpyc version depends in some places on renpy, while the normal unrpyc does not.
   He imports some renpy modules and functionality to avoid some traps which code changes in renpy cause or some game devs set in their code, to prevent decompiling.
2. His unrpyc has many such switches to support py2 and py3 withhin the same version. My versions i work on have the one python or the other.
3. The "switch" you pointed too is IMHO one of them.
   1. He try's to imports from directory renpy the py module revertable(renpy.revertable) which exists only since version 7.5 and 8.
   2. Before this (v7.4) the code from revertable was part of renpy.python, so this is imported if revertable isnt there. This means its a old renpy version (7.4 or older) and in py2.

Also, something isn't right about this statement that renpy.python decompiles file 1, but errors on file 2 and with renpy.revertable it's reverse. I testing now for days with the game estrada777 posted here: https://f95zone.to/threads/unren-ol...-0-unren-powershellhack-v6.92717/post-9363734
Using renpy.revertable gives me just one error type in three files and using renpy.python gives me the same error(!) in the same three files and another one for five more files.

Spoiler: Example code of the two error types

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

Like said, the first error appears with renpy.revertable and with renpy.python both appear. Thats with the py3_v1.1.8 branch version from my github.
Testing with VepsrP unren ultrahack on the same game fails also. The same error i get and a new error type. See here: https://f95zone.to/threads/unren-ol...-0-unren-powershellhack-v6.92717/post-9368018

Looks like we both fail so far on the same dumb error. Maddening.

Well, I kind of solved the problem. You can see the changes in the

You must be registered to see the links

. But now, for some reason, a new error pops up and I haven't figured out how to solve it yet, given that even print(dir(SL Screen)) throws an error and doesn't check what's inside this variable.

Spoiler: SLScreen Error

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

 

[Madeddy]

I'm sorry if I muddled your discussion with VepsrP ...

Thats quit alright. I even appreciate an additional opinion. You never know what another mind can add and theres a chance its at least interesting.
With your points 1 and 2 you're correct i think.

...which is weird tho... because his unrpyc uses the game's engine python so it should also process those old rpycs...

Ahh... no. Unrpyc doesn't depend on RenPy code. Its for many years already stand alone. VepsrP's could be depending on it, but i am not sure. He imports some stuff like i mentioned already up there somewhere.

Well, I kind of solved the problem. You can see the changes in the

You must be registered to see the links

. ...

Well, frak me sideways. This works actually , but i don't understand why not before. I did try in the last days to switch between the python/revertable modules like five times and got very time the same error from three files. What could have happened?

1. The same error came from three different files and i did simply not notice in the error output.
2. The same error came from the same three files, but from different code parts.

Whatever its was, its gone now. Very good and thanks.

Spoiler: YEAH!

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

The trick is that un.rpyc only forms once how to handle these Revertables. The processing is done by the "renpy" created by the magic module, and not by the game engine, so if the signatures do not match, then the fake_package "renpy" does not know how to process it and throws an error. Lines 188 and 219 "class_factory" variable, which determines which Revertables will be processed and which will give errors.

I understand. And there is a way around the "forming just once".
I did the code for this a bit different from yours, but it works all the same. You can later look it up in my GH if you want. (I haven't pushed it upstream yet. Later...Some stuff to do on it still.)

Greets

 

[WarriorSteel]

Do anyone know why I am getting this error?

 

[VepsrP]

View attachment 2167536
Do anyone know why I am getting this error?

The game should be on too old engine, try UnRen-old for this.

 

[VepsrP]

Well, frak me sideways. This works actually , but i don't understand why not before. I did try in the last days to switch between the python/revertable modules like five times and got very time the same error from three files. What could have happened?

1. The same error came from three different files and i did simply not notice in the error output.
2. The same error came from the same three files, but from different code parts.

Probably still the first. Otherwise, even with the replacement, an error would fly out, and it is impossible to have two different versions of this structure in one file.

 

[Madeddy]

I did'n forget, wanted just to hold the text wall up there a bit shorter.

...But now, for some reason, a new error pops up and I haven't figured out how to solve it yet...

You have in your unrpyc version a lot of changes and additional code i haven't, and by some of them i am not sure what they do. The switches for py2/py3 i understand, the code for the check on the .rpyc script file header and the "async" -> "acyncr" code are also. But other stuff in sl2decomp, screendecomp, init (@ dispatch ...stuff [huh?]) i do not understand the reason for.

Regardless, you did use my code in "sl2decomp" for a py3 incompatiblity problem and did some changes on it as you broke up the ternary's. I think from the second of them could come the error you get(line353 in your file):
if i.location[1] > last_keyword_line: Yours is different in meaning. Just test it with my exact code in this part. I remember just this problem was quit bothersome. Something with "a line comparison with zero(0)" and i needed to use a negative value to get around it...

Also, you have in your unrpyc version many chnges missing which should be needed for py3 compatibility. For example all the "unicode" cases should be switched with "str". I think i have all the changes for py3 i the "py3_v1.1.8_legacy" branch(not the changes for renpy7.5/8) if you want to have a look and compare.

 

[VepsrP]

I did'n forget, wanted just to hold the text wall up there a bit shorter.

You have in your unrpyc version a lot of changes and additional code i haven't, and by some of them i am not sure what they do. The switches for py2/py3 i understand, the code for the check on the .rpyc script file header and the "async" -> "acyncr" code are also. But other stuff in sl2decomp, screendecomp, init (@ dispatch ...stuff [huh?]) i do not understand the reason for.

Regardless, you did use my code in "sl2decomp" for a py3 incompatiblity problem and did some changes on it as you broke up the ternary's. I think from the second of them could come the error you get(line353 in your file):
if i.location[1] > last_keyword_line: Yours is different in meaning. Just test it with my exact code in this part. I remember just this problem was quit bothersome. Something with "a line comparison with zero(0)" and i needed to use a negative value to get around it...

Also, you have in your unrpyc version many chnges missing which should be needed for py3 compatibility. For example all the "unicode" cases should be switched with "str". I think i have all the changes for py3 i the "py3_v1.1.8_legacy" branch(not the changes for renpy7.5/8) if you want to have a look and compare.

A lot of changes just concern unicode and py3. Therefore, I first check the python version, and then check it correctly for compliance with the string type. About the new dispatch - a new PostUserStatement class has been added to renpy.ast and some games are already using it, I had to write my own handler, just like for the RPY class. Some changes relate only to certain games (for example, the store module and its displayable_names - one developer decided to write his own code that will work with styles, I don't remember whether it was fully or partially possible to decompile his code). As for SLScreen, I would understand if it was just a matter of location, but even a simple "dir" command gives an error in this place, which in theory should not be.

Spoiler: error 2

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

 

[VepsrP]

I did'n forget, wanted just to hold the text wall up there a bit shorter.

You have in your unrpyc version a lot of changes and additional code i haven't, and by some of them i am not sure what they do. The switches for py2/py3 i understand, the code for the check on the .rpyc script file header and the "async" -> "acyncr" code are also. But other stuff in sl2decomp, screendecomp, init (@ dispatch ...stuff [huh?]) i do not understand the reason for.

Regardless, you did use my code in "sl2decomp" for a py3 incompatiblity problem and did some changes on it as you broke up the ternary's. I think from the second of them could come the error you get(line353 in your file):
if i.location[1] > last_keyword_line: Yours is different in meaning. Just test it with my exact code in this part. I remember just this problem was quit bothersome. Something with "a line comparison with zero(0)" and i needed to use a negative value to get around it...

Also, you have in your unrpyc version many chnges missing which should be needed for py3 compatibility. For example all the "unicode" cases should be switched with "str". I think i have all the changes for py3 i the "py3_v1.1.8_legacy" branch(not the changes for renpy7.5/8) if you want to have a look and compare.

Well, I figured out what the problem is, now I just need to remember how it is solved. It's just that all objects have string-type properties, namely this object of all - bytes. That is, others have "location", and he has b"location". This game is just a mess of files of all possible mess available to humanity.

 

[Madeddy]

... About the new dispatch - a new PostUserStatement class has been added to renpy.ast and some games are already using it, I had to write my own handler, just like for the RPY class....

Gods no. Not more of this incompatible sh*t. Good thing you have it already tackled and managed from the sound of it. On the other hand,

You must be registered to see the links

and the code for this is already 3½ years in Ren'py and just now being used? After all this time unrpyc should have compatibility code for a long time already.

Anyway if i see your error i can just say this looks very much like a incompatibility between data types. What i said before. The pleasure of py2-unicode and py2-bytes and py3-str(utf8) and py3-bytes. Types and encoding... what a fun. I can be wrong, but it think your error comes from the mix in your files.

That is, others have "location", and he has b"location"

"location" is a str in utf8 i would say and b'location is bytes. You just need to utf8 decode it from bytes to str for py3 and the b' is gone.

I think, you should really decide if you want to stay with a py2/py3 hybrid version or to move to a single version of unrpyc. I mean py2 is now out of the door - no need to try riding a death horse. Supporting Ren'py legacy up to v7.4 can be done with current unrpyc, even with py3. And for v7.5+ we do not need py2.

 

[VepsrP]

Gods no. Not more of this incompatible sh*t. Good thing you have it already tackled and managed from the sound of it. On the other hand,

You must be registered to see the links

and the code for this is already 3½ years in Ren'py and just now being used? After all this time unrpyc should have compatibility code for a long time already.

Anyway if i see your error i can just say this looks very much like a incompatibility between data types. What i said before. The pleasure of py2-unicode and py2-bytes and py3-str(utf8) and py3-bytes. Types and encoding... what a fun. I can be wrong, but it think your error comes from the mix in your files.
"location" is a str in utf8 i would say and b'location is bytes. You just need to utf8 decode it from bytes to str for py3 and the b' is gone.

I think, you should really decide if you want to stay with a py2/py3 hybrid version or to move to a single version of unrpyc. I mean py2 is now out of the door - no need to try riding a death horse. Supporting Ren'py legacy up to v7.4 can be done with current unrpyc, even with py3. And for v7.5+ we do not need py2.

It seems to me that you are confusing something, 7.5+ is still py2, only 8+ is already py3. As for why these classes have just surfaced, I think that simply none of the developers have used them before, a rather rare functionality.

 

[Madeddy]

It seems to me that you are confusing something, 7.5+ is still py2, only 8+ is already py3. ...

Oh dang it. You're right, i forgot.
But wait... this doesn't mean we cannot execute unrpyc in py3 and have it still working on Ren'py 7.5, or? As long as unrpyc supports Ren'py-internal py2 code...

About the @ dispatch elements in "sl2decomp": Are both needed for the function or is the one on the files bottom a test block? And whats with these additions to displayable_names=...Are they part of this?

 

[VepsrP]

Oh dang it. You're right, i forgot.
But wait... this doesn't mean we cannot execute unrpyc in py3 and have it still working on Ren'py 7.5, or? As long as unrpyc supports Ren'py-internal py2 code...

About the @ dispatch elements in "sl2decomp": Are both needed for the function or is the one on the files bottom a test block? And whats with these additions to displayable_names=...Are they part of this?

It will be difficult to say for sure, since I have already forgotten which games I wrote these parts of the code for, but in general they are in working order, and not the usual stubs (even the one that says pass is the correct processing option). As for displayable_names, this is also an attempt to support custom styles, especially those that start with the word store - this is generally masterpiece. The developer wrote his own library for processing custom style code, and I even had to create a new fake package for normal processing.
We can decompile the code of the second python on the third, which I do in an application with a graphical interface, but cmd still works with what it is, so I don't really understand where to get another python.

 

[Madeddy]

We can decompile the code of the second python on the third, which I do in an application with a graphical interface, but cmd still works with what it is

Hm. I don't know when the unrpyc chief dev finds time/desire to update the official repo. I got no reaction so far as i asked. Imho needs unrpyc way more overhaul beyond py3 and Ren'py-new changes. There is much old code in there. Censoredusername said himself so. I think there are also some lose ends and some stuff is cumbersome written.

However i think two variants for unrpyc would be best in future:

1. Current: For Ren'py 7.5/8 and to execute in py3. This has all the changes it needs for py3 and for the new functions etc. which mad us problems since summer.
2. Legacy: For Ren'py up to 7.4, but for which python version? This would be basically the current v.1.1.8, but this needs to be executed in py2. Changes not needed i think.

Unren (from whatever dev/user made) could then reflect this easily in his variants. The advantage is, the legacy version would need no support or just little.

 

[VepsrP]

Hm. I don't know when the unrpyc chief dev finds time/desire to update the official repo. I got no reaction so far as i asked. Imho needs unrpyc way more overhaul beyond py3 and Ren'py-new changes. There is much old code in there. Censoredusername said himself so. I think there are also some lose ends and some stuff is cumbersome written.

However i think two variants for unrpyc would be best in future:

1. Current: For Ren'py 7.5/8 and to execute in py3. This has all the changes it needs for py3 and for the new functions etc. which mad us problems since summer.
2. Legacy: For Ren'py up to 7.4, but for which python version? This would be basically the current v.1.1.8, but this needs to be executed in py2. Changes not needed i think.

Unren (from whatever dev/user made) could then reflect this easily in his variants. The advantage is, the legacy version would need no support or just little.

I prefer the idea of full integration with the engine, which I partially implemented in un.rpyc and fully implemented in the archive unpacker. This would simplify support and reduce the need to redesign the tool to maintain all the capabilities of both the engine itself and various modifications of game developers, but so far this is too difficult for me.

 

[VepsrP]

Hm. I don't know when the unrpyc chief dev finds time/desire to update the official repo. I got no reaction so far as i asked. Imho needs unrpyc way more overhaul beyond py3 and Ren'py-new changes. There is much old code in there. Censoredusername said himself so. I think there are also some lose ends and some stuff is cumbersome written.

However i think two variants for unrpyc would be best in future:

1. Current: For Ren'py 7.5/8 and to execute in py3. This has all the changes it needs for py3 and for the new functions etc. which mad us problems since summer.
2. Legacy: For Ren'py up to 7.4, but for which python version? This would be basically the current v.1.1.8, but this needs to be executed in py2. Changes not needed i think.

Unren (from whatever dev/user made) could then reflect this easily in his variants. The advantage is, the legacy version would need no support or just little.

In general, I figured out the byte classes and properties. It turned out rather clumsy and rude, but I haven't come up with anything better yet. Commit in the dev branch. For the release, still need to correct.