"No module named matrix" after migrating the game to another pc

[Adabelitoo]

I changed PCs and I got the "No module named matrix" when I tried to load a save. This only happens with the game I'm developìng, not with other games. I copy-pasted the folder with the game so all those files are the same and I also copy-pasted the saves from User/Appdata/Roaming/Renpy to the new pc. Not sure what I am missing. Not all of my saves have this problem and before noticing this I moved the label (where the game tries to load) to another .rpy but I've done this before and never causedd an issues besides the save going to the beginning of the label instead of the exact line when the save was made. Just to be extra sure I copy-pasted the game from the other pc, this time without making changes, and I got the same error again.

In case it helps, I first downloaded Renpy 7.4 from the website but I had another problem related to 7.4 (as far as I could google) so I deleted the folder and used the .exe from the other pc to install 7.1, the one I was using before.

 

[anne O'nymous]

I changed PCs and I got the "No module named matrix" when I tried to load a save. This only happens with the game I'm developìng, not with other games.

The error happen only when there's a regression of Ren'py version. You're trying to load a save file made with a more recent version of Ren'py than the one actually used. So I guess that when you changed your PC, you installed a too old version of the SDK.

 

[Adabelitoo]

The error happen only when there's a regression of Ren'py version. You're trying to load a save file made with a more recent version of Ren'py than the one actually used. So I guess that when you changed your PC, you installed a too old version of the SDK.

You made me realize that even if the folder inmy other pc said "7.1" I updated RenPy after that so my current version was 7.3.5. Now I downloaded that version but the error now says

"Exception: Couldn't find a place to stop rolling back. Perhaps the script changed in an incompatible way?"

I moved some labels to other .rpy files but that's nothing I haven't done before without this problem. I copy-pasted the folder from my old pc without changes and the same happens.

 

[anne O'nymous]

"Exception: Couldn't find a place to stop rolling back. Perhaps the script changed in an incompatible way?"

I moved some labels to other .rpy files but that's nothing I haven't done before without this problem. I copy-pasted the folder from my old pc without changes and the same happens.

Basically speaking, Ren'py is confused and don't know anymore where you left it when you saved. It's probably a combination between the label move, new version and perhaps also rebuilding from scratch. There isn't really a solution to fix this, alas.

 

[79flavors]

If you have a built version of the game that works, there is one thing I can think of.

• *** BACK UP YOUR PROJECT FIRST ***
• * READ THIS WHOLE ADVICE BEFORE STARTING TO DO IT *

• Run the latest version of the game that players are currently playing (re-download it if you have to).
  • If your game still has an "About" screen, use it to find the version of RenPy you used to use.
  • Otherwise open the log.txt in the game's main folder. The RenPy version is there too.

• Download that same version of RenPy and install it.

• Hopefully the configuration settings will be picked up automatically, but if not... configure your settings.

• Use UnRen to unpack the version of the game people are playing.
  • Delete any now unneeded *.rpa archive files.

• Create a new directory within your RenPy projects folder/directory. Call it something like "<project> resurrected".

• Copy the whole /game/ folder and all subfolders to from the "latest working game" to your RenPy project folder.
  • Within the RenPy project folder...
  • Delete the script_version.txt file.
  • Delete the game/cache/ and game/saves/ folders.

• --- You now have a development version of the game people are playing. ---

• Launch it from the RenPy launcher... make sure you are happy everything works as intended.
  • Specifically, try loading save files. Delete any that don't work.
    • Since this is the same version players are actually playing, any save files that don't work must be save files you've saved while swapping and changing between RenPy versions. They are incompatible with the live game and therefore are useless.
    • Some save files may be using a version of the code that still in development. Those are never going to work with all this messing about. Just delete them too. (You always have your backup... you did back up, right?!?!?!).

• Quit the game and go to your "<project> resurrected" RenPy project folder.

• Delete all *.rpy files, in the /game/ folder and any sub-folders too.
  • ONLY *.rpy files.
  • *** DO NOT DELETE THE MATCHING *.rpyc FILES ***

• Copy all the *.rpy files from your backup project folder. i.e. the latest developer version of the source code.
  • ONLY *.rpy files.

• If, as part of your development, you have removed or renamed any of your source script files; delete the mismatched .rpyc files that are still hanging around. ONLY files that no longer have a matching .rpy file. I can't stress enough how much you need to be careful here. For most developers, there won't be any that need deleting at this stage.

• Launch the game through the RenPy launcher. Again make sure everything works how you planned, including any new game code added after the "live" version.

And that's it... just carry on developing.

If you want to update to the latest version of RenPy, you can do so safely now.

Save/Rollback compatibility is all about what I think of as the "code cross reference" stored in the *.rpyc files. Any time you add/update/delete lines of code, that cross reference is updated in the matching .rpyc file to reflect the updated code. If the cross reference is ever corrupted, recreated or gets out of step with the live code - then save files will stop working.

But, by copying back the latest "live" version of the game - you are restoring the *.rpyc files back to the point where they worked just fine.
When you copy the latest development version of the *.rpy script files into the new project folder, RenPy is forced to apply all those code changes to the existing *.rpyc cross reference data. RenPy can't tell the difference between when you change 1 line of code or when you change 1,000. So all those script updates just get incorporated to the existing files... and everything carries on as normal. But now with a version of the *.rpyc files that is compatible with the live/players version of the game.

The only thing that won't work will be any saved games saved AFTER the latest version of the game was previously released. Those will be pointing at a version of the cross reference data that no longer exists. Thankfully, that only affects you as a developer and not the end users.

If you are in any doubt... DON'T DO THIS.
There is a huge potential for fuck ups while doing this.
Just tell your players that due to a development cockup, all previous save files are corrupted.
Change the define config.save_directory = "xxxxx" to something else in your options.rpy file - to make it difficult for players to load old save files and put it all down to a learning experience.

 

[Adabelitoo]

If you have a built version of the game that works, there is one thing I can think of.

• *** BACK UP YOUR PROJECT FIRST ***
• * READ THIS WHOLE ADVICE BEFORE STARTING TO DO IT *

• Run the latest version of the game that players are currently playing (re-download it if you have to).
  • If your game still has an "About" screen, use it to find the version of RenPy you used to use.
  • Otherwise open the log.txt in the game's main folder. The RenPy version is there too.

• Download that same version of RenPy and install it.

• Hopefully the configuration settings will be picked up automatically, but if not... configure your settings.

• Use UnRen to unpack the version of the game people are playing.
  • Delete any now unneeded *.rpa archive files.

• Create a new directory within your RenPy projects folder/directory. Call it something like "<project> resurrected".

• Copy the whole /game/ folder and all subfolders to from the "latest working game" to your RenPy project folder.
  • Within the RenPy project folder...
  • Delete the script_version.txt file.
  • Delete the game/cache/ and game/saves/ folders.

• --- You now have a development version of the game people are playing. ---

• Launch it from the RenPy launcher... make sure you are happy everything works as intended.
  • Specifically, try loading save files. Delete any that don't work.
    • Since this is the same version players are actually playing, any save files that don't work must be save files you've saved while swapping and changing between RenPy versions. They are incompatible with the live game and therefore are useless.
    • Some save files may be using a version of the code that still in development. Those are never going to work with all this messing about. Just delete them too. (You always have your backup... you did back up, right?!?!?!).

• Quit the game and go to your "<project> resurrected" RenPy project folder.

• Delete all *.rpy files, in the /game/ folder and any sub-folders too.
  • ONLY *.rpy files.
  • *** DO NOT DELETE THE MATCHING *.rpyc FILES ***

• Copy all the *.rpy files from your backup project folder. i.e. the latest developer version of the source code.
  • ONLY *.rpy files.

• If, as part of your development, you have removed or renamed any of your source script files; delete the mismatched .rpyc files that are still hanging around. ONLY files that no longer have a matching .rpy file. I can't stress enough how much you need to be careful here. For most developers, there won't be any that need deleting at this stage.

• Launch the game through the RenPy launcher. Again make sure everything works how you planned, including any new game code added after the "live" version.

And that's it... just carry on developing.

If you want to update to the latest version of RenPy, you can do so safely now.

Save/Rollback compatibility is all about what I think of as the "code cross reference" stored in the *.rpyc files. Any time you add/update/delete lines of code, that cross reference is updated in the matching .rpyc file to reflect the updated code. If the cross reference is ever corrupted, recreated or gets out of step with the live code - then save files will stop working.

But, by copying back the latest "live" version of the game - you are restoring the *.rpyc files back to the point where they worked just fine.
When you copy the latest development version of the *.rpy script files into the new project folder, RenPy is forced to apply all those code changes to the existing *.rpyc cross reference data. RenPy can't tell the difference between when you change 1 line of code or when you change 1,000. So all those script updates just get incorporated to the existing files... and everything carries on as normal. But now with a version of the *.rpyc files that is compatible with the live/players version of the game.

The only thing that won't work will be any saved games saved AFTER the latest version of the game was previously released. Those will be pointing at a version of the cross reference data that no longer exists. Thankfully, that only affects you as a developer and not the end users.

If you are in any doubt... DON'T DO THIS.
There is a huge potential for fuck ups while doing this.
Just tell your players that due to a development cockup, all previous save files are corrupted.
Change the define config.save_directory = "xxxxx" to something else in your options.rpy file - to make it difficult for players to load old save files and put it all down to a learning experience.

This is huge. I always make a copy of my project right before making the build so I already have a development version of the game people is playing. I think I'm gonna do a small patreon exclusive update with one scene to check if save compatibiility is messed up or not before this. Thank you for your super detailed explanation.

 

[79flavors]

I didn't think to say it, but copying stuff the other way around would potentially work too.
Instead of doing the whole "recreate live version" thing... instead copy the .rpyc files from your live version into your development project folder. (*cough* backups).

But the way I've done it in the past is the way I described above. It also offers more opportunities to test things are holding together at various stages along the way.

There's a blog post by PyTom that explains the thing I call the "cross reference" in more detail. Though even there, he's being pretty non-technical about it.

You must be registered to see the links

Think of it as each line is given a unique line number and that line number is stored in the .rpyc file. If anything bad happens to the .rpyc file, then all those line numbers are renumbered - and with it goes the ability of the save file system to figure out where anything is up to.

The system I've described above is just a way of keeping the old line numbers (the ones the users are using) and generate new ones for the lines updated since then. It's not perfect (since any developer only saves may be useless), but it's the best you can recover to once it's all gone tits up.

Obviously it's even more complicated than that. Especially once you realize it's all linked to

You must be registered to see the links

nodes.