Ren'Py Renpy error: not defined [Resolved]

[Jackykynn123]

What's wrong?

 

[defm64]

Remove the following section:

python:
    love = 0
    corruption = 0
    ntr = 0
    rose_love = 0

and set variables inside start label:

label start:
    $ love = 0
    $ corruption = 0
    $ ntr = 0
    $ rose_love = 0

    scene black with fade
    jump day_1

 

[Winterfire]

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

 

[defm64]

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

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.

 

[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

 

[defm64]

Yes...



No!




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.

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.

At no point did I suggest that variable definitions and other declarations should be spread throughout the code. Increasing the number of rpy files will negatively impact performance and further increase the risk of unexpected behavior for players with older devices. This should only be done if it is absolutely necessary or if the developer is willing to reduce the number of rpy files before generating a build.

 

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

 

[defm64]

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.

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

When I talked about the project growing, I was referring to the amount of code itself and I ended up not making that clear. It is not impossible for a game considered short to have much more code than expected due to one or more features.

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

Regardless of the type of question/situation, it is the OP's responsibility to provide as much information as possible to allow for more accurate suggestions, especially since this is not some kind of paid technical support. It is also the OP's responsibility to decide how and whether to actually use these suggestions. In the context of your joke, the OP would be 100% responsible for the outcome.