Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhanced compatibility #199

Merged
merged 4 commits into from
Mar 11, 2024
Merged

Enhanced compatibility #199

merged 4 commits into from
Mar 11, 2024

Conversation

CensoredUsername
Copy link
Owner

This adds a bunch of ren'py 7 compatibility back into the main branches. This is mainly meant for games running ren'py 8 but still having older files, and as such we don't have to worry that badly about emitting things that older ren'py's don't quite grok. These changes are surprisingly small and net us compatibility back to at least 6.18 (2014), where the main blocker is old-style screen language. Supporting that is a big burden that I'm not interested in, so around that point sounds like a good cutoff. I also made it generate an error when encountering those that tells people they're using the wrong decompiler version.

Legacy still has its place as it has all the shenanigans needed for --init-offset version checks, --tag-outside-block and friends, old-style screens support, and true compatibility down to 6, but at least this way un.rpyc and the normal tools won't completely balk upon encountering a single file from ren'py 7.

Posting this as a pull request first to maybe get some feedback, but as the changeset is quite small (118+/21-) I feel like it's worth the lower amount of future issue posts to do this.

@CensoredUsername
Copy link
Owner Author

Thought about it a bit more, and I'm going to merge this tomorrow. Seems I originally overestimated how much backwards compatibility cruft was necessary when I decided on a hard split for python 3 / ren'py 8. Time to get everything in shape again, and edit the README.

@madeddy
Copy link
Contributor

madeddy commented Mar 10, 2024

Seems I originally overestimated how much backwards compatibility cruft was necessary

Me also. If this where much code and work i would vouch against it, but so i see no reason. I'm not sure if this shouldn't sit here a few more weeks, to see if you got everything (code) that's needed for the task. 🤷🏻

In the end, whatever i may think, it's anyway your call as maintainer.

Importantly, seeing new issues the readme gives me the vibe it isn't as clear a it should be.

@CensoredUsername
Copy link
Owner Author

I'm not sure if this shouldn't sit here a few more weeks, to see if you got everything (code) that's needed for the task. 🤷🏻

If those appear we can just add them as well. No reason to let this sit and then have to deal with rebasing everything over it.

@CensoredUsername CensoredUsername merged commit 85090ef into dev Mar 11, 2024
1 check passed
@CensoredUsername CensoredUsername deleted the enhanced-compatibility branch March 11, 2024 00:55
@CensoredUsername CensoredUsername restored the enhanced-compatibility branch March 11, 2024 01:00
@CensoredUsername CensoredUsername deleted the enhanced-compatibility branch March 11, 2024 01:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants