yup. did that.I should clarify that my version only works from the folder where the .exe file of the launcher is located.
Well, the only logical explanation that remains is that the game is not RenPy. Can you drop a photo of the folder with game?yup. did that.
where the heart is-same game i tried before.Well, the only logical explanation that remains is that the game is not RenPy. Can you drop a photo of the folder with game?
it should work... only reason i knew about this program.Well, the only logical explanation that remains is that the game is not RenPy. Can you drop a photo of the folder with game?
Well, I put it on download, I'll test it in the evening. In theory, yes, it absolutely should, but perhaps there is some kind of pitfall.it should work... only reason i knew about this program.
should i try it it in ''game'' folder?Well, I put it on download, I'll test it in the evening. In theory, yes, it absolutely should, but perhaps there is some kind of pitfall.
The version that I released - no. It never works in this folder at all. Since I adhere to the doctrine - executables should be where executables are.should i try it it in ''game'' folder?
then, it's not on my end.The version that I released - no. It never works in this folder at all. Since I adhere to the doctrine - executables should be where executables are.
If you are able to use python v2.7 in your sys you can also try the "pure python rewrite of UnRen".(though still in alpha) https://f95zone.to/threads/unren-ba...sole-developer-menu-enabler.3083/post-5531034still doesn't work...
then, it's not on my end
unren__v0.17.0_py27.py C:/path/to/your/games/root/directory
Oh, until I caught you here. Deobfuscation on the python3 for those unfortunate scripts does not work. As I understood, everything should have been passed through the zlib of the extractor, but for some reason the array "star_string" or something like that is not filled in on Python3. Maybe at least you will get an idea what is wrong there.If you are able to use python v2.7 in your sys you can also try the "pure python rewrite of UnRen".(though still in alpha) https://f95zone.to/threads/unren-ba...sole-developer-menu-enabler.3083/post-5531034
Just execute from a terminal with your games path as arg e.gunren__v0.17.0_py27.py C:/path/to/your/games/root/directory
I believe i don't understand. Huh?Deobfuscation on the python3 for those unfortunate scripts does not work. As I understood, everything should have been passed through the zlib of the extractor, but for some reason the array "star_string" or something like that is not filled in on Python3.
Nah, that's not what I mean. I'm talking about that archive with scripts that you threw me earlier. On the built-in python in RenPy, I also forced both to unpack and decompile. But when trying to do the same experiment on python3, the decompilation stops working. I know for sure that in the console UnRen, decompilation works through the zlib pattern of the extractor function in deobfuscation (or as this stuff with @"name of function" is called), and in python3 in this function, arrays are not filled in, where they should be.I believe i don't understand. Huh?
Is this about your discussion with Ghostface Reborn and my link or some other problem? I case of the first, it has nothing to do with python3. I linked the python27 version of the pure py UnRen.
If some other problem then please explain again. I am probably slow today or something.
Surprisingly, everything works perfectly. Even the decompilation works, I couldn't check the decompression due to the lack of archives, which is surprising. I came up with another idea. Are you running it as an administrator, by any chance?it should work... only reason i knew about this program.
Forget I asked you earlier, I've already solved that problem. Here's a new one. In the picture "Decompilate difference" on the left is information when using python3, on the right is python2 from RenPy. As you can see, it seems like an error comes out when decompiling some files. But the trick is that this file and others with the same message were quietly decompiled (physically, the files with the code already exist). Probably, somewhere there is a logical problem in the code shown in the picture "Code with error", since this error is raised from there. But the logic of this function was beyond my control. Also in the archive is the same deobfuscation file, already with all the found fixes for python3. Perhaps you will be able to solve this puzzle.I believe i don't understand. Huh?
Is this about your discussion with Ghostface Reborn and my link or some other problem? I case of the first, it has nothing to do with python3. I linked the python27 version of the pure py UnRen.
If some other problem then please explain again. I am probably slow today or something.
No.Surprisingly, everything works perfectly. Even the decompilation works, I couldn't check the decompression due to the lack of archives, which is surprising. I came up with another idea. Are you running it as an administrator, by any chance?
... On the built-in python in RenPy...
...and in python3 in this function, arrays are not filled in, where they should be.
Just to understand this few statements before i look at anything:...on the left is information when using python3, on the right is python2 from RenPy...
if data[:10] not in [b'RENPY RPYC', b'MY_HEADER', b'RENPY RPC2']:
This does also.if data[i] != b'\x78':
The ord()
has IMHO no business in there, but in line 173 you remove them... Why?Just the same, the neutered python2 in RenPy works out everything as it should. That's why I've already released a new version of UnRen (console). But when I tried to add functionality to the version for python3, first(as it turned out) there were errors in working with byte data, and now this (the last problem).Just to understand this few statements before i look at anything:
1) Are you running Unren or whatever in RenPys shitty half-python? The castrated python? The one with missing modules i warned to use?
2) Are you trying to run python3 code in RenPy with python2?
I feel like we talk about different stuff here..
1. Well, data immediately gives a number(23, 46, 145, and the like), and not in the form of b'/x78'. In fact, I just brought a byte string to the corresponding number via the ord function, and if you take data from bytearray via data, then you immediately get a number. And now the start_positions variable has started to be filled with the necessary data. And yes, ord is needed there, otherwise it will not decompile.Line 75 is cumbersome:
if data[:10] not in [b'RENPY RPYC', b'MY_HEADER', b'RENPY RPC2']:
This does also.
Line 170:
if data[i] != b'\x78':
Theord()
has IMHO no business in there, but in line 173 you remove them... Why?
except Exception:
pass
A reason why i dont like the renpy python. I think it jumpos over certain things to work at all and we do not know whats modified in there. A permanent unknown with lot of headaches. Thats why i say use normal py to people.... the shitty half-python (as you put it) does not raise any errors. ...
Ah. This must a diff to py2 behavior i guess. "data" must give a different type in original.1. Well, data immediately gives a number(23, 46, 145, and the like), and not in the form of b'/x78'....
Yeah. "CensoredUsername" did in a talk with me once put it like this: magic.py is named like this for a reason.In line 328
...The original problem is in the magic module, but to climb into it is like suicide, too high a level of abstraction for me.Code:except Exception: pass