Ren'Py Tricky problem with loading a save from a previous version

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
Hello, I have a small problem, but I can't for the life of me find the cause.


A couple of players have problems loading saves from previous versions of my VN.

When they do, they end up with a "Exception: Couldn't find a place to stop rolling back. Perhaps the script changed in an incompatible way?" (See traceback attached)

The thing is, only a couple of players had that problem, for the vast majority everything is working perfectly. That's why It's difficult to pinpoint the root cause of the problem. Well, that and the fact that I am a shit coder.

One thing to point out: if I try to load their saves with the version it was made in, it still crashes! I mean, it should work, right? It's a prefect copy of the game it was made in!

I have found a few possible causes:

1/ I deleted a rpyc file. and forgot about it But then, the save should load into the previous versions

2/ I added music between the versions, which changed the script. But it works for other players and even with changing the script so the line where the save was made is the same number, it still crashes. And again, it should load when using the previous version.

3/ Changing labels: I didn't touch that. I did add a new jump, but the labels themselves were not modified.

4/ The way I finish my chapters. I do that:

Code:
    scene black with fade
    "And that's all for this update folks!"
    "If you like the VN, and can afford it, please consider supporting me via my {a=https://www.patreon.com/user?u=81514889}Patreon{/a}."
    scene credit with dissolve
    pause
    scene black with fade
    centered "Please save here."
    return
Then, for the next update, I change it to:

Code:
    scene black with fade

    jump day16_2

From what I understand, I should put the "Please save here" into it's own label.

But again, why wouldn't a save load when using the same version it was made in? Perhaps the combination of that, and the little change of the script due to adding music? Could I fix it?

I am stumped, and would appreciate greatly any help you could provide, thanks.
 

GetOutOfMyLab

Conversation Conqueror
Modder
Aug 13, 2021
6,054
16,212
Well, you shouldn't delete rpyc files from your development folder. They contain important information about the changes made. It's good that you didn't change/delete labels and added a jump instead, however.

I don't usually put the "please save here" stuff into it's own label. I typically have it in the last label for that version, then remove the stuff about saving and add a jump to the next relevant label. I've released several version with no issues doing it that way.
 
  • Like
Reactions: Vanderer

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
Well, you shouldn't delete rpyc files from your development folder. They contain important information about the changes made. It's good that you didn't change/delete labels and added a jump instead, however.
I don't think I did it, I just listed it as a possible cause for the problem.


I don't usually put the "please save here" stuff into it's own label. I typically have it in the last label for that version, then remove the stuff about saving and add a jump to the next relevant label. I've released several version with no issues doing it that way.
I do the same thing, and generally, it works fine too. It's just something I read in a post.


But like I said, recently a couple of players had the issue, and it bothers me. I'd rather do things correctly and avoid the issue, even if it's only for a few players.

Anyways, thanks for your post, I appreciate it!
 
Last edited:

GetOutOfMyLab

Conversation Conqueror
Modder
Aug 13, 2021
6,054
16,212
I don't think I did it, I just listed it as a possible cause for the problem.




I do the same thing, and generally, it works fine too. It's just something I read in a post from, I think, Anne O Nymous, and the guy know his shit.


But like I said, recently a couple of players had the issue, and it bothers me. I'd rather do things correctly and avoid the issue, even if it's only for a few players.

Anyways, thanks for your post, I appreciate it!
Did they indicate which version of your game they last played?
 
  • Like
Reactions: Vanderer

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
Did they indicate which version of your game they last played?
Yes. And the image from the save is one of the last renders of my previous update, so I know they are not mistaken.

One of the player did indicate that they used the compressed version, but those versions didn't touch the script files, and I downloaded the compressed version and tried to load the save, and got the same error.

That's why I don't understand! How can a save made in a version can bug when loaded with the exact same files? The code is the same?
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,302
15,172
When they do, they end up with a "Exception: Couldn't find a place to stop rolling back. Perhaps the script changed in an incompatible way?" (See traceback attached)
[To summarize, and few changes can have happened with the 7.5.x/8.x branches]
When Ren'Py load a file save, the first thing it try is to find back the line where the save had been made. According to the code you gave, he will not find it, since it disappear.
Then it look at the label where this line is located. If it find it, it will load at the starts of this label.
If it still don't works, Ren'Py will look at the rollback stack, trying to find in it a line that still exist. Right now I'm not really sure if during this part it also take count of the labels or not.

So, in short, you made too much changes in the last label, what changed your code in an incompatible way, what then prevent Ren'Py to load the game.
And if it happen only to few players, it's because those few players are saving before the point where you effectively tell them to save. It's something relatively frequent, that I tend to do myself, because it happen way too often that a dev simply delete the "save here" label or, worse but hopefully exceptional, reuse the same for all update, making you load at the end of the new update instead of its starts.
 

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
[To summarize, and few changes can have happened with the 7.5.x/8.x branches]
When Ren'Py load a file save, the first thing it try is to find back the line where the save had been made. According to the code you gave, he will not find it, since it disappear.
Then it look at the label where this line is located. If it find it, it will load at the starts of this label.
If it still don't works, Ren'Py will look at the rollback stack, trying to find in it a line that still exist. Right now I'm not really sure if during this part it also take count of the labels or not.

So, in short, you made too much changes in the last label, what changed your code in an incompatible way, what then prevent Ren'Py to load the game.
And if it happen only to few players, it's because those few players are saving before the point where you effectively tell them to save. It's something relatively frequent, that I tend to do myself, because it happen way too often that a dev simply delete the "save here" label or, worse but hopefully exceptional, reuse the same for all update, making you load at the end of the new update instead of its starts.
Yeah, that's what I think too.

So, putting an "end of chaper" label before the "save here" message will avoid this sort of problems, right? Since the game will not have to rollback so far back.


That doesnt explain something though: why the save doesn't load even with the old version of the VN that has the same script that the save was made in.

That's what stump me.
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,302
15,172
So, putting an "end of chaper" label before the "save here" message will avoid this sort of problems, right? Since the game will not have to rollback so far back.
It should significantly limit it, yes.

But strictly speaking there's no way to totally prevent it to happen. Even well handled and developed games have this issue time to time. The best you can do is remind your players to save often.
Generally I use the save page first row for the "final save", always keeping one from one update before (that I update if needed), and the second row for the "in between" save. It's really rare that none of those saves works. It's annoying of course, since I have to replay already seen content, but less annoying that to have to replay the whole game.


That doesnt explain something though: why the save doesn't load even with the old version of the VN that has the same script that the save was made in.
It's just a guess, but it can possibly come from the compressed version.
Without strictly updating the code, some compressors generate again the RPYC files, what can generate save compatibility issues.
 

Penfold Mole

Engaged Member
Respected User
May 22, 2017
2,952
6,842
I'm also betting on the modded/compressed version *.rpyc indexes being different from the originals.
There's really nothing much you can do about it than to inform your players not to mix save files made by unofficial compressed versions or mods with the original game if they want to avoid those rollback errors.
This pretty much goes for all Ren'Py games.
 
  • Like
Reactions: Vanderer

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
Thanks again.

But I tried to load his save with the compressed version and it didn't work either...anyways, I am not really expected to support a compressed version anyways...still it bother me.

Another question: If I make the compressed version myself and rebuild the distribution with the same parameters, just the image folder replaced with the one with compressed renders, will it induce that sort of incompatibilities?
 

79flavors

Well-Known Member
Respected User
Jun 14, 2018
1,576
2,204
There are ways around it if you did delete an .rpyc file by accident... right up to the point you release the next version... at which point, you're locked in to the new version - because fixing it for one group of people would break it for the people playing the latest version.

Realistically, if it's working for most people - just not those few... then you probably didn't delete an .rpyc file.

As far as a "next chapter" bit of code... this is my usual one...
(usually as part of a file called chapter01.rpy).

Python:
label endof_ch01:

    if not renpy.has_label("ch02_start")
        call thank_you_for_playing

    if renpy.has_label("ch02_start"):
        jump ch02_start
    else:
        jump the_end

Then in the script.rpy file (so it can be used within future chapters)...

Python:
label thank_you_for_playing:

    "Thanks for playing, blah, blah, Patreon, blah, blah, valuable players, blah, blah, next release..."
    return


label the_end:
    return

It looks a little odd to check for the label twice... but that's to cope with players who save during the "Thank you for playing" called section, then load that save after the next chapter has been released.

It does have the advantage that it works before and after you release the next version of your game, without changing any code.
 

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
It does have the advantage that it works before and after you release the next version of your game, without changing any code.
Yes, it seems more...elegant. And I don't have to make sure the script is well aligned with the previous update. And since you do not modify the script, the chances of having an error are reduced.

I didn't know you could ask renpy to verify if a script has a label.

Thank you very much, I will try it now!
 

Vanderer

Active Member
Game Developer
Dec 8, 2017
620
1,900
And it works. I still don't know why the saves don't work in the version of the VN they were made, but it should make the next updates save not only less prone to errors (if I understood right), but it will make updating my VN easier.

Thank you very much!