Menus and Autosave Issues

Discuss how to use the Ren'Py engine to create visual novels and story-based games. New releases are announced in this section.
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
Post Reply
Message
Author
User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Menus and Autosave Issues

#1 Post by AnnieDB » Thu Sep 21, 2017 4:58 pm

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
Eileen-Class Veteran
Posts: 1205
Joined: Wed Dec 04, 2013 12:33 pm
Contact:

Re: Menus and Autosave Issues

#2 Post by philat » Fri Sep 22, 2017 3:51 am

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

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#3 Post by AnnieDB » Fri Sep 22, 2017 1:25 pm

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!

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#4 Post by AnnieDB » Fri Sep 22, 2017 2:21 pm

...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
Eileen-Class Veteran
Posts: 1205
Joined: Wed Dec 04, 2013 12:33 pm
Contact:

Re: Menus and Autosave Issues

#5 Post by philat » Sat Sep 23, 2017 12:06 am

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.

User avatar
Scribbles
Veteran
Posts: 428
Joined: Wed Sep 21, 2016 4:15 pm
Completed: Pinewood Island
Projects: As We Know It, By Moonlight, Possessed[hiatus],
Organization: Scribble Games
Tumblr: doodlesatbreakfast
Deviantart: breakfastdoodles
itch: scribbles
Location: Georgia
Contact:

Re: Menus and Autosave Issues

#6 Post by Scribbles » Mon Sep 25, 2017 10:23 am

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?
Image - Image

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#7 Post by AnnieDB » Mon Sep 25, 2017 4:15 pm

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!

User avatar
Scribbles
Veteran
Posts: 428
Joined: Wed Sep 21, 2016 4:15 pm
Completed: Pinewood Island
Projects: As We Know It, By Moonlight, Possessed[hiatus],
Organization: Scribble Games
Tumblr: doodlesatbreakfast
Deviantart: breakfastdoodles
itch: scribbles
Location: Georgia
Contact:

Re: Menus and Autosave Issues

#8 Post by Scribbles » Mon Sep 25, 2017 5:20 pm

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?
Image - Image

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#9 Post by AnnieDB » Mon Sep 25, 2017 5:30 pm

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 :)

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#10 Post by AnnieDB » Mon Sep 25, 2017 5:50 pm

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
Veteran
Posts: 248
Joined: Tue May 30, 2017 6:10 am
Contact:

Re: Menus and Autosave Issues

#11 Post by Remix » Mon Sep 25, 2017 7:09 pm

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

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#12 Post by AnnieDB » Mon Sep 25, 2017 7:50 pm

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

Remix
Veteran
Posts: 248
Joined: Tue May 30, 2017 6:10 am
Contact:

Re: Menus and Autosave Issues

#13 Post by Remix » Tue Sep 26, 2017 4:40 am

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...

User avatar
AnnieDB
Regular
Posts: 35
Joined: Tue Dec 01, 2015 3:24 pm
Location: Seattle
Contact:

Re: Menus and Autosave Issues

#14 Post by AnnieDB » Tue Sep 26, 2017 4:51 pm

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! :D

Post Reply

Who is online

Users browsing this forum: No registered users