[Solved] renpy.fix_rollback() is broken with menus

[martingerdes]

EDIT: This is actually just a plain bug in renpy.fix_rollback()
Please see my comment below for steps to reproduce it.

====original post====

So I updated Ren'Py to 7.4.11, finally. Luckily, it seemed to be a drop-in replacement, and everything continued to work.
Now, however, I have noted a problem.

Before, I had the following hacky way to achieve rollback without allowing choices to change:

Code: Select all

def menu(items, interact=True, screen="choice"):
                rv = renpy.display_menu(items, interact=interact, screen=screen)
                rlb = renpy.game.log
                if not rlb.rollback_is_fixed:
                    rlb.fixed_rollback_boundary = rlb.log[-1].context.current
                return rv

Source: https://github.com/renpy/renpy/issues/1446

After the upgrade to 7.4.11, this does not work anymore.
Does someone know how to achieve that effect with the current version?
I really don't want to start plastering renpy.fix_rollback() all over my code. But at the same time I really don't want making changing choices as easy as using the scroll wheel. My players should at least savescum to do that!

Edit: If I roll back one step further, and then advance, I can't change the choice. But if I roll back exactly to the choice, I can. I just verified this was not the case in 7.3.5.
So something must have subtly changed in Ren'Py's rollback implementation...

[zmook]

Is the only problem with fix_rollback() that you don't want to have to type it for every menu? You could use mode_callbacks to trigger it when leaving menu mode:

Code: Select all

init python:
    def auto_fix_rollback(mode, old_modes):
        if old_modes[0] == 'menu' and mode != 'menu':
            renpy.fix_rollback()
            
    config.mode_callbacks.append(auto_fix_rollback)

I just tested in 7.4.11.

[martingerdes]

Thank you alot for that suggestion! I did not even know such a function existed...
Now that I read up the documentation on that: https://www.renpy.org/doc/html/modes.html
I have at least a much more elegant solution for my use case.

However, all that ended up doing, is replacing my hacky solution with an elegant one.
The problem though, is apparently a real bug in the Ren'Py version 7.4.11:
When you roll back precisely to the menu, you can change your choice. Only if you roll back one step more, does it become locked in. Which obviously isn't helpful at all...

Reproduction case:
Create a new Project, open script.rpy, and replace the default text section with:

Code: Select all

    e "You've created a new Ren'Py game."
    e "Here is a menu:"
    menu:
        "option 1":
            $ renpy.fix_rollback()
        "option 2":
            $ renpy.fix_rollback()

    e "Once you add a story, pictures, and music, you can release it to the world!"

If you go back to "Here is a menu:", then you can't change your selection. However, if you roll forward past your choice, and then back again exactly to the menu itself, you can choose either "option 1" or "option 2" again...

Should I make a bug report for this somewhere else, or is this thread enough to get this noticed? Because this is obviously just wrong...

[Ocelot]

I think, it still a bug, but conditions seems to be somewhat different from what you are describing.
You can remake your choice if you have rolled back exactly one step.
For example in following code:

Code: Select all

    e "You've created a new Ren'Py game."
    e "Here is a menu:"
    menu:
        "option 1":
            $ renpy.fix_rollback()
        "option 2":
            $ renpy.fix_rollback()
    '123'
    e "Once you add a story, pictures, and music, you can release it to the world!"

Situation you described will only happens if you roll back exactly on '123' line. If you went past it, no amount of scrolling will enable choice again.
So, the impact is not that big.

Anyway, RenPy issues list is here: https://github.com/renpy/renpy/issues , you can report this one if you want.

[martingerdes]

Thank you Ocelot! I didn't even have the idea to try to advance further and check whether the bug still applied...
So solved.

I've cleanup the test case and opened an issue for it: https://github.com/renpy/renpy/issues/3183
But knowing that it's locked in after one step more makes it indeed a fairly small problem.