Disabling Rollback and Auto-Save?

[xela]

Rollback:

Code: Select all

    config.rollback_enabled = False

Code: Select all

    $ renpy.block_rollback()

This does prevent user ability to rollback, I am not yet able to say if it actually stops Ren'Py from saving gamestates.

Auto-saving:

Code: Select all

    config.has_autosave = False
    config.autosave_frequency = None

Works partly (tried it in init python early/0, 9999)

Any ideas or input? This is really annoying for a game that doesn't require rollbacks and where auto-saving is causing visible delays

[Asceai]

To my knowledge the only way to disable rollback state from being recorded entirely is to change contexts, then disable rollback_enabled (to prevent the player from exiting the context with rollback controls)

In terms of autosave, setting has_autosave to False will prevent timed autosaves, but it will not prevent forced autosaves. Forced autosaves occur, as far as I can tell:

• When a MainMenu() action is invoked
• When a Quit() action is invoked
• When renpy.input() is called
• When renpy.choice_for_skipping() is called
• When the Quit or Main Menu buttons in config.game_menu are invoked

A forced autosave will only not autosave if the player is on the main menu or in a replay. So I guess all I could suggest is reimplementing MainMenu(), Quit() and renpy.input() and not using renpy.choice_for_skipping() (the config.game_menu stuff is obsolete anyway), or having the entire game take place on the main menu or in a replay.

[rakada]

could just hide the auto save /auto load button so that even if it does auto save they wont know/ can't use it

[Asceai]

Well, OP's problem was with the delays associated with autosaving; although those shouldn't really be a problem as most of the things that trigger a forced autosave are once-off interrupting events, not things that just happen in normal play.

[xela]

To my knowledge the only way to disable rollback state from being recorded entirely is to change contexts, then disable rollback_enabled (to prevent the player from exiting the context with rollback controls)

In terms of autosave, setting has_autosave to False will prevent timed autosaves, but it will not prevent forced autosaves. Forced autosaves occur, as far as I can tell:

• When a MainMenu() action is invoked
• When a Quit() action is invoked
• When renpy.input() is called
• When renpy.choice_for_skipping() is called
• When the Quit or Main Menu buttons in config.game_menu are invoked

A forced autosave will only not autosave if the player is on the main menu or in a replay. So I guess all I could suggest is reimplementing MainMenu(), Quit() and renpy.input() and not using renpy.choice_for_skipping() (the config.game_menu stuff is obsolete anyway), or having the entire game take place on the main menu or in a replay.

Thanks, that's a lot of useful info. I am not sure what yo do with this yet but this way I have an idea on where to begin. It just sucks that we're practically getting these features shoved down our throats if we want to use Ren'Py.

Theses measures are not simple to implement but I tend to figure stuff out given the time

Well, OP's problem was with the delays associated with autosaving; although those shouldn't really be a problem as most of the things that trigger a forced autosave are once-off interrupting events, not things that just happen in normal play.

That's right, problem is not players using auto-saves, that would be useful. Problem is that that they seem to happen inside of a menus I lock in while loops to allow viewing same choices more than once (in Ren'Py script). Maybe if jumping to the same label is used, it wouldn't be an issue, I'll test that later but code would get ugly with jumps. As game progresses, more and more characters are added to it so things are ok with save files sized around 1mb, there are delays but they are not really annoying. But with 1.5 - 2 mb savefiles it's gets pretty bad.

It'll be ok for now. At least I know that I haven't missed some simple setting somewhere that could have fixed both of these issues.

[Asceai]

I am not sure what yo do with this yet

To me, the easiest (and probably best?) way:

Code: Select all

init python:
  config.rollback_enabled = False
  config.has_autosave = False
label start:
  $renpy.call_replay("start2")
  return
label start2:
  $renpy.call_in_new_context("realstart")
  return
label realstart:
  "game goes here"
  return

This will make it impossible to save with the default controls... and it could potentially be uncooperative with respect to saves you force with python calls. But other than that it should work.

EDIT: Fixed things up so it actually works.

[xela]

Looks like it...

Situation isn't bad enough at the moment to justify this. I expect it'll get there eventually but this isn't something that is harder to do after 60k lines of code than after 40

In any case, this goes to my bookmarks collection.

[PyTom]

I'll note that a 1-2mb savefile likely means something is being saved that shouldn't be.

I'd suggest setting config.save_dump = True, waiting for an autosave, and then looking at save_dump.txt to see what's taking up all that space.

[xela]

Nope, took some time to glance trough 17 - 50Mb (depending on amount of characters loaded) textfile but it's legit, nothing foreign is being saved, there are no unexpected duplicates of any objects.

As I've said, situation as it stands is not all that bad, I have some ideas on how to tweak saving function in the future to kill all autosaves if it gets worse. Right now it's just like a nag... that functionality like auto-saves/rollbacks cannot be disabled completely. Ren'Py is doing it's job very, very well otherwise

[PyTom]

I'm not sure about that. I'd suggest sorting the file on numbers, and seeing what's taking up the space.

[xela]

I'll take a look at it again when time permits but I do not really expect to find anything. Amount of data loaded into the game more than justifies the size, I honestly see no reason to expect file to be any smaller.

[Tayruu]

As far as I can tell, the 'return to title' and 'quit prompt' functions all use $ renpy.loadsave.force_autosave(). But there are four versions. Why are there even four versions? label _quit_prompt, label _main_menu_prompt, class MainMenu(Action), class Quit(Action)?

Code: Select all

config.quit_action = ui.gamemenus("quit_prompt")

I used this, created a copy of the label/content _quit_prompt, and in that version (one without the preceding '_') I just removed force_autosave. Returning to the title was different though - because my menu appears to use action MainMenu(), I created a copy of the class and edited that.

As Asceai points out though, there still seems to be autosaves occurring, like after dialogue menus. I want to have complete control over autosaves - for example, at the start of chapters. I can't work out what's causing the others though, searching does not turn up the above force_autosave().

[xela]

I want to have complete control over autosaves - for example, at the start of chapters.

I gave up since it seemed that disabling auto-saves during menus would require editing Ren'Py and updating it with every release and that's not a good option, especially for a game in development.

Neither was I able to confirm that there is any repeating data in the save files, although I am not completely sure what that looks like in the dump files (those are 50 MB text files )

[PyTom]

I've added config.autosave_on_quit to 6.18, which controls autosaving on quit, main-menu, and load.

[xela]

I've added config.autosave_on_quit to 6.18, which controls autosaving on quit, main-menu, and load.

Great! But those are nowhere near as annoying as the once during the menus