Ren'Py Problems using default to declare variables.[SOLVED]

[9thCrux]

I'm trying to define variables using default:

# Define variables.

default x1 = 0
default x2 = 0
default x3 = 0
default x3 = 0

# The script of the game goes in this file.

I'm placing the variables at the very top of the script file, and when I try to run the game is giving me an error:
File "game/script.rpy, line 8: expected statement.

Line 8 has the "# The script of the game goes in this file." which is just a comment.

What am I doing wrong?

I just want to set the variables value to 0 so I can add or subtract later on.

 

[9thCrux]

Update:

I was trying out stuff and moved the variables to the start of the "Label start" block:

# The game starts here.

label start:

    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0

I haven't get an error, seems to be working fine now...
I guess I should do some testing.

 

[Deleted member 1121028]

Not an expert and someone will explain better but it should start like this

init :
    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0

label start:
"blablabla"

 

[9thCrux]

Not an expert and someone will explain better but it should start like this

init :
    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0

label start:
"blablabla"

Interesting, I didn't try to use the
init :

I'm trying to build a form of route system which uses stats to define which options to show.
So is like some interactions add to the variable's value and then if the value is high enough you have more options available.
Kinda like:

if x1 == 5:
do this.

else:
do this instead.

And I'm guessing <=, >=, == are conditions that can be used to check the value...

I'm just learning this stuff but I think I have to use if, else, and maybe elif to check the variable's value assign an action based on the variable(s) value...

Sorry, I'm trying to make sense of it to understand it.

Update:

Yay!
It worked!

Added init : at the start, then used x1+= 5 to add to the variable, and if x1 == 5 to check the value and display something and it works. ^^

 

[the66]

you don't have to place default statements within an init block. they are executed at init level. also you can place them wherever you want in your scripts. it's just easier for you to access them, when they are at the beginning of a script or within a separate file.

 

[9thCrux]

you don't have to place default statements within an init block. they are executed at init level. also you can place them wherever you want in your scripts. it's just easier for you to access them, when they are at the beginning of a script or within a separate file.

Yes, but I was getting this error:

I'm placing the variables at the very top of the script file, and when I try to run the game is giving me an error:
File "game/script.rpy, line 8: expected statement.

Line 8 has the "# The script of the game goes in this file." which is just a comment.

I don't know what was wrong but when I added the
init :

Solved the problem.
Now it looks like this:

#Variables.
init :
    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0
# The script of the game goes in this file.

 

[79flavors]

I'm trying to define variables using default:

# Define variables.

default x1 = 0
default x2 = 0
default x3 = 0
default x3 = 0

# The script of the game goes in this file.

I'm placing the variables at the very top of the script file, and when I try to run the game is giving me an error:
File "game/script.rpy, line 8: expected statement.

Line 8 has the "# The script of the game goes in this file." which is just a comment.

What am I doing wrong?

Based on this code... as far as I can see, nothing is wrong - at least not structurally.

You do have TWO default x3 = 0 lines. Why that would generate that particular error, I don't know. When I add that with RenPy 7.3.4, I get a different error.

It is perfectly fine to have those default lines right at the top of the code, as you've described. (Well, after you remove the duplicate line).

I just want to set the variables value to 0 so I can add or subtract later on.

To risk confusing matters... you don't technically need default to do that. But it is still a really, really good idea to code it this way.

In theory, you could do:
$ x1 = 0
$ x1 += 1

... which would create the x1 variable with a value of 0 and then add 1 to it.

However the problem is save file compatibility.
If in a later patch you added $ x5 = 0 and someone loaded a save file from after where that line of code could have been executed, x5 wouldn't exist - because RenPy hasn't run that line of code for that particular player. Which is one of the reasons why default was added. It is executed at init time and so the value ALWAYS exists (and so doesn't cause runtime errors).

As far as your original problem... I'm going to guess it's that 2x "x3" definition - even though I got a different error.

The only other thing that comes to mind would be something like a misplaced {line feed} or {carriage return} character in there somewhere. Some editors, especially in Linux/Unix don't always use both {LF}{CR} at the end of each line. Could be some weird thing where RenPy sees two lines merged together. I really doubt this one, but it came to mind.

I note by your first update, you've removed the duplicate x3 and added x4 and x5... and things are fixed. I'm going to suggest that, rather than where you moved it to as being the reason it works from that point.

 

[9thCrux]

Based on this code... as far as I can see, nothing is wrong - at least not structurally.

You do have TWO default x3 = 0 lines. Why that would generate that particular error, I don't know. When I add that with RenPy 7.3.4, I get a different error.

It is perfectly fine to have those default lines right at the top of the code, as you've described. (Well, after you remove the duplicate line).



To risk confusing matters... you don't technically need default to do that. But it is still a really, really good idea to code it this way.

In theory, you could do:
$ x1 = 0
$ x1 += 1

... which would create the x1 variable with a value of 0 and then add 1 to it.

However the problem is save file compatibility.
If in a later patch you added $ x5 = 0 and someone loaded a save file from after where that line of code could have been executed, x5 wouldn't exist - because RenPy hasn't run that line of code for that particular player. Which is one of the reasons why default was added. It is executed at init time and so the value ALWAYS exists (and so doesn't cause runtime errors).

As far as your original problem... I'm going to guess it's that 2x "x3" definition - even though I got a different error.

The only other thing that comes to mind would be something like a misplaced {line feed} or {carriage return} character in there somewhere. Some editors, especially in Linux/Unix don't always use both {LF}{CR} at the end of each line. Could be some weird thing where RenPy sees two lines merged together. I really doubt this one, but it came to mind.

I note by your first update, you've removed the duplicate x3 and added x4 and x5... and things are fixed. I'm going to suggest that, rather than where you moved it to as being the reason it works from that point.

Seems like it is some kind of text editor glitch, because the variables I was using were different, not x1 ...x5, I changed them to not make public the variables I'm actually using. I made the duplicated x3 when I was renaming them to make the forum post.

I will be making a lot of changes to my game over time and I want to prevent future problems, I'm glad we can use default to prevent problems with variables.

I'm using Ren'Py 7.3.5.606 by the way.


Thanks for the info, I haven't get that far learning Ren'Py, many things still a mystery to me.

 

[anne O'nymous]

You do have TWO default x3 = 0 lines. Why that would generate that particular error, I don't know.

I would generate an error, but to point that the variable is defaulted twice.

Seems like it is some kind of text editor glitch, because the variables I was using were different, not x1 ...x5,

It can also be the name of the variable, or the value assigned.
When the syntax error throw by Ren'py point to a line that is correct, most of the time it mean that it was trying to proceed the previous line as multi-line, but have failed for something else that the basic missing (, [, ' or ".

More generically, if there's absolutely no error on the pointed line, then the error is in the previous line or a line before this.
And in this particular case, there's the only possible errors on the pointed line is either a wrong character for the starting # (but still a valid UTF-8 character, else the error would be different), or a wrong encoding for the end of the line, but there really few reason for this to affect only one line.

The fact that placing it in an init bloc solve the problem is just a side effect. More than effectively solving the error, it silenced it, for a reason of another.

 

[LoafyLemon]

Ren'py requires of you to include the start label in one of the script files and you seem to be missing it, that's why the compiler throws an error. As previously mentioned, you don't need to add `init:` before default statements.

default x1 = 0
default x2 = 0
default x3 = 0
default x4 = 0
default x5 = 0

label start:
    # game loop
    "Hello World."
    return

 

[9thCrux]

Ren'py requires of you to include the start label in one of the script files and you seem to be missing it, that's why the compiler throws an error. As previously mentioned, you don't need to add `init:` before default statements.

default x1 = 0
default x2 = 0
default x3 = 0
default x4 = 0
default x5 = 0

label start:
    # game loop
    "Hello World."
    return

Nope, added the variables to the script in my game.
It was already a functional Ren'Py game before adding the variables, meaning that there was a label start.

I only used that example to illustrate where I was placing the variables; at very top of the script.
Is a strange glitch and I'm guessing it has to do with the text editor and updating Ren'Py... I don't know.

 

[79flavors]

Not an expert and someone will explain better but it should start like this

init :
    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0

label start:
"blablabla"

you don't have to place default statements within an init block. they are executed at init level. also you can place them wherever you want in your scripts. it's just easier for you to access them, when they are at the beginning of a script or within a separate file.

Reaffirming this statement and to repeat what I said in the other thread... default does not belong in an init: block.

Yes, but I was getting this error:

I don't know what was wrong but when I added the
init :

Solved the problem.
Now it looks like this:

#Variables.
init :
    default x1 = 0
    default x2 = 0
    default x3 = 0
    default x4 = 0
    default x5 = 0
# The script of the game goes in this file.

Then there's something else going on. Something which you haven't repeated within this thread.
Most games don't need an init: block at all. At least, not most of the time.

What it should look like is:

#Variables.
default x1 = 0
default x2 = 0
default x3 = 0
default x4 = 0
default x5 = 0

# The script of the game goes in this file.
label start:
    "*** THE START ***"
    "Hello World"
    "*** THE END ***"
    return

... with the default lines at the top of the script, no init: block (unless you need it for something else) and a label start: somewhere as the game's starting point.

And yes, I realize you're going to say it didn't work like that... and I'm going to say that it's something else that this fixes by accident, not design.

 

[9thCrux]

And yes, I realize you're going to say it didn't work like that... and I'm going to say that it's something else that this fixes by accident, not design.

I just went ahead and tried again; I removed the init block and just left the variables at the top of the script file...
Now is working and I'm not getting any error so far...
OMFG... the ghost in my machine hates me!

I'm going to keep testing but it seems like the glitch is gone.