unrpyc

unrpyc copied to clipboard

Currently, we always put "as" and "tag" as the first two lines inside of "screen", even if line numbers imply this isn't where they went. Also, when we're sure we're decompiling older versions of Ren'Py, we should still put "tag" on the same line as "screen".

First part fixed in 4e4576f and second part fixed in 2774946. The first part was fairly invasive, so I'll leave everything in dev for now and close this once it gets merged to master.

I'm not really sure about the second one. It being a command line option is fine, but having it be auto detected is a problem as it breaks forward compatability, and it is possible that the relevant .rpyc files are being ran with an engine version higher than they were originally compiled by.

It's a REALLY wide version gap though. I've seen a few games with minor version differences, but never a game that shipped pre-6.99 files with a 7.3+ engine.

While it's rarely used in practice, upgrading the engine of an already released game is still something that ren'py tries to support. I'm less concerned about line-number accuracy (it's nice for tests and to look at but minor offsets aren't a problem) than I'm about getting random issue reports about decompiled games giving errors. It should be an opt-in choice.

Unrelatedly though, long time no see, nice to see you active again ;)

upgrading the engine of an already released game is still something that ren'py tries to support

They do? Isn't the response at renpy/renpy#1860 itself evidence that they don't?

I'm less concerned about line-number accuracy (it's nice for tests and to look at but minor offsets aren't a problem) than I'm about getting random issue reports about decompiled games giving errors. It should be an opt-in choice.

Fair enough; changed in e42f460.

Unrelatedly though, long time no see, nice to see you active again ;)

It's nice to be back! :)

They do? Isn't the response at renpy/renpy#1860 itself evidence that they don't?

That's a problem with upgrading the engine as developer with *.rpy files present. Upgrading when *.rpyc files are present wouldn't cause that as it's an error in the stage of compiling *.rpy to *.rpyc.

I'm in favour of these kinds of workarounds when the new syntax breaks the .rpy in the old engine but if there's a syntax that works in both I'd say stick to that.

It's nice to be back! :)

Glad to have you!

Closing this as it was fixed 3 years ago I think.