CensoredUsername / unrpyc

A ren'py script decompiler
Other
837 stars 149 forks source link

RenPy's new "use expression" feature not working with unrpyc decompiled scripts #86

Closed madeddy closed 4 years ago

madeddy commented 4 years ago

More bugs with the current dev-branch. It gets stranger with every try: Renpy errors.txt:

I'm sorry, but errors were detected in your script. Please correct the
errors listed below, and try again.

File "game/scripts/core/user_interface/computer/app/email.rpy", line 31: expected 'word' not found.
    use 'pc_app_email_' + app.tmp.open
        ^

File "game/scripts/core/user_interface/computer/desktop.rpy", line 18: end of line expected.
    use app.screen(app)
           ^

File "game/scripts/core/user_interface/popup/proxy.rpy", line 24: end of line expected.
    use spec[0](*spec[1:])
            ^

Ren'Py Version: Ren'Py 7.3.5.606
Wed Feb  5 18:31:02 2020

The whole set of original *.rpyc: rpyc_scripts.zip

CensoredUsername commented 4 years ago

Looks like it's using the new "use expression" feature of ren'py, should be an easy fix.

CensoredUsername commented 4 years ago

Should be fixed on the dev branch as well.

madeddy commented 4 years ago

No. I get again a bug if i run the game with the decompiled scripts. Looks like the wrong code formating somehow sneaked in there. Line 24 (use expression spec[0]...) is the problem from the look. (see also traceback)

init python in popup:
    '''
    Machinery to proxy popups in a way such that if an erroneous popup
    is triggered it unobtrusively yields debug information rather than
    crashing the game. This is important while in active development.
    '''

    def _proxy(name, *args, **kwargs):
        try:
            return globals()[name](*args, **kwargs)
        except:
            return missing()

screen popup_proxy(name, *args, **kwargs):
    tag popup
    modal renpy.get_mode() == 'screen'
    sensitive renpy.get_mode() == 'screen'
    zorder 100

    add kwargs.pop('background', None)

    default spec = popup._proxy(name, *args, **kwargs)
    use expression spec[0](*spec[1:])

label popup(name, *args, **kwargs):
    with None
    show screen popup_proxy(name, *args, **kwargs)
    with dissolve
    pause
    hide screen popup
    with dissolve
    return
# Decompiled by unrpyc: https://github.com/CensoredUsername/unrpyc

traceback.txt

This bug is also a duplicate of #87

CensoredUsername commented 4 years ago

Ah I see, it is supposed to be parsed as spec[0] holding the name, and (*spec[1:]) being the argument list for it.

CensoredUsername commented 4 years ago

Should be fixed now as well.

madeddy commented 4 years ago

Super! Yeah, thats a strange construct there in RenPy. Needing 'pass' as sep...

I test this now and get then back. Hopefully thats all then with the changes from RenPy which breaked all this.

madeddy commented 4 years ago

There are no easily recognizable exceptions anymore like before, but the test game is not playable anymore for me.

Somehow the decompiling breaks now the game state. Ingame options like map or menu choices not reachable or available anymore. Some game decisions are forgotten now or not triggered at all. I "think" the game variables could be affected by this. Its true for a new started game and also if one uses savegames.

CensoredUsername commented 4 years ago

Yeah, thats a strange construct there in RenPy. Needing 'pass' as sep...

It's required to resolve the syntactical ambiguity of the screen name being a python expression as well as the args list being a parenthesis-delimited list of expressions. It has to be there due to the lack of properly delimited python expressions in renpyscript syntax.

Somehow the decompiling breaks now the game state. Ingame options like map or menu choices not reachable or available anymore. Some game decisions are forgotten now or not triggered at all. I "think" the game variables could be affected by this. Its true for a new started game and also if one uses savegames.

That sounds weird, but I need more information to start from. If you can figure out a location where it breaks I can look at it in a new issue, but for now I'm closing this one as the specific problems here have been fixed.