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

[mazinogamer]

 

[CurtimusPrime92]

on v6 pressing enter if in the proper game directory doesn't continue like it says it will, it immediately closes the cmd prompt window

Spoiler: screenshots

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

enter does nothing except immediately close window
.
..
...
..
.
TL/DR doesn't properly fallback to current directory of the file

 

[Dodzh]

Pardon my ignorance: so I copied both bat and ps1 files into a game folder I wanted to extract .rpa files, I ran first the bat then ps1 both worked only on options 3 to 6 and created scripts as it should but when I tried option 1 "1) Extract RPA packages" nothing happened

You must be registered to see the links

I'm I doing something wrong here?

thank you

 

[Madeddy]

@ mazinogamer: I dont know what version of Unren.bat - forall(v6) you are using or from where you got it, but thats not the one(exactly the same name and version) i downloaded from github. Your code is different: import _multiprocessing is there NOT in unrpyc.py and cannot work. Thats the original code which should be there:
Edit: Did interprete the shot wrong, but there is still something not right. The python which comes with renpy is a cut down version and has no multiprocessing module.

Spoiler

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

@

v6 didn't work ... neither with the tool in the folder (closes immediately) nor via drag'n'drop (claims to unpack the archives but actually doesn't), v5 works fine. ...immediately after pressing enter, via drag'n'drop I get this error: ImportError: No module named renpy.object. v5 working fine

...enter does nothing except immediately close window
TL/DR doesn't properly fallback to current directory of the file

Correct, its broken. What works is to to pull the game dir in the window and hit enter.

...I'm I doing something wrong here?...

No, you do nothing wrong. Its also a bug.

You guys should till its fixed(i've noticed he works already on it) go back to the previous version or whichever worked for you last. Or just wait.

 

[VepsrP]

New version. It should work now. I checked the current location and different versions of the engine. But special characters are now banned again for the cmd file. As always, I suggest testing experienced users first.

 

[VepsrP]

@ mazinogamer: I dont know what version of Unren.bat - forall(v6) you are using or from where you got it, but thats not the one(exactly the same name and version) i downloaded from github. Your code is different: import _multiprocessing is there NOT in unrpyc.py and cannot work. Thats the original code which should be there:

try:
    from multiprocessing import Lock, Pool, cpu_count
except ImportError:
    def cpu_count():
        return 1

    class Lock:
        def __enter__(self):
            pass

        def __exit__(self, type, value, traceback):
            pass

        def acquire(self, block=True, timeout=None):
            pass

        def release(self):
            pass

If you had looked more closely at the screenshot, you would have seen that a multiprocessing module appeared in python. However, most likely broken and cropped. I've only just noticed it myself.

 

[Madeddy]

If you had looked more closely at the screenshot, you would have seen that a multiprocessing module appeared in python. However, most likely broken and cropped. I've only just noticed it myself.

No, i looked closely enough and did see he bitches also about the orginal python part. However the trace cite's also the "...Lock()" from unrpyc and i thought the import comes also from there. My mistake.

This error should never happen with a normal unrpyc. "Something" was changed i think.

 

[VepsrP]

No, i looked closely enough and did see he bitches also about the orginal python part. However the trace cite's also the "...Lock()" from unrpyc and i thought the import comes also from there. My mistake.

This error should never happen with a normal unrpyc. "Something" was changed i think.

You can try to run the "Normal" unrpyc. I am sure that the problem will remain, because in the place of the error there is an attempt to import the library _multiprocessing.pyd, which is not in the stripped-down python. So it's still about the stripped-down python, not my code.

 

[Madeddy]

... attempt to import the library _multiprocessing.pyd, which is not in the stripped-down python. ...

I know.

... So it's still about the stripped-down python, not my code.

You misunderstood me. I did NOT mean its from your code. I guessed just someone else must changed something so the error appears.
I am aware, from our work on unrpyc, you know the code in unrpyc module well enough and the try/except importerror there handles the missing multiprocessing with the mock code. So the question was/is why does it print this error? I never seen it before.
-------------
I attached a changed version of your unren-dev(remove the .txt). Look what you think about it and if you want use the code or some of it . Or not.... no problemo. However I have still a weird bug in there: The exit with the "x" option does not work correctly. It goes back to the menu and exits only if you repeat it. No idea why.

Other users: DO NOT try to use the attached unren version. Its incomplete and not working!

 

[VepsrP]

I know.
You misunderstood me. I did NOT mean its from your code. I guessed just someone else must changed something so the error appears.
I am aware, from our work on unrpyc, you know the code in unrpyc module well enough and the try/except importerror there handles the missing multiprocessing with the mock code. So the question was/is why does it print this error? I never seen it before.
-------------
I attached a changed version of your unren-dev(remove the .txt). Look what you think about it and if you want use the code or some of it . Or not.... no problemo. However I have still a weird bug in there: The exit with the "x" option does not work correctly. It goes back to the menu and exits only if you repeat it. No idea why.

Other users: DO NOT try to use the attached unren version. Its incomplete and not working!

Yeah, sorry, i think, you were writing about me.
There are no errors when importing, because the import of _multiprocessing takes place directly in the function. In the context.py line 65 there is a Lock function, which consists import from synchronize.py another Lock function. It is at this moment that the file is processed synchronize.py, which tries to import _multiprocessing. In normal python, there is a library called _multiprocessing.pyd, written in C++. But there is no such library in this version, respectively, this module will not work. In general, either this is the preparation of the authors of the engine, which I doubt, or this is the work of the author of the game, who poorly understood the work of python.

 

[VepsrP]

I attached a changed version of your unren-dev(remove the .txt). Look what you think about it and if you want use the code or some of it . Or not.... no problemo. However I have still a weird bug in there: The exit with the "x" option does not work correctly. It goes back to the menu and exits only if you repeat it. No idea why.

x option don't work, because exit /b doesn't close app, but exits the module. Should be just exit 0.
Edit: An interesting approach to determining the architecture, but I would check only x86, since there is more than one 64-bit architecture (although most of them are so rare that they are unlikely to appear to an ordinary user), and 16-bit and older processors have generally sunk into oblivion and will not even work on WinXP. In addition, old engines without 64-bit folders will not work if user has a 64-bit processor (in your case, but I liked how you designed everything, it's a pity, it won't work out as beautifully if take into account all the possibilities).

 

[Shadowkeeper]

unren "forall(v7) (221231)" still instantly closes upon pressing enter/return...
(is there anything I could temporarily add to catch any errors, because I would think it would throw one of your built-in errors if it couldn't get a valid path...)

 

[VepsrP]

unren "forall(v7) (221231)" still instantly closes upon pressing enter/return...
(is there anything I could temporarily add to catch any errors, because I would think it would throw one of your built-in errors if it couldn't get a valid path...)

launch the console from the folder and run the script from there, then the console will remain open with an error.

 

[Madeddy]

... In general, either this is the preparation of the authors of the engine, which I doubt, or this is the work of the author of the game, who poorly understood the work of python.

Oh, you mean its from the game? Do i understand this correct? I did not test it with the game in question... so i cannot know.

x option don't work, because exit /b doesn't close app, but exits the module. ...

Yes, this is the intend. I wanted it to let the terminal open after the exit of the script. But like said, it goes strangely back to the menu after the first exit attempt. I don't understand why.

...An interesting approach to determining the architecture, but I would check only x86, since there is more than one 64-bit architecture...

I thought about its but i wanted to be able to add the else with the error message in case the "architecture var" fails somehow. Without the check for both the else is impossible.

...but I liked how you designed everything, it's a pity, it won't work out as beautifully if take into account all the possibilities

Like said, its no problem if you do not use the code. I played a bit around with it out of curiosity and for fun, to see if its possible to improve the recent problem cases and that's it.

p.s.: If you're interested, could you do a bit of testing on my diff2patch tool? ->

You must be registered to see the links

Just if you have spare time and feel like it. The apps development is basically done, but there a very likely bugs in it. I did for example for many weeks not get to test it in windows. The win colors support with ctypes and the other out-commented option is complete untested.

 

[VepsrP]

Oh, you mean its from the game? Do i understand this correct? I did not test it with the game in question... so i cannot know.

I'm telling you, in the folder with python modules in this particular game there is a multiprocessing module. Most likely, the author put it there for some reason. But he didn't know that it wasn't enough for this module to work.

 

[Shadowkeeper]

Enter the path to the game, drag'n'drop it or press enter immediately if this tool is already in the desired folder:
F\fs\to was unexpected at this time.
PS E:\Backup F\fs\to test\Lust Element>

It appears to me that spaces are the problem in this case...
Not the biggest problem in my case, I'll just cut the selection code out and keep the old method... ( set "currentdir=%~dp0%" )

 

[Scy7he]

even though the rpyc files are present, the program tells me there is none...is this because of () in my program files (x86)?
(Putting the program into the main folder and pressing enter also doesn't seem to work)

Extracting _decomp.cab...
Searching for rpyc files...
C:\Program Files (x86)\PTM\randomgames
   + Searching for rpyc files in
File not found:
No script files to decompile.

Cleaning up temporary files...

Edit: I placed my file in another place without (), still the same issue...the game in question is latest version of superheroes suck

Update: the powershell version worked!!! thank fuck for that

 

[Shadowkeeper]

C:\Program Files (x86)\

Part of the problem is likely how windows handles access to the "program files" folders (both with and without (x86) ).
They are protected folders and access attempts by anything not running in admin are rerouted to another folder outside the "safe zone".
It is recommended to not put anything in those folders unless it needs to be (like actual programs/apps and definitly nothing that has anything to do with gaming...)

 

[Scy7he]

Part of the problem is likely how windows handles access to the "program files" folders (both with and without (x86) ).
They are protected folders and access attempts by anything not running in admin are rerouted to another folder outside the "safe zone".
It is recommended to not put anything in those folders unless it needs to be (like actual programs/apps and definitly nothing that has anything to do with gaming...)

well weirdly the powershell version worked even on the (x86) folder...tho like you said, I have changed my folder to elsewhere now

 

[Shadowkeeper]

well weirdly the powershell version worked even on the (x86) folder...tho like you said, I have changed my folder to elsewhere now

All I can say there is *shrug* ...
Microsoft doesn't always follow it's own "safety" measures so who knows ...