Label calls in code suddenly changed possibly after buildi??

[SuperbowserX]

I was preparing a copy paste of some code from the beta version of my game that I finished and hadn't reviewed the code of in two weeks. While I was doing so, looking at the code for the first time, I noticed something strange. My label calls were abruptly and mysteriously altered.

I had this label declared in my script:

Code: Select all

label check:
        play sound "SFX/check.wav"
        return

It's there because I prefer writing "call check" over that play sound string since this was a very common label call.

I was surprised that I started seeing "call check" replaced with things like "call check from _call_check_3", and other things like "call faceleft from _call_faceleft_8" for a similar "faceleft" label.

Just want to get some clarification because I was legitimately surprised to see all that. Is this kind of mass code replacement normal/expected behavior for build distribution? I checked both my distribution and the code in the Ren'py launcher and they both have these changes, but the pre-distribution backups I have don't.

Is it normal for Ren'py to make these changes to your code automatically for label calls when you build a distribution? If not, can someone explain to me what's going on here?

And more importantly, when I make the next chapter, can I still just use the typical "call check"? Will it just automatically "fix" it once the next distribution is built? Or must I start going by this incrementing number convention?

One other thing. Are .bak files important? I found them in my game's main folder (not the distribution the project folder). Why are there and can I remove them?

[Alex]

There's nothing wrong with your "calls" - that's how things work. You can put from clauses manually or let Ren'Py make it for you automaticaly. https://www.renpy.org/doc/html/label.ht ... -statement

As for different files in game folder, Ren'Py creates some files (.rpyc, .rpyb, .bak) based on your .rpy files for its own use. This files will be recreated each time you make changes in your script. So you can delete them. Note: do not delete .rpy files - this is the script files you've created.

[xavimat]

As far as I understand it, "from" clauses are only used if you change the script and want to open a save that has been saved with an older version of the game. In any case, they are optional, and the "build distributions" screen in the Ren'Py launcher allows you to turn off the automatic from clauses:
Here the text of the doc, linked by Alex:

If the optional from clause is present, it has the effect of including a label statement with the given name as the statement immediately following the call statement. An explicit label helps to ensure that saved games with return stacks can return to the proper place when loaded on a changed script.

[PyTom]

In general, you should not delete .rpyc files. They are updated automatically, and include information that is used to help Ren'Py figure out how to load a game. If you delete the file, Ren'Py might have problems loading.

[SuperbowserX]

For anyone looking at this in the future, if you want to undo this (like me) for readability, then what you want to do with regex in your text editor is do a find-and-replace. Replace, with regex enabled (this works for me in Atom): " from _.*" with a blank line. The .* in there basically tells regex "everything in this line after the preceeding phrase" (which is the " from _"). This will work for it all.

Also, if someone could remind me, what exactly is the purpose of the from clause? It makes my code look uglier to me. What does it functionally do?

[gas]

There's a "call" stack, and the "from" identify that call in the stack.

[PyTom]

And more importantly, when I make the next chapter, can I still just use the typical "call check"? Will it just automatically "fix" it once the next distribution is built? Or must I start going by this incrementing number convention?

Yes, you can. Ren'Py will annotate each "call check" with a unique from line, which helps Ren'Py to get back if someone deletes the next line.

One other thing. Are .bak files important? I found them in my game's main folder (not the distribution the project folder). Why are there and can I remove them?

They're created when Ren'Py edits a file. You can delete them or ignore them, once the game is shown to work.

[SuperbowserX]

What are stacks in Ren'py? And why do I need these "from" identifiers in there? Functionally what do they do as opposed to just the typical, no-from call method?

[PyTom]

A stack is a pretty standard computer data structure - it's what we call something that's LIFO, last-in, first-out. In this case, the stack is a stack of return locations. When we make call, we take the name of the next statement, and push it onto a stack. The return statement pops the return location from the top of the stack, and jumps to it. When we have code like this:

Code: Select all

"Dialogue line 1."
call mylabel
"Dialogue line 2."
"Dialogue line 3."

The three dialogue lines are given arbitrary names, of the form ("script.rpy", 1487831453, 4). When the script changes, Ren'Py does its best to give lines the same name, but sometimes it can't. For example, in this change:

Code: Select all

"Dialogue line 1."
call mylabel
"This isn't the second dialogue line."
"And neither is this."
"Dialogue line 3."

Ren'Py will give the two new dialogue lines new names, and the old name will cease to exist. If the game is saved inside the mylabel call, and then returns, Ren'Py will crash. But when a call is followed by a label:

Code: Select all

"Dialogue line 1."
call mylabel
label _call_mylabel__1:
"This isn't the second dialogue line."
"And neither is this."
"Dialogue line 3."

Ren'Py can always find that label even if the script changes. It's convenient enough I've created a tool that adds the labels automatically, and a special syntax for writing a call followed by a label:

Code: Select all

call mylabel from _call_mylabel__1

TL;DR: The from clauses on calls help your game keep working even if the script has been changed.