Issue with ui.callsinnewcontext and saving [SOLVED]

[Sondre]

Greetings!

I am turning to the forums as I'm starting to get...
"Desperate, your turn."
"Desperate."
"Desperate."
"Desperate."

I am working on a game which uses a whole bunch of screens. For instance, while in the "basement" label, the player can click on one of their dinosaurs, which in itself is a screen. Doing this will show screens related to that dinosaur, such as a "feed", "talk" and "kill" screen. Were a player to.. say, kill a selected dinosaur, it will of course disappear from view, and a whole bunch of variables will change.

Whenever one of these related dinosaur screens are clicked ("feed", "talk" and "kill"), I make the game use ui.callsinnewcontext to essentially reload the "basement" label where all this takes place. This is necessary for the game to update itself on the variables that change when you kill, feed or talk to one of your dinosaurs.

Now for the actual issue at hand. It would seem that whatever happens after a label has been loaded via ui.callsinnewcontext will not be saved should the player wish to save their game and load it later. Essentially, whenever the player loads their game after having interacted with their dinosaurs, all of those interactions are nullified.

"What a shame."
- JC Denton
2052


Here is some code to (hopefully) help you understand what is happening.
First off we got a simplified view of the basement label:

Code: Select all

label basement:

    if velociraptor <= 0:
        $ velociraptor_power = 0
        $ velociraptor_noise = 0
        $ velociraptor_food = 0
    if velociraptor == 2:
        $ velociraptor_power = 0
        $ velociraptor_noise = 0
        $ velociraptor_food = 0
        $ velociraptor_health = 10
        if velociraptor_hatch >= 3:
            $ velociraptor = 1
    if velociraptor == 1:
        $ velociraptor_stage = 1
        $ velociraptor_power = 2
        $ velociraptor_noise = 4
        $ velociraptor_food = 4
        if velociraptor_health >= 55 and velociraptor_health <=119:
            $ velociraptor_stage = 2
            $ velociraptor_power = 5
            $ velociraptor_noise = 10
            $ velociraptor_food = 8
        if velociraptor_health >= 120:
            $ velociraptor_stage = 3
            $ velociraptor_power = 3
            $ velociraptor_noise = 12
            $ velociraptor_food = 10
        if velociraptor_health <= 0:
            $ velociraptor = 0

    if velactive == 1:
        show screen velociraptor2
        show screen velociraptor_feed
        show screen velociraptor_kill
        show screen velociraptor_talk
        show screen velociraptor_info
    if velociraptor >= 1 and velactive == 0:
        show screen velociraptor

Here are the screens related to the velociraptor:

Code: Select all

screen velociraptor:
    vbox xalign 0.91 yalign 0.12:
        imagebutton:
            idle "ui/ui_velociraptor.png"
            hover "ui/ui_velociraptor_hover.png"

#All this messy stuff below has to do with the (probably inefficient) way I've dealt with the existance of 9 other dinosaurs in the game. Essentially, it hides screens from dinosaurs you no longer have selected as you're selecting the velociraptor. Very messy, though I am by no means a particularly skilled coding-person

            action [ SetVariable("oviactive", 0), SetVariable("velactive", 1), SetVariable("plaactive", 0), SetVariable("caractive", 0), SetVariable("triactive", 0), SetVariable("ankactive", 0), SetVariable("spiactive", 0), SetVariable("steactive", 0), SetVariable("albactive", 0), SetVariable("oloactive", 0), Show("velociraptor_kill"), Show("velociraptor_feed"), Show("velociraptor_talk"), Show("velociraptor2"), Hide("velociraptor"), Show("velociraptor_info"), Hide("albertosaurus_info"), Hide("albertosaurus_kill"), Hide("albertosaurus_feed"), Hide("albertosaurus_talk"), Hide("albertosaurus2"), If ( (albertosaurus == 1 or albertosaurus == 2), true = Show("albertosaurus"), false = Hide("albertosaurus") ), Hide("oviraptor_info"), Hide("oviraptor_kill"), Hide("oviraptor_feed"), Hide("oviraptor_talk"), Hide("oviraptor2"), If ( (oviraptor == 1 or oviraptor == 2), true = Show("oviraptor"), false = Hide("oviraptor") ), Hide("spinosaurus_info"), Hide("spinosaurus_kill"), Hide("spinosaurus_feed"), Hide("spinosaurus_talk"), Hide("spinosaurus2"), If ( (spinosaurus == 1 or spinosaurus == 2), true = Show("spinosaurus"), false = Hide("spinosaurus") ), Hide("carnotaurus_info"), Hide("carnotaurus_kill"), Hide("carnotaurus_feed"), Hide("carnotaurus_talk"), Hide("carnotaurus2"), If ( (carnotaurus == 1 or carnotaurus == 2), true = Show("carnotaurus"), false = Hide("carnotaurus") ), Hide("olorotitan_info"), Hide("olorotitan_kill"), Hide("olorotitan_feed"), Hide("olorotitan_talk"), Hide("olorotitan2"), If ( (olorotitan == 1 or olorotitan == 2), true = Show("olorotitan"), false = Hide("olorotitan") ), Hide("triceratops_info"), Hide("triceratops_kill"), Hide("triceratops_feed"), Hide("triceratops_talk"), Hide("triceratops2"), If ( (triceratops == 1 or triceratops == 2), true = Show("triceratops"), false = Hide("triceratops") ), Hide("ankylosaurus_info"), Hide("ankylosaurus_kill"), Hide("ankylosaurus_feed"), Hide("ankylosaurus_talk"), Hide("ankylosaurus2"), If ( (ankylosaurus == 1 or ankylosaurus == 2), true = Show("ankylosaurus"), false = Hide("ankylosaurus") ), Hide("stegosaurus_info"), Hide("stegosaurus_kill"), Hide("stegosaurus_feed"), Hide("stegosaurus_talk"), Hide("stegosaurus2"), If ( (stegosaurus == 1 or stegosaurus == 2), true = Show("stegosaurus"), false = Hide("stegosaurs") ), Hide("plateosaurus_info"), Hide("plateosaurus_kill"), Hide("plateosaurus_feed"), Hide("plateosaurus_talk"), Hide("plateosaurus2"), If ( (plateosaurus == 1 or plateosaurus == 2), true = Show("plateosaurus"), false = Hide("plateosaurus") ) ]
            activate_sound "sounds/Select2.ogg"
        
screen velociraptor_info:
    add If ( (velociraptor_stage == 1), true = ("ui/velociraptor1.png"), false = ("ui/nodinosaur.png") ) xalign 0.5 yalign 0.5
    add If ( (velociraptor_stage == 2), true = ("ui/velociraptor2.png"), false = ("ui/nodinosaur.png") ) xalign 0.5 yalign 0.5
    add If ( (velociraptor_stage == 3), true = ("ui/velociraptor3.png"), false = ("ui/nodinosaur.png") ) xalign 0.5 yalign 0.5
    add If ( (velociraptor == 2), true = ("ui/dinosauregg.png"), false = ("ui/nodinosaur.png") ) xalign 0.5 yalign 0.5
    text "[velociraptor_food]" outlines [ (absolute(0), "#000", absolute(0), absolute(0)) ] color "#4B372A" xalign 0.3386 yalign 0.371
    text "[velociraptor_noise]" outlines [ (absolute(0), "#000", absolute(0), absolute(0)) ] color "#4B372A" xalign 0.464 yalign 0.928
    text "[velociraptor_power]" outlines [ (absolute(0), "#000", absolute(0), absolute(0)) ] color "#4B372A" xalign 0.559 yalign 0.928
    text "{font=fonts/augusta.ttf}[Velociraptor_name]{/font}" outlines [ (absolute(0), "#000", absolute(0), absolute(0)) ] color "#4B372A" xalign 0.5 yalign 0.85
            
screen velociraptor_kill:
    vbox xalign 0.3285 yalign 0.7:
        imagebutton:
            idle "ui/kill.png"
            hover "ui/kill_hover.png"
            action [ SetVariable("velactive", 0), SetVariable("velociraptor", velociraptor - 2), SetVariable("meat", meat + 16), ui.callsinnewcontext("basement") ]
            activate_sound "sounds/reset.ogg"
            
screen velociraptor_feed:
    vbox xalign 0.3285 yalign 0.3:
        imagebutton:
            idle "ui/feed.png"
            hover "ui/feed_hover.png"
            action If ( (meat >= velociraptor_food), true= [ SetVariable("meat", meat - velociraptor_food), SetVariable("velociraptor_health", velociraptor_health + 10), ui.callsinnewcontext("basement") ], false = None )
            activate_sound "sounds/Select3.ogg"
            
screen velociraptor_talk:
    vbox xalign 0.3285 yalign 0.15:
        imagebutton:
            idle "ui/talk.png"
            hover "ui/talk_hover.png"
            action ui.callsinnewcontext("velociraptor_talk")
            activate_sound "sounds/Select3.ogg"
                
screen velociraptor2:
    vbox xalign 0.925 yalign 0.12:
        imagebutton:
            idle "ui/ui_velociraptor.png"
            hover "ui/ui_velociraptor_hover.png"
            action [ SetVariable("velactive", 0), Hide("velociraptor_info"), Hide("velociraptor_kill"), Hide("velociraptor_feed"), Hide("velociraptor_talk"), Hide("velociraptor2"), Show("velociraptor") ]
            activate_sound "sounds/Select2.ogg"

After the start label I have listed all the necessary variables (not showing the ones for other dinosaurs here):

Code: Select all

        $ meat = 20
    $ fruit = 20
    $ velactive = 0          #Used to tell the game whether or not a dinosaur is selected
    $ velociraptor = 1
    $ velociraptor_hatch = 0
    $ velociraptor_health = 10
    $ velociraptor_stage = 0
    $ Velociraptor_name = "Velociraptor"

So basically I'm looking for a way to have the game save properly. As mentioned earlier, anything that happens after a ui.callsinnewcontext doesn't seem to be saved. I've tried renpy.jump("basement") as a replacement but that just results in an infinite loop before I even get a chance to activate the screen. Removing ui.callsinnewcontext entirely made saving work, however one would have to exit and re-enter the basement label manually to see the changes that were made.

I realize my code is probably very unnecesarily overcomplicated, though I hope something can be done with what's already here instead of having to rewrite most of it.

Any help is much appreciated! ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤ ♥ ❤

[xela]

The hell is happening with the ui.callsinnewcontext... it's the fourth time in last two weeks it seriously messed people up. Don't use it. Especially if you don't understand what it does. Just use the shortest, simplest, most to the point actions like Show/Jump/call and etc.

Any unnecessary complicated code is a mistake, fix it by "simplifying" and not by asking for advice on how to sink into the quagmire even deeper.

That insane, unreadable mess of screen actions should be one function and (also) a true need to go out of context in Ren'Py is very rare.

===>

This is necessary for the game to update itself on the variables that change when you kill, feed or talk to one of your dinosaurs.

No, it really shouldn't be. The usual reasons to go out of context is to prevent interaction restart during interaction (usually due to poor code in the first place) or to get rid of rollback/saving system (which you can also do to a good degree without it).

===>>
I can't really advice on this stuff anymore as in every single instance so far, people I tried to help out get the result they desired by getting rid of stuff like ShowMenu() and ui.callsinnewcontext(), and not once (so far) did they get it right by doubling down on it.

Sometimes it works if you return from there properly but there hasn't been one case where it helped to really solve anything so far except for the two mentioned cases and even then it is rarely absolutely required with decent code setups.

[Sondre]

Hurray, problem solved!

I didn't realize I could use Jump in the same way as ui.callsinnewcontext.
Now that I've replaced every instance of ui.callsinnewcontext with Jump, the game seems to save and load just fine. The only issue is slight lag each time you feed or kill a dinosaur but this is probably due to my less-than-ideal code.

Always feels silly to come across such simple and easy fixes.

[Evildumdum]

This is strange since i've always used ui.callsinnewcontext with absolutely no problems. Usually to replace the call function in a screen. I've not yet found another function that will take you away from a screen and put you back without proceeding using the return function. I always use it when i have a button that will take me away from the main body of code to one that is in a fixed position. I can access that code with it and then return to an unspecified point, which is not possible with the jump function.

[xela]

This is strange since i've always used ui.callsinnewcontext with absolutely no problems. Usually to replace the call function in a screen. I've not yet found another function that will take you away from a screen and put you back without proceeding using the return function. I always use it when i have a button that will take me away from the main body of code to one that is in a fixed position. I can access that code with it and then return to an unspecified point, which is not possible with the jump function.

So you've (or you've maybe, it's not like it'll throw an error at you) instinctively used it in a correct (or at least acceptable) way. You'll prolly be ok if you don't try to save in the new context and return as soon as you're done with it. People are too often looking for an easy fix to some bad coding practice and use any function that seems to solve the immediate issue, no matter how scary that function sounds. Problems that are created later do not throw errors and are really hard to explain/track down.

[Onishion]

I don't use screens much (side from UI overlays), but some cases where I have, I used ui.callsinnewcontext. It's not that I'm in love with it or anything, but there doesn't seem to be any other way to use the standard "call" from within an screen, like a button action. In these cases I do want to advance and return to where I left when I pressed the button, but it would be nice if I could save while in there, or do the other more flexible ways you can use a basic call statement. If you could just "call" then that's what I'd use instead, but it's not an option, last I checked. That's part of the reason I don't use screens more in the first place, a lot of the most basic rules of Renpy/Python that I've learned for other areas are just arbitrarily different.

[xela]

I don't use screens much (side from UI overlays)

This might be going off-topic a little bit but when talking Ren'Py, I'd name screens one of the best features. When asked about the "holes" in the engine, I always say that it's the inability to completely block off rollback mechanism and inability to save just the current state of the game (forgetting everything before the current statement) but screens don't even come near "cons" column.

I've actually doubled down on screens and atl since SL2 was introduced.

I used ui.callsinnewcontext. It's not that I'm in love with it or anything, but there doesn't seem to be any other way to use the standard "call" from within an screen, like a button action.

Well... you wouldn't be using standard call anyway, they may "feel" the same, but what they do is quite different. And one could argue that using the standard "call" from within a screen is the way to use the standard "call" from within a screen. It would not return you to the current statement but neither would call (since you cannot even run it from a statement without using a screen or ui overlay). Rollback is a really bad bet in both cases because with normal call, you would not be able to roll forward and with new context, whatever the heck you did would be lost. You may be able to fix this but that also takes skill.

In these cases I do want to advance and return to where I left when I pressed the button, but it would be nice if I could save while in there, or do the other more flexible ways you can use a basic call statement. If you could just "call" then that's what I'd use instead, but it's not an option, last I checked.

As I've said, you can but it's still a farcry from perfect, you'd have to fix/disable rollback somehow or it'll still screw you over just in a different way than a new context would.

That's part of the reason I don't use screens more in the first place, a lot of the most basic rules of Renpy/Python that I've learned for other areas are just arbitrarily different.

I don't know what rules you're taking about but it's ok to use screens, as long as you do it correctly.

[Onishion]

Well... you wouldn't be using standard call anyway, they may "feel" the same, but what they do is quite different. And one could argue that using the standard "call" from within a screen is the way to use the standard "call" from within a screen. It would not return you to the current statement but neither would call (since you cannot even run it from a statement without using a screen or ui overlay). Rollback is a really bad bet in both cases because with normal call, you would not be able to roll forward and with new context, whatever the heck you did would be lost. You may be able to fix this but that also takes skill.

Well, what I mean is, I tend to use the default "menu" system for most of my interactions, and if I click on a menu item, and that activates a "call somelable," then the game will advance to that label, I can do some stuff, save, reload the save if I like and all's fine, eventually get to a return statement, return to where I came from, it's all good. There doesn't seem to be any way to trigger that sort of call statement using a screen-based element like an imagebutton, at least not as far as I've seen, so I used callsinnewcontext. And that works like a call, except that if I change anything, and then do not return from that label and do "anything else" first before saving, then my actions have not been remembered. Ideally I could just have the screen element make a simple "call" like a menu result can, but if that's possible I haven't found out how.

What's the issue you have with rollback, btw? Is it just a personal preference thing, that you don't want the players to be able to reverse their choices, or is there actually some objective flaw with them that makes them destructive to the game's progress?

I don't know what rules you're taking about but it's ok to use screens, as long as you do it correctly.

I just mean that when you are using things like imagebuttons, they have different rules for what they can do than a standard Renpy menu button, what goes into the "action" is more limited. If this is already possible then I'm just being an idiot, but I think it would be nice if you could do something like:

Code: Select all

imagebutton idle "images/button1a.png" hover "images/button1b.png" action:
    $ Variable += 2
    "You raised your variable by 2!"
    call somelabel
    jump someotherlabel

[xela]

Well, what I mean is, I tend to use the default "menu" system for most of my interactions, and if I click on a menu item, and that activates a "call somelable," then the game will advance to that label, I can do some stuff, save, reload the save if I like and all's fine, eventually get to a return statement, return to where I came from, it's all good. There doesn't seem to be any way to trigger that sort of call statement using a screen-based element like an imagebutton, at least not as far as I've seen, so I used callsinnewcontext. And that works like a call, except that if I change anything, and then do not return from that label and do "anything else" first before saving, then my actions have not been remembered. Ideally I could just have the screen element make a simple "call" like a menu result can, but if that's possible I haven't found out how.

It's not a good comparison, whatever you put after a "menu" choice is passed through the menu screen as an action. You can also use Function(renpy.call, "label_name") in a screen but as I've said, it'll come with it's own set of issues, even thought you prolly should be able to save/load to it.

What's the issue you have with rollback, btw? Is it just a personal preference thing, that you don't want the players to be able to reverse their choices, or is there actually some objective flaw with them that makes them destructive to the game's progress?

The latter, you can't save just the current state of the game, it's a very objective flaw that doesn't seem necessary if it wasn't for rollback.

I just mean that when you are using things like imagebuttons, they have different rules for what they can do than a standard Renpy menu button, what goes into the "action" is more limited. If this is already possible then I'm just being an idiot, but I think it would be nice if you could do something like:

Code: Select all

imagebutton idle "images/button1a.png" hover "images/button1b.png" action:
    $ Variable += 2
    "You raised your variable by 2!"
    call somelabel
    jump someotherlabel

Nah, this seems way too messy, I sometimes use screens from really long python statements so this doesn't look even remotely useful. I don't really want to go into it too deeply but this is fairly close to what menu does where the code is not executed from a screen, just passed thought it.

There are technical reasons why this shouldn't (and prolly cannot) be done from a long python statement (or it can but it'll end/reset the entire statement). Screens are far more flexible as they are now, because they can be used in both, Ren'Py and Python "worlds".

[Onishion]

Right, I mean that's why I like menus, they're easy to write and they can execute all sorts of different effects once the user picks a menu choice, with the downside that if you just use menus then the graphics involved are more fixed in place (unless you make a very complicated menu overlay). Whereas with screens, you have much more control over what the choices look like, you can put the buttons all over the screen and have them all be different shapes and colors, moving, whatever, but then the results when you actually click on them are much more limited, or if you can execute complex outcomes, it's only through much more complex code than the result of a menu choice.

[philat]

I mean, I sympathize insofar as I think differentiating between Renpy statements, screen language, ATL, and python is one of the biggest stumbling blocks for anyone who's looking to make the jump from noob to competent. But... they are different. I don't really know how one would even improve it; they just do different things. Like xela said, ui.callsinnewcontext and call label and call screen are all different mechanics -- even though they may feel similar.

I echo xela's statement, however, that 99% of the time, ui.callsinnewcontext and ShowMenu() are not what you want, unless you actually know your way around Renpy. This is based purely on hanging out here -- both are valid and have their uses, but are almost universally misused by beginners. Which is not to blame beginners; like I said, I sympathize, and I've been there. But xela's point is that most of the time, there is a better way. It's a rather rare use case where it's necessary.

[Onishion]

It might help then if in the documentation they would include an easy to use alternative for when people want a screen object's "action" to cause a Renpy label to be called. If that's not ui.callsinnewcontext then what would it be?

[xela]

It might help then if in the documentation they would include an easy to use alternative for when people want a screen object's "action" to cause a Renpy label to be called. If that's not ui.callsinnewcontext then what would it be?

There are technical reasons why this shouldn't (and prolly cannot) be done from a long python statement (or it can but it'll end/reset the entire statement). Screens are far more flexible as they are now, because they can be used in both, Ren'Py and Python "worlds".

There shouldn't/cannot be one because screen action is not a Ren'Py statement. What you get are two hacks we discussed, each with it's own flows but it's like asking aquanauts to build an Eiffel Tower... it's not a correct function/concept.

[Evildumdum]

So if the ability to call a Ren'py statement is incompatible with screen actions then what other ren'py statement compatible GUI options are available? Ren'py statements are a little too basic for more advanced GUI's.

As a possible mitigation to the problems ui.callsinnewcontext causes, would disabling the save function while inside a ui.callsinnewcontext called section of code work?

[xela]

So if the ability to call a Ren'py statement is incompatible with screen actions then what other ren'py statement compatible GUI options are available? Ren'py statements are a little too basic for more advanced GUI's.

It's not incompatible with screen actions, you can call using a screen action. It's not compatible with design of the engine. Screens can always be shown so there is always a very high chance that you click on the button in the middle of interaction/statement execution. There often will not even be a good point to return to so it's best not to do it at all.

As a possible mitigation to the problems ui.callsinnewcontext causes, would disabling the save function while inside a ui.callsinnewcontext called section of code work?

That's one of the things you have to do anyway as you cannot load into new context. Blocking/fixing rollback is also pretty much a must, I don't know enough about rollback to know which is best.