AttributeError: 'RawBlock' object has no attribute 'statements' about unrpyc HOT 12 CLOSED

@zorbathut

* Could you look in which Ren'Py version the previous game versions run? I'm curious.

I'm afraid I don't actually have any older versions, nor do I see a way to get them off Itch.

* To decompile this app you need to run the unrpyc legacy (v1.3 with python2).

Aha, wild. Not going to worry about this for now then! Thanks for looking into it :)

from unrpyc.

Ok, this was a breeze. I got this already and can make later a pull req for it.

Basically "RawBlock" can be without attrs(fix this and more will come) and we need now to check against it. Like in many other places in the last years.
I have the feeling that's not last we've seen of this type of bug.

Edit: A little bit too fast... With the fix (dev_fix_ish197) it decompiles without error but the resulting .rpy is "strange". A lot of image statement blocks without content.
goth_wardrobe.zip

from unrpyc.

Basically "RawBlock" can be without attrs(fix this and more will come) and we need now to check against it. Like in many other places in the last years.

Huh, I wonder what causes that. renpy should unconditionally assign self.statements in RawBlock.__init__.

I have a feeling more is afoot there.

from unrpyc.

Try decompiling that single file with legacy ;)

from unrpyc.

Damn.
I had the thought to try this, so why didn't i? 😩 So my other thought could very well also fit: A legacy game put on v8 without forced recompile, huh?

@zorbathut

• Could you look in which Ren'Py version the previous game versions run? I'm curious.
• To decompile this app you need to run the unrpyc legacy (v1.3 with python2).

from unrpyc.

To decompile this app you need to run the unrpyc legacy (v1.3 with python2).

No, only to decompile that single file. The rest was compiled with 8.1, go figure why.

from unrpyc.

No, only to decompile that single file.

Strange. I decompiled and astdumped everything error free with v1.3.0. Tested the game even a few minutes(fast skip) and encountered no issues. Very curious.

The rest was compiled with 8.1, go figure why.

Ah no. I found a few more in there from different dates all the way back to 2022, but the most are as you said. 🤷🏻 More riddles...

from unrpyc.

Strange. I decompiled and astdumped everything error free with v1.3.0. Tested the game even a few minutes(fast skip) and encountered no issues. Very curious.

Seems for everything I ripped out of either, both legacy and master are still pretty decent at decompiling stuff from either py2 or py3 based renpy. Honestly pretty surprising.

from unrpyc.

Just FYI, I'm fine with this being either closed or kept open for discussion. If possible, though, I'd request some check to ensure you're using the right version - I'm certain I won't be the last person to report something that ends up being "wrong renpy version", and a more descriptive error message would go a long way to stop that.

This assumes there's a good way for code to tell which version the .rpyc is, though.

. . . although, given the discussion here, maybe with an optional flag to try anyway. Or do the check only on error.

from unrpyc.

I'm currently of the opinion that doing both is a good idea. I've added some detection, but the format makes it hard to detect all. That said, if we can't detect it, we might just be able to decompile it decently. The detection just prints a warning, and I'll add back a few pre ren'py 8 features (basically just ubiquitous parameter / argument handling). That will likely be enough to support basically every ren'py 7 game as well. Not sure how much more it'd be able to decently handle. 6.17 is the first I know it definitely won't as that requires old-style screenlang handling. Rest is some much more minor backwards compatibility hazards.

from unrpyc.

See #199

from unrpyc.

This has all been implemented.

from unrpyc.