Ren'Py label with a list of variables

[liberatorus]

I was going through a game's code and noticed a file called variables.rpy

label variables:

    #character relationship variables
    default lilyRS = 0
    $ persistent.lilyMet = False
    
    # And a lot more variables after
    # ......
   
    return

As far as i can see there is no `jump variables` anywhere. (searched using grep) How do these variables actually get defined? If control never reaches this label

The game in question is Jury if that helps.

 

[GetOutOfMyLab]

It's possible they are calling the label, given that it has a return statement at the end. Either way, I do not recommend defining variables inside labels like this.

 

[liberatorus]

It's possible they are calling the label, given that it has a return statement at the end. Either way, I do not recommend defining variables inside labels like this.

Interesting, just checked it doesn't seem to be called using the call statement either. Is there something I can do like put a `print(stacktrace)` or something similar inside the label that lets me see where exactly it's getting called from?

 

[GetOutOfMyLab]

I did a search for "variables" and there are no references to it at all. However, when Ren'Py loads, even if inside a label, it will read the default keyword and set the variable. So the label doesn't actually have to be jumped to or called... it's defined at init.

 

[79flavors]

... that lets me see where exactly it's getting called from?

It's not getting called from anywhere.

default is one of a list of commands that, in effect, are executed when the game starts.
The label has nothing at all to do with them and is likely just the author copy/pasting code from someone who didn't understand it either.

Things like default, define and image are NOT executed at runtime.

When you hit the [START] button on almost every game, those default values are loaded - regardless of where the statements are located within the code.
For much the same reason, those same statements are treated as comments while the script is running (since they've already been executed).

As with all programming languages, there are some caveats with all that. But that's the basics of it.

I wrote this example for a another thread which highlights the point...

label start:

    "*** START ***"

    $ myvar1 += 1
    "value is [myvar1]."

    default myvar1 = 5

    "new value is [myvar1]."

    "*** THE END ***"

Will display 6 and 6, not 6 and 5 (or even 1 and 5).

Most developers will put statements like these at the top of the scripts, or create separate scripts to hold them. It's purely for organizing things, RenPy doesn't care. But it makes sense to the programmer and will make their lives easier in the future, if they know where to find things that are initialized.

Edit: (for a bit of clarity)...

default should be used for variables where the value will be (or is likely to be in the future) changed by the script.
define should be used for variables that will remain unchanged while the script is running.

 

[79flavors]

I was going through a game's code and noticed a file called variables.rpy

label variables:

    #character relationship variables
    default lilyRS = 0
    $ persistent.lilyMet = False
   
    # And a lot more variables after
    # ......
  
    return

I just went back and looked at this again and it works... but not for the reasons the original author probably thought.

label variables: - not needed.
default lilyRS = 0 - is fine. But doesn't need to be indented (or within a label).
$ persistent.lilyMet = False - will never be executed, unless a call variables is added to the script.
return - no more needed than the label.

They get away with the persistent variable, because they wanted the default value to be False.
But that line of code is never run and so the variable will never be set. But a peculiarity of persistent variables is that they don't cause runtime errors if they don't exist and will generally behave like an empty string and/or False - depending on how they are used. The end result is the same for this script, but by accident rather than design.

Personally, I would use default persistent.lilyMet = False - since this is clearly a variable that will be changed with the actions of the player and following that rule is safer when starting out. I could explain why it doesn't strictly need to be default like other variables - but that would just muddy the waters and honestly just go into a level of detail not needed for this type of question. Keep it simple - if it's going to change, it should be default.

 

[anne O'nymous]

I just went back and looked at this again and it works... but not for the reasons the original author probably thought.

[Emphasis is mine]


Ren'Py biggest force, but also its biggest flaw...

 

[Kalu12345]

Can someone tell me how to get this variables.rpy file in the game folder? I used Unren to do this but still couldn't get this variables.rpy file. The game in question is Demon Curse

 

[79flavors]

Can someone tell me how to get this variables.rpy file in the game folder? I used Unren to do this but still couldn't get this variables.rpy file. The game in question is Demon Curse

RenPy doesn't care what the files are called. Just because one game has a variables.rpy, doesn't mean other games will have an identical file. Demon Curse does not have a variables.rpy file.

You've picked an abomination of a game (at least, as far as variables go).

For example, the character names are defined within \renpy\common\00action_menu.py.
I can't begin to explain how odd that is. I'm sure the developer has their reasons... I can't imagine what they are.

 

[Kalu12345]

RenPy doesn't care what the files are called. Just because one game has a variables.rpy, doesn't mean other games will have an identical file. Demon Curse does not have a variables.rpy file.

You've picked an abomination of a game (at least, as far as variables go).

For example, the character names are defined within \renpy\common\00action_menu.py.
I can't begin to explain how odd that is. I'm sure the developer has their reasons... I can't imagine what they are.

Hey thanks man. I am a layman here can you guide me how to change the stamina and lust in that game. Someone in that games thread explained that there is a variables.rpy file and the stamina and lust bar can be altered.

 

[79flavors]

Hey thanks man. I am a layman here can you guide me how to change the stamina and lust in that game. Someone in that games thread explained that there is a variables.rpy file and the stamina and lust bar can be altered.

It depends.
Mostly upon how much you know about the RenPy console.

If you haven't already, rerun UnRen can select "3) Enable Console and Developer Menu".
That will enable the console and the developer tools.

Spoiler: 00action_menu.py

You don't have permission to view the spoiler content. Log in or register now.

Yeah. Okay. This guy is an arse.
Right at the bottom of their code for handling the advancing of time is a bit of code that basically says "if the player has enabled the console, ZERO OUT the player's progress".

        if config.console == True:
            aeziana_love = 0
            aeziana_lewdness = 0
            jenna_love = 0
            jenna_lewdness = 0
            mandy_love = 0
            mandy_lewdness = 0
            jasmin_love = 0
            jasmin_lewdness = 0
            mary_love = 0
            mary_lewdness = 0
            lila_love = 0
            lila_lewdness = 0
            nina_love = 0
            nina_lewdness = 0

First thing you're going to need to do is edit the \renpy\common\00action_menu.py file and remove those lines from the code.

Oh... dear gods, it gets worse.
They've also hidden some code in /renpy/common/00preferences.py too.

    if config.console == True:
        jump turn_off

# then later...

    if not xconfig:
        jump turn_off

The label turn_off: again zeroes out the player's progress and in this case, calls the player a cheater then quits to the main menu.

All 4 of those lines need to be removed too.

Oh wait... here we go again...

Again, in \renpy\common\00action_menu.py, the developer has created a new function called jackass.

It checks if the console is enabled, switches it off and resets all the player's progress. /sigh.
Thankfully, as far as I can tell, it is only invoked once. So remove the two lines:

    python:
        jackass()

Now, back to my original explanation...

It depends.
Mostly upon how much you know about the RenPy console.

If you haven't already, rerun UnRen can select "3) Enable Console and Developer Menu".
That will enable the console and the developer tools.

Because of the way the developer has handled variables (not using default), none of those variables exist until they are first used.

However, once they do - you can press <ALT + D> together to bring up the developer menu and select "Variable Viewer". It will let you know the variable names and their current values. Just use the [RETURN] button when you want to return back to the game.

In addition to <ALT + D>, you can also use <ALT + O> to bring up the RenPy console.
From there you can enter RenPy and/or python commands.

Realistically, you probably only need (up to) 4 commands.

print <variablename>	Shows the value (not much different than the variable viewer).
<variablename> = <value>	Change the value of a variable to any value you like.
watch <variablename>	Add a variable to the "watch list" (a small window in the top right, that will show you the values while you play the game)
unwatch <variablename>	Remove a variable from the watch list.

Examples...

print mandy_love
mandy_love = 60
watch mandy_love

In addition, the <ESC> key will return you to the game.

This developer is going out of their way to avoid people cheating. Presumably because they intend to add a cheat menu to the phone, for Patreon/Subscribestar members only.
Personally, I would wait for them to add that functionality for them - then wait for the inevitably hack that bypasses the restriction for non-subscriber players.

 

[dude.FF]

watch <variablename>	Remove a variable from the watch list.

unwatch <variablename>