Ren'Py 5.6.7 Released

[Jake]

When we write python code directly in the scripts, does rollback work ?

I read this part to mean 'yes':

When compling a python block, when we encounter a list literal like [1, 2, 3], we need to call RollbackList to replace it with a rollback list. This is done transparently to the end user, when python blocks are compiled in renpy files.

...although as I understand it, rollback only rolls between renpy interaction points, so all that really typically means is that the state changes made by the python code are rolled back, as if a snapshot of the state before entering the python code had been taken.

(My mindset interprets rollback a little like a long series of nested COM+ transactions, each mousewheel up rolls back the innermost transaction, each renpy interaction creates a new one. I'm sure the code behind it is simpler than that, though, and of course it doesn't take into account rollforward.

... that said, a 'commit' might be an interesting, if bizarre, thing to have...

[monele]

Well I think the "commit" exists in the sense that there is a function to prevent from rollbacking starting from a point.

[PyTom]

When we write python code directly in the scripts, does rollback work ?

Yes. The code that I've written to make rollback work is applied to the python blocks in the script, so rollback works here. (At least, for code that doesn't go too far out of the way to make it not work.)

And if we don't "import" but actually change the py sources, even though you don't recommend it :p, does this problem occur too?

I'm not sure what you mean by this. There are only two ways of getting code into memory. Either it's imported by python, or loaded by Ren'Py by virtue of being in a python block.

Jake >>> It's not precisely nested transactions, since we do eventually age out older rollbacks. It's best to think of it as object versioning, where we keep the ability to roll back objects some number of previous versions.

Roll-forward is fairly simple. When we run the program the first time, we allow it to store roll-forward information in each version. When a version is rolled-back, that information is placed onto a stack. When rolling forward, we pop the top element off of that stack, and that's used as the default result of the interaction when the user pushes roll-forward. Add a little logic that disables roll-forward if the user isn't repeating himself, and everything works, at least in the common cases. (An important part is that failure disables roll-forward while keeping the game correct.)