Ren'Py Can't figure this out.

[Vollezar]

I am not a coder. I know a bit but not enough, obviously, to fix this error. Can anyone help me figure this out?

I'm sorry, but an uncaught exception occurred.

While running game code:

  File "game/scripts/chapter03.rpy", line 6445, in script

    if fcslow and likealex and (alexkiss or noalexkiss):

  File "game/scripts/chapter03.rpy", line 6445, in <module>

    if fcslow and likealex and (alexkiss or noalexkiss):

NameError: name 'noalexkiss' is not defined

-- Full Traceback ------------------------------------------------------------

Full traceback:

  File "game/scripts/chapter03.rpy", line 6445, in script

    if fcslow and likealex and (alexkiss or noalexkiss):

  File "renpy/ast.py", line 2115, in execute

    if renpy.python.py_eval(condition):

  File "renpy/python.py", line 1092, in py_eval

    return py_eval_bytecode(code, globals, locals)

  File "renpy/python.py", line 1085, in py_eval_bytecode

    return eval(bytecode, globals, locals)

  File "game/scripts/chapter03.rpy", line 6445, in <module>

    if fcslow and likealex and (alexkiss or noalexkiss):

NameError: name 'noalexkiss' is not defined

Windows-10-10.0.19041 AMD64

Ren'Py 7.5.3.22090809

One Lie 0.5.1

Mon Sep 26 10:05:12 2022

Thank you.

 

[Catapo]

The error itself says what the problem is, you don't have a variable for noalexkiss.

You probably wanted to write (alexkiss or not alexkiss) ... but this condition is redundant since it will always return True so you can remove it entirely and leave just: if fcslow and likealex:

 

[Vollezar]

There is supposed to be an 'noalexkiss' variable. I guess it was not coded in by the programmer.

Thank you.

 

[79flavors]

The other consideration is that noalexkiss is not changed by the the script you've provided (chapter 03).

So it must be set within chapter01 or chapter02 (or any introduction).

There are other variables alexkiss / likealex. If you can find where they are set, it might make more sense as to what's going on.

Elsewhere in the same code, there is a check for not alexkis, which makes sense. But checking alexkiss and not alexkiss is pointless (it's a bit like checking a coin toss to be both "heads" AND "tails" at the same time).

If you have enough knowledge about RenPy, you could just change the line to just:
if fcslow and likealex

Ultimately, better to report it as a bug to the original author.
(we might be able to offer a better alternative, if we knew which game it was that is failing... then we can look at all the code).

 

[Vollezar]

I think I know why it wasn't set properly. There is a choice early on in the game where that variable is supposed to come up. Either alexkiss (if the player chooses for the kiss to happen) or noalexkiss (if the player stops the kiss). The programmer did not actually set the noalexkiss variable. Instead, if the player does not choose the alexkiss the game is supposed to default to noalexkiss. I have no idea why. Honestly, it makes no sense to not do it properly (i.e. if the player refuses the kiss it creates a variable $ noalexkiss=true).
I have fixed the issue by just erasing the (alexkiss or noalexkiss). Since either one have the same outcome in this scene no point in having them there anyway. Those two variables are sub-variables to another variable, which is the one that is important to the decision regardless of whether the kiss happens or not.

 

[anne O'nymous]

Honestly, it makes no sense to not do it properly (i.e. if the player refuses the kiss it creates a variable $ noalexkiss=true).

This is not doing it properly.

The variable MUST exist before the choice is given to the player, this precisely in order to avoid all those possibilities of errors:

#  Can be /define/ in place of /default/, since it's boolean values it don't 
# change much. But having the habit to use /default/ is better.
default alexkiss = False
default alexnokiss = False

label whatever:
    menu:
        "kiss the girl":
            # alexnokiss stay at False since the player choose to kiss
            $ alexkiss = True
            [...]
        "I never seen Disney's little mermaid":
            # alexkiss stay at False since the player choose to not kiss
            $ alexnokiss = True
            [...]

Now, this being said, like 79flavors implied about another issue in the code, this is relatively useless.
There's no need to have a flag for both the kiss and the absence of kiss. Since the player isn't Schrodinger's cat, he can't have both kissed and not kissed the girl at the same time. Therefore, the value of one imply the value of the other.
Either he kissed the girl, and then if alexkiss will match, or he didn't, and it's if not alexkiss that will match. What lead to:

#  By default the player haven't kissed the girl. This permit to have a route
# where the choice isn't presented to the player.
default alexkiss = False

label whatever:
    menu:
        "kiss the girl":
            $ alexkiss = True
            [...]
        "I never seen Disney's little mermaid":
            # Nothing to change, the default value is "haven't kissed the girl".
            [...]

label somewhereElse:
    if not alexkiss:
        bestFriend "Are you idiot ? She was waiting for a kiss !"

This approach is better for many reasons:

• It's cleaner ;
• There's less code to write, therefore less risk of error ;
• There's only one variable to handle what is one choice ;
• Handling the choice with a single variable mean more constancy in the code ;
  There will not be cases where you test if alexkiss then cases where you test if alexnokiss, before the test turn into if not alexkiss or, the worse, if not alexnokiss.
• Twice less variables also mean twice less variable names and meaning to remember.

 

[Vollezar]

This is not doing it properly.

The variable MUST exist before the choice is given to the player, this precisely in order to avoid all those possibilities of errors:

#  Can be /define/ in place of /default/, since it's boolean values it don't
# change much. But having the habit to use /default/ is better.
default alexkiss = False
default alexnokiss = False

label whatever:
    menu:
        "kiss the girl":
            # alexnokiss stay at False since the player choose to kiss
            $ alexkiss = True
            [...]
        "I never seen Disney's little mermaid":
            # alexkiss stay at False since the player choose to not kiss
            $ alexnokiss = True
            [...]

Now, this being said, like 79flavors implied about another issue in the code, this is relatively useless.
There's no need to have a flag for both the kiss and the absence of kiss. Since the player isn't Schrodinger's cat, he can't have both kissed and not kissed the girl at the same time. Therefore, the value of one imply the value of the other.
Either he kissed the girl, and then if alexkiss will match, or he didn't, and it's if not alexkiss that will match. What lead to:

#  By default the player haven't kissed the girl. This permit to have a route
# where the choice isn't presented to the player.
default alexkiss = False

label whatever:
    menu:
        "kiss the girl":
            $ alexkiss = True
            [...]
        "I never seen Disney's little mermaid":
            # Nothing to change, the default value is "haven't kissed the girl".
            [...]

label somewhereElse:
    if not alexkiss:
        bestFriend "Are you idiot ? She was waiting for a kiss !"

This approach is better for many reasons:

• It's cleaner ;
• There's less code to write, therefore less risk of error ;
• There's only one variable to handle what is one choice ;
• Handling the choice with a single variable mean more constancy in the code ;
  There will not be cases where you test if alexkiss then cases where you test if alexnokiss, before the test turn into if not alexkiss or, the worse, if not alexnokiss.
• Twice less variables also mean twice less variable names and meaning to remember.

Thank you.