AttributeError: ‘StoreModule’ object has no attribute ‘_history'

[emz911]

Hi all, two of my players have encountered this following error when loading (I believe mainly on and after Quick Load, which is activated by pressing the shortcut key “L”):

Error Screenshot

AttributeError: ‘StoreModule’ object has no attribute ‘_history'

I traced down to Line 156 in 00library.rpy but am not quite sure where this '_history' variable came from. Any clue? Help is very appreciated!

[IrinaLazareva]

It's hard to say without the code.
First, Check line 2363 of script.rpy (as well as the line above and the line below).
Also maybe you have variable with reserved name, for example, "extend"...

[emz911]

It's hard to say without the code.
First, Check line 2363 of script.rpy (as well as the line above and the line below).
Also maybe you have variable with reserved name, for example, "extend"...

Line 2365 is a "show screen" statement and 2363 is a "call screen" statement which I use all the time, it just starts the simulation part of the game. I looked through the reserved name list and don't believe I used the same variable names...

More information:
They say they get this error when they S/L too many times (mostly quick save and quick load), and when they get this error, they can't continue the game even after ignoring it.
My only clue of what is triggering this error is that my game's first version included a long list of default variables, but those default variables led to bugs (for example, loading a game caused a default variable to reset), so I deleted these default variables afterwards and updated a new game version without them (now they're all defined under init with the same name). May this error be because those saves had the old default variables? But what does that have to do with new quick saves and new quick loads? I can't wrap my head around that and the "_history" attribute. Also, I tested the game out a lot of times after updating and deleting the default variables, no errors appeared, so I don't really expect the error to have to do with this, but this is the only thing I can think of. Perhaps this has nothing to do with it?

[gas]

You can retain variables after load...
https://www.renpy.org/doc/html/save_loa ... after-load

[emz911]

You can retain variables after load...
https://www.renpy.org/doc/html/save_loa ... after-load

Hi, I don’t quite understand how this function works... does this work like persistent values where a newly started game saves the value of the last played game? Or does it have to do with saving and loading different gameplays? If saving a save slot stores all variables already, what does this do? Would you mind explaining a bit more? Thanks!!

[gas]

Renpy saves are not exactly "freezes": they save "one step back in time", the last content of the rollback cache, and execute from that point onward when you load.
One thing that's not saved is the state of variables WHILE interacting with a screen (that's mean in the same "step" of the rollback cache).

You call the screen, you modify a variable, while you are in the screen you save. Well, that variable value is not saved. It will be saved after the screen (the next step in the rollback cache), not in the meanwhile.
That's why you've seen your defaults got a reset after loading.

Every time you call a screen that could change game data (more probably, when you call a screen that modify many things and imply many clicks), you should first call retain_after_load.
So the game save the state of such variables the very moment you save instead of using the last checkpoint status.
This is not a default behaviour for a lot of technical and design reasons.

Using 'default' declarations and retain after load should solve your first problem and very likely the second one too.

[emz911]

Renpy saves are not exactly "freezes": they save "one step back in time", the last content of the rollback cache, and execute from that point onward when you load.
One thing that's not saved is the state of variables WHILE interacting with a screen (that's mean in the same "step" of the rollback cache).

You call the screen, you modify a variable, while you are in the screen you save. Well, that variable value is not saved. It will be saved after the screen (the next step in the rollback cache), not in the meanwhile.
That's why you've seen your defaults got a reset after loading.

Every time you call a screen that could change game data (more probably, when you call a screen that modify many things and imply many clicks), you should first call retain_after_load.
So the game save the state of such variables the very moment you save instead of using the last checkpoint status.
This is not a default behaviour for a lot of technical and design reasons.

Using 'default' declarations and retain after load should solve your first problem and very likely the second one too.

Wow, understood. I’ll go home and test this out! Thank you for the explanation!