RenPy beginner questions

[Lyka]

I'm ultra tired right now and tried to step it up a bit more to the way i need it in the end
but why am i thrown always right to the messed up label?

init:
 $ money = 0

label start:
    "YOUR IN THE START LABEL AND JUMPING TO THE INN"
    $ money += 1
    jump inn

label inn:
    call event_testing
    "YOU ARE IN LABEL INN"
    jump somewhere

label event_testing:
  if money == 1:
      return "eve_1"
  elif money == 2:
      return eve_2
  else:
       return

label eve_1:
    "YOUR NOW IN EVENT 1"
jump inn

label eve_2:
    "WRONG!! YOUR IN EVENT 2"
jump inn

label somewhere:
    "IF YOU SEE THIS YOU MESSED UP"

 

[Maid Lain]

but why am i thrown always right to the messed up label?

Fixed:

default money = 0

label start:
    $ money += 1
    jump inn

label inn:
    "YOU ARE IN LABEL INN"
    call event_testing
    if not _return == None:
        jump expression _return

    "Event_testing returned None."
    jump somewhere

label event_testing:
  if money == 1:
      return "eve_1"
  elif money == 2:
      return "eve_2"
  else:
       return None

label eve_1:
    "YOUR NOW IN EVENT 1"
    jump inn

label eve_2:
    "WRONG!! YOUR IN EVENT 2"
    jump inn

label somewhere:
    "IF YOU SEE THIS YOU MESSED UP"

 

[Lyka]

thank you, using smaller stuff shows errors really fast. going back and using a new project was the righte coice.
thanks!



can someone explain this with some simpler words, please?

Return Statement
The return statement pops the top statement off of the call stack, and transfers control to it. If the call stack is empty, the return statement restarts Ren'Py, returning control to the main menu.

If the optional expression is given to return, it is evaluated, and it's result is stored in the _return variable. This variable is dynamically scoped to each context.

 

[anne O'nymous]

can someone explain this with some simpler words, please?

Return Statement
The return statement pops the top statement off of the call stack, and transfers control to it. If the call stack is empty, the return statement restarts Ren'Py, returning control to the main menu.

If the optional expression is given to return, it is evaluated, and it's result is stored in the _return variable. This variable is dynamically scoped to each context.

• Ren'py use a 'stack' to keep track of where it was when a call happen. For this, it put something in the said 'stack". Then, when a return happen, Ren'py remove the last 'something' that was added, and return to the place designed by this 'something', then continue the game from here.
• If the 'stack' is empty, a return mean that the player reached the end of the game.
• If the return statement is followed by something, this 'something' will be put in the _return variable.
• The variable _return is (like) local to the current label. Its value in a label is not necessarily the same that its value in another label.

And like I'm a coder, so not this good at explaining code, here's a demonstration of all this :

Spoiler: demonstration

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

Note: Like the code is big, I also put it in the attached archive.

 

[Lyka]

your the best!!

interested in something different

if storyArc1 == 0 and day >= 7 and variablex>=10 and time == 0 and "label park"

what do i need to add that it triggers only if i go to the park at day >=7....?

 

[anne O'nymous]

if storyArc1 == 0 and day >= 7 and variablex>=10 and time == 0 and "label park"

what do i need to add that it triggers only if i go to the park at day >=7....?

Not sure to understand your question, so pick the right answer

If what you want is "player go to the park, this event must be triggered if this and that", then it's in the park label that you must do it :

label park:
   if storyArc1 == 0 and day >= 7 and variablex >= 10:
       jump park_event1
   elif storyArc2 == 5 and day >= 20:
       call park_event2
       return

   [put here the default code for the park]

I used two triggers to show you how it can be done ; more specifically the fact that you must return (or jump somewhere else) after the call. Some people use this structure :

label park:
   if condition:
       jump somewhere
   elif condition:
      call somewhere
   else:
      default content

But I prefer the one I used because it limit the indentation of the main code. In the same time it mark clearly that it's what happen by default ; default being the most common occurrence. The rest (what in the if/elif/else structure) being the exception.

Putting the trigger here isn't the only solution, but it's the better one. It naturally split the events in two categories :

1. global events
   Those that happen because of a generic situation. By example "two day after you said that you love her, she phone you".
2. local events
   Those that happen because the player entered a given location "at the right time". By example, when the player enter into the park at 10AM, he can see the pretty girl next door walking her dog... and when he finally have enough courage, he try to talk to her.

This separation between the two is clearly seen by the fact that the triggers aren't at all at the same place. In the same time, if you want to change a trigger for an event related to the park, or add a new event to the park, you know that you need to look at the start of the "park" label.



If what you want is "this event must be triggered if this and that, and it the player goes to the park at day 7", then it's in the main event label that you work, but you also need to make a little change in the "park" label :

default parkDay7 = False

label mainEventTest:
   if storyArc1 == 0 and day >= 7 and variablex >= 10 and parkDay7 is True:
       jump park_event1
   [...]

label park:
   if day == 7:
       $ parkDay7 = True
  [...]

Here, you use a flag to keep track of the fact that the player was in the park at day 7. Then you use this flag to check if the condition are reach or not.
I used an equality as condition, but it works with any condition, even multiple ones.

 

[Lyka]

thanks to all this help i found the perfect solution for me.

 

[anne O'nymous]

thanks to all this help i found the perfect solution for me.

No problem. And sorry, I'm still not sure to have correctly understood what was your problem this time.