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

[Alpine Eagle]

thanks for the answer

If you just need to translate the game, you don't need to pack the files back into rpa, you can put them in the Game folder in the unpacked form and perform the translation. To change the language in the game you will have to add a few lines of code in screens.rpy
You can also unpack image archives if you translate them. They can also not unpacked.

 

[chris300]

i can't get this to work on seeds-of-chaos-0.2.52-pc. am i just a retard or do i need something else?

 

[goobdoob]

i can't get this to work on seeds-of-chaos-0.2.52-pc. am i just a retard or do i need something else?

Well, I won't comment on your question, but if you want support, you should:

1. Say exactly what you're doing
2. Say exactly what you expect
3. Say exactly what's happening, including error messages

 

[jimmydatoolip]

Enabling Console/Dev mode in Witch Hunter Trainer vOctober causes crash upon startup. I recall the same issue from other games but unfortunately didn't keep track of which - I'll try to be more proactive but it's not an insulated incident per se.

1. Download and Unarchive game to ASCII named folder (e.g. C:/Games/WHT_vOctober). Copy Unren.bat to that folder. Option 3, Enter, Enter. 'game' folder does indeed have 'unren-dev.rpy' and after running the executable 'unren-dev.rpyc'.
2. I expect the splash screen then the game menu, not an error screen. To be clear, with unren-dev I don't receive the splash screen.
3. The game starts, immediately as a window opens it's filled with errors. Main error is "Parsing the script failed." followed by dozens of seemingly unrelated 'the label xyz is defined twice at fileA lineA and fileAorB lineC' (see attachment).

Deleting the unren-dev files in the game folder fixes everything. Enabling console in the 'renpy/common/00console.rpy' file does not break the game.

 

[goobdoob]

Enabling Console/Dev mode in Witch Hunter Trainer vOctober causes crash upon startup. I recall the same issue from other games but unfortunately didn't keep track of which - I'll try to be more proactive but it's not an insulated incident per se.

1. Download and Unarchive game to ASCII named folder (e.g. C:/Games/WHT_vOctober). Copy Unren.bat to that folder. Option 3, Enter, Enter. 'game' folder does indeed have 'unren-dev.rpy' and after running the executable 'unren-dev.rpyc'.
2. I expect the splash screen then the game menu, not an error screen. To be clear, with unren-dev I don't receive the splash screen.
3. The game starts, immediately as a window opens it's filled with errors. Main error is "Parsing the script failed." followed by dozens of seemingly unrelated 'the label xyz is defined twice at fileA lineA and fileAorB lineC' (see attachment).

Deleting the unren-dev files in the game folder fixes everything. Enabling console in the 'renpy/common/00console.rpy' file does not break the game.

I've seen other games do this - the Mac version of Milfy City, for example.

Edit unren-dev.rpy and remove the config.developer line.

 

[anne O'nymous]

I've seen other games do this - the Mac version of Milfy City, for example.

Edit unren-dev.rpy and remove the config.developer line.

I seriously never understood how this can happen. The developer mode is enabled in the SDK, and the distribution can't be built if the game can't be launched.

Does this imply that those devs used the SDK only once, and after see use the distribution file to continue the development of their game ? :/
And I don't even talk of the fact that they have duplicated labels.

 

[goobdoob]

I seriously never understood how this can happen. The developer mode is enabled in the SDK, and the distribution can't be built if the game can't be launched.

Does this imply that those devs used the SDK only once, and after see use the distribution file to continue the development of their game ? :/
And I don't even talk of the fact that they have duplicated labels.

I don't know. When I turn on developer mode in the Mac version Milfy City 0.6e I get this:

Spoiler

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

The label map_label is defined twice, at
File "game_gui.rpyc", line 89 and
File "game/game_gui.rpy", line 89.

I've got another copy of 0.6d with the rpas unpacked. There are both game_gui.rpyc and game_gui.rpy; game_gui.rpy is not decompiled with unrpyc (no comment at the end saying it is). I run unrpyc on game_gui.rpyc, then compare it to game_gui.rpy, and the only differences are whitespace and comments.

I have no idea why this is happening.

 

[anne O'nymous]

The label map_label is defined twice, at
File "game_gui.rpyc", line 89 and
File "game/game_gui.rpy", line 89.

Launch the game again, and you'll have a surprise

It's due to the "compilation" process of Ren'py. It compared the files in the rpa and directly on the disk, but didn't understood that the "game_gui.rpyc" in the rpa was the same than the "game_gui.rpy" directly on the folder. Therefore it complained about the duplicated labels.
But once you'll have up to date rpyc files directly on the folder, it will understand that it have to use the newest of them, and so there isn't conflict anymore.


But for jimmydatoolip it's something else :

The label sloose is defined twice, at
  File "game/fight.rpy", line 250 and
  File "game/fightdub.rpy", line 238.

The label story6f is defined twice, at
  File "game/huntstory.rpy", line 1050 and
  File "game/huntstory.rpy", line 1259.

At the exception of the first label, that is duplicated in another file, all the labels are defined twice in the same file... It's clearly a problem due to the dev ; and generally not a good news for the future of the game.

 

[goobdoob]

Launch the game again, and you'll have a surprise

It's due to the "compilation" process of Ren'py. It compared the files in the rpa and directly on the disk, but didn't understood that the "game_gui.rpyc" in the rpa was the same than the "game_gui.rpy" directly on the folder. Therefore it complained about the duplicated labels.
But once you'll have up to date rpyc files directly on the folder, it will understand that it have to use the newest of them, and so there isn't conflict anymore.


But for jimmydatoolip it's something else :
[/code]
The label sloose is defined twice, at
File "game/fight.rpy", line 250 and
File "game/fightdub.rpy", line 238.

The label story6f is defined twice, at
File "game/huntstory.rpy", line 1050 and
File "game/huntstory.rpy", line 1259.
[/code]

At the exception of the first label, that is duplicated in another file, all the labels are defined twice in the same file... It's clearly a problem due to the dev ; and generally not a good news for the future of the game.

It's supposed to rebuild the rpycs before it loads anything; it should never have a (newer) rpy that doesn't match the rpyc.

Plus, I'm seeing this with the game running from rpas, without unpacking them. I run it twice and I see the same issue. The only solution is to turn off dev mode.

 

[anne O'nymous]

It's supposed to rebuild the rpycs before it loads anything; it should never have a (newer) rpy that doesn't match the rpyc.

You forgot the key point, the RPYC file is inside a RPA archive. Therefore, it's absolutely possible to have a RPY newer that the already loaded associated RPYC file.
When loading the scripts from the RPA files, Ren'py take count of the fact that the game can have been patched in a way or another. So, it search if a copy of the RPYC file exist somewhere else (other RPA, or directly on the disk). But it don't look if there's a RPY file than haven't been proceeded yet.
In consequence, if the "game" directory have :

• script.rpa
  • script.rpy
  • script.rpyc
• script.rpy

Ren'py will load the RPYC located inside the RPA, then proceed the RPY file that is directly on the disk. Which lead to conflict between the labels and make Ren'py stop.

But if you have :

• script.rpa
  • script.rpy
  • script.rpyc
• script.rpy
• script.rpyc

It will just use the newest RPYC file.

Plus, I'm seeing this with the game running from rpas, without unpacking them. I run it twice and I see the same issue. The only solution is to turn off dev mode.

Because they are two different issues. The one you have with Mifly City is due to the extracted rpy files. It's shown by the traceback :

The label map_label is defined twice, at
File "game_gui.rpyc", line 89 and
File "game/game_gui.rpy", line 89.

The couple path+name is different only because the RPA files get ride of the leading "game/" in the path. But it's the same file and the label declaration happen at the same line.
It's the issue I explained above. Launch Ren'py again and, now that there's a RPYC file directly on the disk, it will works fine, even with the developer mode enabled.


While the problem encountered with Which Hunter Trainer is different :

The label sloose is defined twice, at
File "game/fight.rpy", line 250 and
File "game/fightdub.rpy", line 238.

Here, the files are clearly different.

The label story6f is defined twice, at
File "game/huntstory.rpy", line 1050 and
File "game/huntstory.rpy", line 1259.

While here it's the lines that are different.
And effectively, in this case you can't run Ren'py if the developed mode is enabled, unless you explicitly said to Ren'py that he have to ignore duplicated labels.

 

[the66]

i might be wrong but as far as i understand Ren'Py's code:
1. local rpyc files always preceeds stored ones in a rpa archive.
2. the decision either to use an existing local rpyc file or to update it, is only based on the comparison of 2 secure hashes (via Python's hashlib), a new one created of the rpy file and the one stored in the rpyc file. if both differs, the rpyc file is updated from the existing rpy file. if both hashes are the same, the existing rpyc file is used. there is never a check if one file is newer than another.

 

[anne O'nymous]

1. local rpyc files always preceeds stored ones in a rpa archive.

Yes, local RPYC, and yes also for the fact that there no comparison, my memory failed me.

But it change nothing to the problem, which happen because of loader.py:scandirfiles() ; more precisely because of its interal add() :

    def add(dn, fn):
        if fn in seen:
            return
[...]
        files.append((dn, fn))
        seen.add(fn)
        loadable_cache[fn.lower()] = True

At this time, fn still have the extension, therefore, seen will content both "script.rpy" and "script.rpyc". But what happen when "script.rpyc" do not exist because unrpyc just did its magic ?
It's simple, when Ren'py have finished to build the list of the files in the disk, "script.rpyc" will be missing in seen. Therefore, when Ren'py will add the list of files in the RPA, it will exclude "script.rpy" if it's stored, but include the "script.rpyc".
In the end of the process, when script.py:Script.load_script() will load the scripts, it will be given a list that contain both ( "script", "[path to game]/game" ), and ( "script", None ), and proceed both files. Which will lead to the label conflict.

But when you'll run Ren'py the second time, the RPYC file will now be present on the disk, and this time seen will works correctly and exclude the file in the RPA.

 

[the66]

this problem only occurs if you have a local rpy file and an archived rpyc file. but this shouldn't normally happen. if the game is packaged as rpa, there is simply no need for local files at all. the only scenario with rpy + rpa files is extracting the rpa and deleting the extracted rpyc files or extracting only the rpy files. but i don't see this as problem of Unren or Ren'Py.
and the problem with the duplicate labels in WHT was always there. either just enable only the console and not the dev mode or fix the labels.

 

[goobdoob]

Because they are two different issues. The one you have with Mifly City is due to the extracted rpy files. It's shown by the traceback :

The label map_label is defined twice, at
File "game_gui.rpyc", line 89 and
File "game/game_gui.rpy", line 89.

The couple path+name is different only because the RPA files get ride of the leading "game/" in the path. But it's the same file and the label declaration happen at the same line.
It's the issue I explained above. Launch Ren'py again and, now that there's a RPYC file directly on the disk, it will works fine, even with the developer mode enabled.

That's really odd. I didn't unpack the rpas. There should be no local rpys, but there are. Running it twice doesn't create local rpycs.

The local rpys must be different versions than the ones in the rpycs in the rpas, either that or RenPy doesn't do a good job determining that they're the same.

 

[jimmydatoolip]

So long story short, in Witch Hunter Trainer vOctober, the code was written (.rpy) and assets supplied, the code was compiled (.rpyc) and the compiled code and assets were archived (.rpa). All of that together was then released. Somehow or another - didn't entirely follow that part in detail, sorry - dev mode off this all works fine (uses .rpa only and/or newest only) but with dev mode on RenPy gets confused (again, somehow).

TLDR; Not something UnRen can realistically be asked to do anything about. Try deleting either .rpa or 'everything' else if you decide dev mode is worth the effort.

Not a huge issue but avoiding excessive grinding is often quite easy with dev mode's Variable Viewer - if it's not stored in classes. The console and/or its log slows down and even causes instability when it gets long (e.g. with multiple long dir() results) which I subsequently try to avoid. Tracking down variables in code is a lottery where sometimes you're led down a rabbit hole. Plus I suppose it can lead to spoilers, more-so than variable names anyway.

Thanks all for your effort, much appreciated.

 

[anne O'nymous]

That's really odd. I didn't unpack the rpas. There should be no local rpys, but there are.

It happen sometimes. Some uploaders pack back the version they tested and you have a... How to define them ? They aren't corrupted version, nor weird, just not the distribution as intended by the dev. In some you have the unren console enabling file, in others you have the RPY, and things like that. It never changed something to the game, except that the "game" directory don't look like it was when the author published the release.
It can be the reason why you had the local RPY, like it can be for another reason, I can't say.

Running it twice doesn't create local rpycs.

But this is totally not normal. Unless there's a bug in this particular version of Ren'py, the RPYC should be created. The only thing that can prevent this, is if there's an error preventing the "compilation" of the first RPY file. But the duplicated labels are more warnings than errors, you got the error once Ren'py is ready to go.

 

[goobdoob]

It happen sometimes. Some uploaders pack back the version they tested and you have a... How to define them ? They aren't corrupted version, nor weird, just not the distribution as intended by the dev. In some you have the unren console enabling file, in others you have the RPY, and things like that. It never changed something to the game, except that the "game" directory don't look like it was when the author published the release.
It can be the reason why you had the local RPY, like it can be for another reason, I can't say.




But this is totally not normal. Unless there's a bug in this particular version of Ren'py, the RPYC should be created. The only thing that can prevent this, is if there's an error preventing the "compilation" of the first RPY file. But the duplicated labels are more warnings than errors, you got the error once Ren'py is ready to go.

Unless someone unzipped the Mac app, unpacked just the script rpa, decompiled the rpycs, then deleted the rpycs, I think this is the original distro by the dev. Very odd.

 

[anne O'nymous]

Unless someone unzipped the Mac app, unpacked just the script rpa, decompiled the rpycs, then deleted the rpycs, I think this is the original distro by the dev. Very odd.

More than odd, it's totally weird. I never really looked at Ren'py's code for the distribution building process, but as far as I understood it, only the files not proceeded as part of a RPA are copied into the distribution archive. Therefore, the RPY file have really no reason to be here :/

 

[SWAJ]

Interesting tool. Thanks for sharing!

 

[MSNlover95]

unren it does not enable it the rollback in it the game deliverance