Ren'Py Renpy error: not defined [Resolved]

[Jackykynn123]

What's wrong?

 

[Winterfire]

Even better, just keep them loose in a rpy file. No point in keeping them inside a label.

 

[anne O'nymous]

Remove the following section:

Yes...

and set variables inside start label:

No!

Defining these initial variables at the beginning of the start label will prevent unexpected behavior as the project grows in size, as well as making things clearer and more organized.

Wrong.


It's not an issue for the first release of a game, but for it only.

For any following release, either the code is kept clear and organized, with all variables declaration being grouped in the "start" label, and therefore the game will not be save compatible. Or the game is kept save compatible, and therefore the variables declaration will be spread all over the code, what is the opposite of "clear and organized".

And, obviously, doing it for the very first release is also not an option, because it starts a bad habit.



Ren'Py have two statements specially dedicated to variables declarations, and every devs should use them. The first one being

You must be registered to see the links

d as constants, and the second being

You must be registered to see the links

for all the other variables.

This is the only way to have both a clear and organized code, and a save compatible game (at least when it come to variables). All declarations are located in the same place, by example a loose file like Winterfire said. This while ensuring that all variables will exist in a players play, whatever the moment they've been added to the game, whatever how old the save file is, and whatever content the player have seen during his own playthrough.

 

[Winterfire]

I am starting to understand why so many games suffer from "unsupported save files"
Always wondered how people managed to screw up so badly.

 

[Jackykynn123]

Fixed; replaced python statement with default

 

[peterppp]

The OP did not provide any detailed information about the project, including whether there will be several updates at different times or whether these variables will actually be used later in the next chapters/days. If it is a project with a really short story, there may not even be a need for players to use saves.

Considering a scenario like this and that when a variable is not defined at game start, using the "default" statement is the same as defining the variable at the beginning of the start label, my solution is still applicable and is still a clear/organized way to deal with these initial variables in the limited context presented by the OP. I am not obligated to imagine/foresee all the different scenarios where it is necessary to give different instructions to someone who asks a question here with limited information.

if you don't know, then give an answer that works for all scenarios. if your solution only works for a specific scenario, then you should have said so in your answer. that's just common sense

you even said "as the project grows in size" which doesnt sound like a small one-off short story.

 

[anne O'nymous]

The OP did not provide any detailed information about the project, [...]

What you wrote reads like: "well, it's not my fault if OP killed his mother following what I said. He should have been more explicit, and explained that 'she's ill, how can I help her' was about a human person having a flue, and not about an agonizing animal."

 

[Turning Tricks]

The solution I gave solves the immediate problem the OP presented and will allow the project to run without errors. I really don't have to guess all the needs of his project. It would be up to him to make these aspects clear somehow or wait for another answer that better meets his needs (which he apparently did).

But that's wrong. While it might let this particular example run without an error (right now), putting the initial variable declaration inside the start label has different behavior than if you properly initialized it at INIT time, using the default statement. Something that Ren'py says on

You must be registered to see the links

...

"Here, we'll show how to store a flag containing information about a choice the player has made. To initialize the flag, use the default statement, before label start."

The OP was clear with both their problem and in sharing the applicable code. Anyone who wrote a Ren'py project with the variables initialized inside the game loop would run into all sorts of issues down the line, including saves not working properly.

If you find the Ren'py docs not much use, then read some guides like

You must be registered to see the links

, who writes clear and easy to follow Ren'py tutorials.

 

[anne O'nymous]

The OP was clear with both their problem and in sharing the applicable code.

Talking about this, strictly speaking, and obviously outside of the safe way to declare variables, his error was to write python in place of init python.

Like python is a valid statement, and due to the way Ren'Py works, it's not explicitly an error, reason why Ren'Py didn't complained.

By design, labels aren't closed blocks, therefore when Ren'Py reach the end of a block, if there's no explicit branching (like jump or call), Ren'Py will continue to progress linearly into the code in the current RPY file. It's the reason why some devs achieve to have code like this:
/!\ None of the following code are to use in your own game. /!\

label start:
scene whatever
mc "Hello, my name is [mc.name]."
girl "Oh my god, you're so beautiful, please fuck me."

In the example above, the "start" label is technically empty, and serve just as marker for free code. But this imply that something like:

default myVar = 42

label start:
    "Value is [myVar]"

python:
    myVar = 24

label following:
    "value is now [myVar]"
    "END"

would works as well. In fact the second label is even optional and this too should works:

default myVar = 42

label start:
    "Value is [myVar]"
python:
    myVar = 24
"value is now [myVar]"
"END"

Now, while it's not to use, it's also not totally useless knowledge.
It's not to use, but sometimes, especially for devs who are doing this on their freetime, your mind wander and you forgot an indentation, or do errors like this. Then like your code still works, you don't notice it, until the day where it strike back and trigger a bug.
Knowing that something dirty like this works can help you to keep in mind that "it worked before I added this" do not mean that the error isn't located in code that you wrote five months ago.



All this said, in OP code, the python block happen before the "start" label, what mean that Ren'Py never proceeded it. What OP wanted is something like:

init python:
   [variable declaration]

The leading "init" tell Ren'Py that the block is to proceed before the game starts, while the "python" tell it that the following will be a Python block.

All this obviously not changing what I said above regarding variable declaration.

 

[Turning Tricks]

Talking about this, strictly speaking, and obviously outside of the safe way to declare variables, his error was to write python in place of init python.

Like python is a valid statement, and due to the way Ren'Py works, it's not explicitly an error, reason why Ren'Py didn't complained.

By design, labels aren't closed blocks, therefore when Ren'Py reach the end of a block, if there's no explicit branching (like jump or call), Ren'Py will continue to progress linearly into the code in the current RPY file. It's the reason why some devs achieve to have code like this:
/!\ None of the following code are to use in your own game. /!\

label start:
scene whatever
mc "Hello, my name is [mc.name]."
girl "Oh my god, you're so beautiful, please fuck me."

In the example above, the "start" label is technically empty, and serve just as marker for free code. But this imply that something like:

default myVar = 42

label start:
    "Value is [myVar]"

python:
    myVar = 24

label following:
    "value is now [myVar]"
    "END"

would works as well. In fact the second label is even optional and this too should works:

default myVar = 42

label start:
    "Value is [myVar]"
python:
    myVar = 24
"value is now [myVar]"
"END"

Now, while it's not to use, it's also not totally useless knowledge.
It's not to use, but sometimes, especially for devs who are doing this on their freetime, your mind wander and you forgot an indentation, or do errors like this. Then like your code still works, you don't notice it, until the day where it strike back and trigger a bug.
Knowing that something dirty like this works can help you to keep in mind that "it worked before I added this" do not mean that the error isn't located in code that you wrote five months ago.



All this said, in OP code, the python block happen before the "start" label, what mean that Ren'Py never proceeded it. What OP wanted is something like:

init python:
   [variable declaration]

The leading "init" tell Ren'Py that the block is to proceed before the game starts, while the "python" tell it that the following will be a Python block.

All this obviously not changing what I said above regarding variable declaration.

It's funny that when I wrote my first release on F95 here, I had almost my whole Intro scene written in the script.rpy file, inside the start label.

I soon learned that it's much easier and more "future proof" to just make new rpy files for each scene and then have a block to control their calls. So now my script.rpy just has the call for my "traffic control" and also a few after load blocks to add the multi.persistent declarations for the other VN.

My traffic control looks like this... (a01 is Act 1, a02 is Act 1 etc)

label Traffic_Cop:

    call intro from _intro
    call a01 from _call_a01
    call a02 from _call_a02
    call a03a from _call_a03a
    call Exit_Interview from _call_Exit_Interview

    return

I have a similar block to control each scene within an Act. And when you add content, you just add it into the stack right after the last Act released.