I've decided to give up the idea, once I've noticed that even if I make it work, replacing the original object in the namespace would lead to problems if I'd like to recreate the singleton, for example when updating the variables to the never version of the game.
I'd still be interested to know how and where in the engine are the stores implemented. I've found the StoreModule class in renpy/python.py, but it's pretty bare-bones and I can't really find where is it actually used and how does the engine decide which variables should be saved and which shouldn't.
==============
=== ORIGINAL POST ===
So, I'm storing most of my game variables in singleton objects. This is a problem as changes in the fields of those objects aren't saved by Ren'Py.
An obvious solution would be to instantiate each in a separate default statement, but it would lead to spatial separation between the object and the instance and, even worse, it leads to quite a bit of boilerplate code.
So I've been thinking of automating it with something along the lines of
Code: Select all
init python:
def singleton(cl, *args, **kwargs):
default_store.__sett_default_attr__(cl.__class__.__name__, cl(*args, **kwargs))
@singleton(1, 2)
class ASingletonObject:
def __init__ (self, one, two):
self.one = one
self.two = two
I'm not too concerned about it changing between versions as it seems like a rather core feature of Ren'Py. And even if it should change, once I know how it's done, tracking down the change history shouldn't be very time consuming.
