So I was coding some choices in Ren'Py and ran into some problems with label calls, options within options, and story paths.
I was getting unwanted label loops and label calls, and when choosing a path the other path's labels would show up at end of the current event flow.
Solved that problem when I moved all labels to a separate file meant for labels only, but I had to modify some of them to jump and follow the main game flow and return to a logical point in the main story.
My problem were mostly options within options and returning to a desired point in the current path or main story.
In your experience, what is the best way to map events and options flow? Do you use something like a flowchart?
label start:
menu:
"option 1":
call option1
"option 2":
call option2
"But, why will I end in 'option1' again ?"
label option1:
"Yeah, I'm in 'option1'."
"That's exactly where I wanted to be."
label option2:
"but why do I see this ?"
"I should magically return somewhere."
"at the end of the label 'option1'."
"It's magic, where will I end now ?"
Labels aren't closed entities, and Ren'py don't come with a divination feature. If you don't tell Ren'py where it need to go, he will just continue linearly until he found a statement giving it the direction to follow, or reach the end of the file and do some voodoo magic.
What do you mean by "returning to a desired point" ? You can only return right after the line where the label was called ; and you'll never return somewhere else. Which lead to the next question, "how do you get out of this point ?"
There isn't a "best way", there's just "good way for this kind of situation". And it's hard to give you an advice without knowing what you effectively expect, nor what was exactly your previous problem.
label start:
menu:
"option 1":
call option1
"option 2":
call option2
"But, why will I end in 'option1' again ?"
label option1:
"Yeah, I'm in 'option1'."
"That's exactly where I wanted to be."
label option2:
"but why do I see this ?"
"I should magically return somewhere."
"at the end of the label 'option1'."
"It's magic, where will I end now ?"
Labels aren't closed entities, and Ren'py don't come with a divination feature. If you don't tell Ren'py where it need to go, he will just continue linearly until he found a statement giving it the direction to follow, or reach the end of the file and do some voodoo magic.
What do you mean by "returning to a desired point" ? You can only return right after the line where the label was called ; and you'll never return somewhere else. Which lead to the next question, "how do you get out of this point ?"
There isn't a "best way", there's just "good way for this kind of situation". And it's hard to give you an advice without knowing what you effectively expect, nor what was exactly your previous problem.
Beep. Wrong answer. You have absolutely no necessity to end a label with a return, nor to jump out of them. In this case, like I already said, Ren'py will just implicitly jump to the label (or not) defined right after the actual line.
When you don't understand what I wrote, just say it. I know that my English isn't this good, I'll not be offended. Whatever in how many place you'll define a return point from your label, you will always return to the same point.
Your response seems like some weird way to vent off your frustrations.
If you don't know then don't bother ranting your ignorance and assumptions.
Calm down, I would be sad to know that some old man had an stroke because of a simple question I made...
...well not really, I would actually laugh about it but anyway...
Just to educate you:
Labels are closed entities, you end them with "return"
Labels can call another label, or jump to another label, they don't "only return right after the line where the label was called"; have you ever heard about multiple endings?
When one of multiple endings (labels) is selected the game doesn't "only return right after the line where the label was called"... the game ends genius...
I don't know why you ask for help if you know so much
Now seriously, I don't know why you've taken @anne O'nymous's answer so badly, she/he is trying to help you, assuming what your problem might be since you haven't put any code to refer to.
By the way, she/he is one of the best programmers I've seen around here, and always willing to help, so it would be nice to show a little more respect... as you've seen, even with your aggressive response, she/he doesn't respond in the same way and keeps trying to help
I don't know why you ask for help if you know so much
Now seriously, I don't know why you've taken @anne O'nymous's answer so badly, she/he is trying to help you, assuming what your problem might be since you haven't put any code to refer to.
By the way, she/he is one of the best programmers I've seen around here, and always willing to help, so it would be nice to show a little more respect... as you've seen, even with your aggressive response, she/he doesn't respond in the same way and keeps trying to help
And then goes and says that "You can only return right after the line where the label was called ; and you'll never return somewhere else."
And even keeps going on about it... like in every single case labels have to jump back right before they were called...
...say the opposite. So, perhaps explain clearly your problem, or provide example of the code. But blaming other for your own fault will led you nowhere.
Or is it you that can't understand that part of my answer ?
I mean, you read the opposite of what I wrote regarding the divination, didn't understood the slang talk, still haven't understood the sentence regarding the return point, and don't see what your description of parts of your problem mean. So, There's chances that you also missed my point here.
With nothing shown, what you said above indicates that you don't fully understand how Ren'py's game flow works. Those problems don't show up without you making an error somewhere.
I think you've taken great offense to a slightly tongue in cheek answer, as someone tried to guess what kind of error you may have made without you showing us an example of your issue...
Mapping out the game flow in another program won't help you stop making the same mistakes, if you don't learn what mistakes you were making.
As @anne O'nymous already said this is 100% false, if you don't end a label with some sort of jump, call, or return: you will never receive a word of complaint from Ren'py... it will just keep going to the next line directly beneath it.
But if you won't believe me that you made a mistake, fine my recommendation for keeping track of game flow is Twine
You can't even get the offensive tone of his comment or you're just kissing up.
Either of those is lame...
So this duck is implying that I must think that ren'py comes with a "divination feature" and I must think is "voodoo magic".
And then goes and says that "You can only return right after the line where the label was called ; and you'll never return somewhere else."
And even keeps going on about it... like in every single case labels have to jump back right before they were called...
First he fails to understand that label calls and jumps are not the problem, and can't even get what "In your experience, what is the best way to map events and options flow? Do you use something like a flowchart?" means.
Gomez, get a clue before requesting respect, you're just making yourself look like a professional licker.
I think that by not having written the code that gives you problems, he has had to imagine it, and has started with the basics where many can be confused, but I don't see any derogatory or mocking; in any case keep in mind that sometimes it isn't the same to speak than to write and that when reading something written you can give it a tone that wasn't what he wanted to express in writing (apart from possible problems in translation as could be in my case )
I'm not going to get into discussions about how labels work in renpy, I haven't used it for so long and I don't consider myself an expert, but I always try to learn and help.
I'm sure that if you write the part of the code that gives you problems and describe what happens to you someone will give you the solution
As for "the best way to do it", with your permission, I think you are also wrong, since it's very common that there are several ways to achieve the same thing, and the "best" way to do it doesn't have to be one or the other, but the one that is more practical, flexible, easy for you, etc.
PS: I don't think being friendly and respectful is synonymous with professional licker, but well, if you think so, at least it's good to know that I'm considered professional in something
Is there a specific reason you're using call?
In my experience with RenPy, it's generally not something that's needed. Most (1st) games usually are fine with just jump statements only.
Don't get me wrong, call has it's uses. But due to the nature of how most devs end up coding their first game, it tends not to be needed at all.
You've said about moving all the labels (and associated code) to a separate file, tweaking a bit and then it works.
Let me start by saying that the "tweaking" is what fixed it (assuming it is fixed)... RenPy makes no distinction about if you use one file or two dozen. The filenames don't matter. Just the structure of the code within the source. Because using different files doesn't actually matter to RenPy... I've got to guess that putting it in a separate file only causes you to look at your code in a different way... that second glance is where your fix really lay.
Okay... RenPy branching 101:
jump is "go somewhere, never come back". Control passes to wherever you've told it to jump to.
call is "go somewhere, come back if you ever encounter a return statement". Control passes to wherever you've told it to "call" and behaves just like a jump... unless it runs into a return statement - in which case control passes back to wherever the call was made from.
The RenPy build process includes an option to add from to the call statement. This is just a way for RenPy to keep track of things when you save game. Essentially if you ended up changing your code after a player has already been playing it... from gives RenPy a fighting chance of not screwing everything up. I'm sure some very clever people can think of reasons to mess with that... but for the rest of us... you should probably always let RenPy take care of that for you.
Every time you use call, it adds the current program location to what I think of as a call stack. Every time it runs into a return, it pulls the latest entry off the call stack and goes there. It's the reason you can put calls within calls and create all sorts of levels of complexity. It's also the reason why not including a return statement where you planned to can lead to all sort of really bizarre shit happening that's really difficult to keep straight in your head. Not least, because the last thing RenPy does as you finish your game is return to the core RenPy code... Anything left outstanding on the call stack... and things will get more than a little confusing.
You might want to use call for something like "add 1 to person-x's lust variable"... where the bit of code not only added 1 to the variable, but also does a small animation on the screen... or something like that. But in my experience, call causes more problems than it solves for people who don't come from a programming background. Initially at least. Whereas people rarely go wrong with jump.
I've used it for "figure out the various clothing combinations" during a truth or dare mini game. It has it's uses. But if you can use jump , use jump.
On top of all that, there's RenPy's indentation.
Anything with the same level of indentation is executed in sequence. Good practice says that 4 spaces is what to use. It can be 1, but that will just drive you nuts when trying to read it.
TL;DR? - Use jump. Forget all about call. If you absolutely insist you need to use call, make sure there's a corresponding return statement.
Obviously, we're all guessing about the problems you are running it to. If you have some specific code... that would make diagnosing the problems you're having so much easier.
What is weird is how you don't question yourself a single second, despite the fact that everybody that answered you understood your question more or less in the same way.
The question was not about coding, it was... "In YOUR EXPERIENCE", what is the best way to keep track of your game flow? What do you use to map the game flow? Do you use something like a flowchart?.
Title of the thread : "nested options label calls and game flow"
Content of OP : 9 lines talking about your problem with label calls and jump, 2 lines talking about game flow.
