Ren'Py Non-persisten replay gallery?

[SPkiller31]

Hi,

I have basic replay gallery that allows replaying certain labels that have been already seen via "action Replay("event)" .

AFAIK screen language/or that particular example has to use persistent data and because of that, each next playthrough will have everything unlocked(or rather everything player saw in last playthrough).

My question is, what would be cleanest way to make replay buttons locked back whenever player starts new game? (Visible but grayed out ofcourse)

I tried using action Replay("EventTest", locked=persistent.TestFlag) and setting default variable to False, having it being changed to True at the end of chosen label but no matter what, label remained pernamently unlocked. (I have yet to try clearing my Renpy cache completely but regardless I think it should work in new game, as variable is being set to False/True but it didn't) It was recommended to me to try that and maybe I just don't know about something regarding persistent values.

Thanks to the idea of folks I know that I could make something like question at the start of the game/option in Settings that would clear all persistent data but it would prevent something like having latest build save-file and launching new game to check different routes or would require shuffling files from player's side so I keep it at the last resort. Plus it would possibly reset sound/any option player has changed in Settings.


Thanks in advance.

 

[anne O'nymous]

AFAIK screen language/or that particular example has to use persistent data and because of that, each next playthrough will have everything unlocked(or rather everything player saw in last playthrough).

It's the intent. The replay gallery is designed to be similar to an achievement system, therefore it persist between playthrough.

My question is, what would be cleanest way to make replay buttons locked back whenever player starts new game? (Visible but grayed out ofcourse)

It's not the solution.
You want it to be dependent of the playthrough, but you don't need to start a new game to have different playthrough. It suffice to save before the first choice, and to follow different route depending on the save file you'll load.

This mean that you need to build your own gallery system. There's example in this part of the forum if I remember correctly.

 

[SPkiller31]

It's the intent. The replay gallery is designed to be similar to an achievement system, therefore it persist between playthrough.




It's not the solution.
You want it to be dependent of the playthrough, but you don't need to start a new game to have different playthrough. It suffice to save before the first choice, and to follow different route depending on the save file you'll load.

This mean that you need to build your own gallery system. There's example in this part of the forum if I remember correctly.

So probably building it from scratch huh? I don't mind it as it should be simple/basic enough to do but I thought I will be able to make use of locked function or anything like that. Thank you for clarifying that. Never before thought about it as achivements but it makes sense, really good example.

Now when I read your answer very dumb idea came to my head but it sounds too obvious: Would it be also possible to just make if statements that will check if label has been seen and label-releated variable is set to True and then, display either plain text or textbutton with replay action depending on said variable? Prolly very barbaric way of implementing that but sounds fool-proof as it should correctly update with default variables when loading save or starting game. I believe all relation points, including mine work on similar way.

Anyway thanks a lot for answer and guiding me in right direction.

 

[osanaiko]

As the esteemed AnneO said, the best way is to roll your own solution.

Using the "seen_label" built-in method (

You must be registered to see the links

) will not be limited to a single playthrough or save, it is universal across all playthroughs (using the hidden persistent data in %Appdata%).

But luckily there is something you can control for such a per-save "gallery" system:
- add to your defaults initialization section

default seen_scenes = []

- in each label where you have a image or scene you want to be revealed in the gallery, add a manual flag for that scene:

$ seen_scenes["X_Y_Z"] = True

- Then in your gallery code, check the "seen_scene" array for the flags for the scenes that have been seen and can be replayed. (i.e. draw the rest of the fucking owl here

You must be registered to see the links

)

 

[crabsinthekitchen]

can't you just use normal variables (the ones with default and define) instead of persistent? I mean, yeah, the replay gallery won't work from the main menu without loading a save but I've seen stranger things. so whenever it says persistent.something in the tutorial you'd just skip the persistent. part and use your variables

another thing you might try is label callbacks to reset the persistent data to whatever is in the game
something like

init python
    def my_callback(label, newcontext):
        persistent.scene1 = store.scene1
    
    config.label_callback = my_callback

so the gallery would still use persistent data and work from the main menu but would be reset when you start a new game or load a different save

offtopic: writing that last line of code always makes me want to rant about how renpy having only one label callback instead of an array is terrible but that's another topic and not like I'd do any better

 

[anne O'nymous]

But luckily there is something you can control for such a per-save "gallery" system:
- add to your defaults initialization section

default seen_scenes = []

- in each label where you have a image or scene you want to be revealed in the gallery, add a manual flag for that scene:

$ seen_scenes["X_Y_Z"] = True

Shouldn't it be default seen_scenes = {} ?
I past the morning writing Perl code, I'm not sure of my Python right now.

This being said a list can also do it ; or more precisely a set:
/!\ Wrote in the fly, there's perhaps a typo or two /!\

# List of the seen scenes for this playthrough.
# /default/ because the value need to be saved.
default seen_scenes = set( () )

#  List of all the scenes that can be replayed. It's the /label/ name, because it permit to
# have a smaller code.
# /define/ because this need to never be saved, for save compatibility purpose.
define all_replayable_scenes = [ "replayable_scene", "scene1", "scene2" ]


# One of the replayable scene.
label replayable_scene:
    #  Add the name of the label into the /seen_scenes/ set, to mark that it's 
    # now replayable.
    $ seen_scenes.add( "replayable_scene" )
    #  If it's a replay...
    if _in_replay:
        # adjust the variables that need to be adjusted.

    # The whole scene take place here.
    [...]

    # If it's a replay...
    if _in_replay:
        #  Send the player back where he was before replaying.
        return

    # Else, so if it's not a replay, branch where you would normally branch.
    [...]

screen gallery:

    # browse all the existing replayable scenes.
    for scene_name in all_replayable_scenes:
        # The scene have been seen and is replayable.
        if "scene name" in seen_scenes:
            # An /imagebutton/ that permit to replay the scene.
            imagebutton:
                #  The image are named accordingly to the scene. Therefore,
                # "replayable_scene_replay.png", "scene1_replay.png", and so on.
                idle "{}_replay.png".format( scene_name )
                #  Call the label for this scene. Calling will permit to send back the
                # player here.
                action Call( scene_name )
        # The scene haven't been seen, and so isn't replayable.
        else:
            # Show a generic image.
            add "looked gallery.png"

    [...]

The screen need to be worked on, because as it, it would be a real mess. But there's the

You must be registered to see the links

screen statement that permit to present this better.