Menus and Autosave Issues

[AnnieTiamat]

So right now I'm handling a number of puzzles in my game with menu-style implementation instead of hotspots or choices. This works great EXCEPT it's entirely screwing up the autosave system - even with choices implemented later, loading the autosave of that choice will still bounce it back to the most recent menu-based puzzle. Actually, just hitting "Escape" will bounce the player back to the puzzle, not the main menu.

Obviously the menu code is subverting the use of the main menu somehow - a HUGE PROBLEM, given I use this method of menu-based puzzles more than once. How do I make sure stuff is correctly routed and saved?

[philat]

This isn't a particularly helpful post. What do you mean by "menu-style implementation"?

[AnnieTiamat]

Sorry, apologies for my end-of-day lack of clarity! Here's the deal.

I have a game that swaps between choices and puzzles frequently. The puzzles causing the problems are variants on a keypad entry sequence, which I derived from the code linked here:
viewtopic.php?f=8&t=40764#p431022

The tl;dr of that code is that instead of utilizing hotspots or standard choice-menu based inputs, it creates a NEW MENU (or rather, set of menus, since it flows through multiple choices), and decisions are routed through there. I have it utilized in three implementations:

• using the keypad to input a sequence of numbers (which I structured to show as a cascading sequence of menus, not just tapping entries on a single one)
• a "Pipe Dream" style puzzle in which clicking on a tile rotates it
• a "frequency" matching puzzle (really just a glorified number-guessing game) where the player taps a series of buttons to adjust values

The resultant issues are as follows:

• hitting the Escape key (which usually routes you to the save menu) instead resets the puzzle, even after the puzzle is finished.
• Further hitting Escape will open the proper menu, but is somewhat of a moot point since it's effectively undone your progress.
  attempting to load autosaves that have triggered after the puzzle (at a choice point, for example) will instead load the puzzle

In addition to all this, I'd like to learn up how to set up autosave points (since hotspots and menu choices don't trigger it), which could potentially solve part of this issue.

Any assistance on this would be hugely welcome! I can also post the code, but it's... it's VERY LONG. Like the shortest implementation is nearly 800 lines. I can also attempt to distill it, but being that it comes from that core code linked above (the key different being that it routes to another chunk of similar code), that would seem a better place to start than me just batch-dumping data here!

[AnnieTiamat]

...aaaaand I suppose a supplementary question to this would be how to set up the special menu-clicky buttons (skip and home, or at least home) for these puzzles.
I have a sinking feeling they'll need to be smacked into the puzzle itself. which makes me a sad panda. (Although I guess skip is less a worry since there's nothing to skip...)

[philat]

If what you mean by new menu is that you're using ShowMenu, then, well. Don't. Menus are in a different context from the flow of the main game, and naturally you can't save in them.

Code: Select all

default pw = ""

screen keypad():
    text pw xalign 0.5

    grid 3 4:
        for i in range(1,13):
            if i == 12:
                textbutton "E" action Return()
            elif i == 10:
                textbutton "C" action SetVariable("pw", "")
            elif i == 11:
                textbutton "0" action SetVariable("pw", pw+"0")
            else:
                textbutton str(i) action SetVariable("pw", pw+str(i))

label start:

    call screen keypad

    if pw == "1234":
        "Right"
    else:
        "Wrong"
        jump start

This is a completely functional keypad in 26 lines, counting whitespace. Obviously it would be longer using images, but like. 800 lines for a keypad puzzle? I'm not quite sure what you're trying to do.

[Scribbles]

you might want to try posting some of your own code here, and seeing if we can help based on that. I know with screens there are differences between Show and Call, Return, and Hide and I'd recommend reading over the documentation for screen language. If you post your code in this thread though, maybe someone can point out any issues?

[AnnieTiamat]

So the length of the keypad puzzle has less to do with the complexity of the puzzle itself and more how it's presented - likely I could revamp it to have a single puzzle presentation that just ran each selection through multiple if/else fall-throughs. I'll try to map it out gameplay-wise:

Puzzle screen presented
-> enter first number
---> number called out as confirmation in text (and visible as an image superimposed in the correct position on the screen)
---> corresponding variable set for both number and location (first number, X number - like "code_B_8")
---> number replaced as flat X
---> on to second number (new puzzle screen presented, keyboard menu
-> enter second number
---> (etc)
-> enter third number
---> (etc)
-> enter final number
---> (etc)
-> run test checking to see if ALL numbers are correct
---> IF YES, puzzle success, on to next thing
---> IF NO, are any correct
-----> YES, show which are correct (give the player a sense of progress), then restart puzzle
-----> NO, just jump to restart

Link to images here.

I think the key issue here is that I'm using ShowMenu to handle the jumps. I'll grab a code snippet (which, ironically enough, is going to be easier to show because I'm using big expanded multi-menu systems instead of a thicket of if/thens, which I'll probably end up rescripting anyway!)

OK - the setup here is you're in the first screen, and you select 1 on the keypad:

Code: Select all

            button:
                background None
                action SetVariable("code_set_A", True), SetVariable ("code_A_1", True), ShowMenu ("code_A_1")
                xysize 110, 110
                hover_background "#fff9"

that routes you to:

Code: Select all

label code_A_1:
    scene keyboard_start with fade_null
    show code_A_1 at codeA
    Ship "FIRST DIGIT ENTERED: 1" #this is the system telling the player what number they picked
    jump keyboard_code_B #jumps them to the next menu

(Quick note that I have a moment showing the player what they picked not just to confirm their choice visually, but because I didn't have any other means that I could find to keep the number up there as a superimposed variable while the menu was active)

This sequence repeats with choices for the second, third, and fourth number, then routes to a variable check, and splits from there into success and failure. The failure-state code is a big boring inefficient chunk of checking variables/showing images/hiding images/resetting variables, and is kludgey but at least works well

From the sound of it, the key issue is the ShowMenu command. If there's a better alternative that has the same result of bouncing the player to a "label" segment, I would be hugely happy, because that seems like a heck of an easier fix than I was fearing!

[Scribbles]

https://www.renpy.org/doc/html/screen_a ... ol-actions

^talks about various screen command actions

having the code show/jump around like that is probably causing issues. I believe if you show something and then want to hide it, use Hide() as opposed to just jumping. Also you can create a screen with the right sequence of numbers changing depending on the puzzle -- which may be a little complex code-wise but way more streamlined. I think screens can take arguments and then you could pass them on and then use them in the screen to help with checking for the right sequence. I'm not 100% sure though, hopefully that helps at least a little bit?

[AnnieTiamat]

Thanks for the link - I attempted Jump and it SEEMS like it's working, and I will seriously headdesk and laugh myself into insanity if THAT is the thing that works And I'm perplexed because I do remember attempting to do this before, and having RenPy scream at me. But if I can get this kicking by just swapping those commands out, you've saved my sanity (whatever is left of it, at least) Either way, I'll keep you posted - and if you think it would be helpful for anyone, I can clean up and post this code somewhere for free use

[AnnieTiamat]

OK - things seem like they're looking good so far (THANK YOU!!) - now the only element remaining is possibly forcing an autosave after the puzzle so there's no risk of error (also, seems a good place to have an autosave anyway).

HOWEVER:
- hunting for threads on autosaves have yielded little (mostly people wanting to turn them off, or people asking about them and dead-ending the thread)
- just putting in $ renpy.force_autosave doesn't seem like it works.

Any thoughts there?

[Remix]

You might want to also stipulate to only auto save if not in rollback...

Code: Select all

python:
    if not renpy.game.after_rollback:
        renpy.loadsave.force_autosave(True)

If that still does not create an auto save at that point you might have to debug the autosave_not_running object and make sure you are not in replay mode

[AnnieTiamat]

Good call there - where should I drop (or find) that code niblet you provided, if I may ask?

[Remix]

Just throw it in the label within the flowing conversation is probably best... Ren'py likes saves that are in the standard flow of the game...

Code: Select all

label whatever:
    ...
    "Play a game"
    call / show / jump / whatever
    ...
    "You won, well done"
    python:
        if not renpy.game.after_rollback:
            renpy.loadsave.force_autosave(True)
    "Now check the autosave slot"

It would/should also work within the game logic if outside an interaction...

[AnnieTiamat]

EXCELLENT! Nearly there - it didn't take a screenshot when it saved (but it DID SAVE!), and I know there's code for that SOMEWHERE. Might you have it on hand?

EDIT: Holy craziness. I checked this thread and found that if you delete the persistent stuff, it DOES appear with a screenshot. That's utterly mental but if it works, it works, AND RIGHT NOW IT WORKS <3

Thank you so much for all the help!