Ren'Py from tag

[User_286102]

Hi friends

Since today, tags from appear after all the call tags
why this tag from..... appears in my script and why it wasn't there before?
and on it's from there are numbers after sevpark and tituatu
what are these numbers?

menu:
            "Join Jimena":
                $ elpicheer += 1
                call cheerleaders from _call_cheerleaders
            "Go to calladoran":
                $ elpiworkbar += 1
                call workbar from _call_workbar
            "Go to the park":
                call sevpark from _call_sevpark_6
            "Walk in the city":
                call tituatu from _call_tituatu_7

 

[drKlauz]

RenPy (optionally) add these during build to maintain save compatibility.
Without from clauses if you change sources and load old game it will crash on first "return" statement.
You probably only want to add these when you done with development. But if there is no official modding support it is safe to not add these at all.

 

[User_286102]

Okay, they're only for the save, so...
I keep creating the game without worrying about that?

and in the files game a i've new files named .rpy.bak
it's also for the saves?

 

[anne O'nymous]

Okay, they're only for the save, so...
I keep creating the game without worrying about that?

You keep creating the game, ensuring that the from are correctly added. Assuring the compatibility between your game's updates, and the save files made from a previous update, isn't some optional secondary task.

and in the files game a i've new files named .rpy.bak
it's also for the saves?

It's nothing related to Ren'py. The

You must be registered to see the links

extension is the backup of the file made by the text editor you used.

 

[drKlauz]

While i somewhat agree, sometimes it is best to drop legacy support. Especially when you working on alpha/early beta game, if half of game changed on update why spend time to maintain compatibility when you can spend it adding actual content?
Also from clauses visually clutter code.

 

[User_286102]

it's best to drop legacy support, can you tell me how I can do that?

 

[drKlauz]

From clauses get added when you build project thru RenPy launcher. There will be "Add from clauses to calls" option. It is "ON" by default. I don't think there is any automatic way to remove them. I got them added couple of times before, simple reverted to earlier sources. Use github or similar for version control, will help you _alot_ in some cases.
And probably if you don't know why it is there and how it works, you should follow Anon advice.

 

[User_286102]

Yes, I will follow anon's instructions. "even if I don't understand much about it."

I don't understand anything you're telling me
the "from" are my choices..., if I create the next version with my choices then the players will no longer have their choices but mine in their game... i don't understand...

I don't understand anything and I think I still have a lot to learn and that this is only the beginning of my misfortune
I'm going to work like this and I'll see...

 

[79flavors]

Imagine you're loading a save game in the middle of your sevpark call...
RenPy starts up... does it's usual voodoo about figuring out where the game was up to when it was saved... and then goes to a point in the middle of the sevpark code.
When it hits a return it needs to figure out where to return to. Since you might have multiple call sevpark's in your game - RenPy might get confused (probably not)... especially if you're reworked your code a fair amount between releases/chapters.

So to make it easier, the build process adds in the from {blahblah} to the end of the call. Now RenPy explicitly knows which of the calls was used to get there... so less chance of getting confused.

• Letting the build process add the from is a good idea.
• Don't try to adding any froms yourself - even if there's some already in the code (RenPy is better at it, and doesn't make typos).
• Don't remove any after they've been added (Next time you build, the numbering might end up different... so the save games will get borked).

Obviously it doesn't work exactly how I've described it, but it's close enough for figuring out this sort of stuff.

 

[drKlauz]

It is not about choices or game play at all.

When you use "call some_label" RenPy store next line location in call stack, then jump to target label ("some_label" in this case). When RenPy hit "return" statement it pop return address from call stack and jump there.
Without "from _another_label2" thing, RenPy generate some digital id (not visible in code) for each call statement. But if you change sources these digital id get regenerated, as result if you load save from older version call stack get screwed and game crashes. To avoid this RenPy add "from xxx" to all call statements. This way RenPy have stable return label in call stack and can survive code changes.
It is technical hack to avoid problem with how RenPy store code nodes internally.

All things considered, develop game, when you ready for public release, build with "Add from clauses" - ON. Keep "from" in sources, add more content, again build with "Add from clauses" - ON.

 

[User_286102]

Yes, thank you, now I understand.

As you say, Dr. Klauz, I thought it was the choices, but it depends on the saves.
if the players leave while in a "call" they will return in the same "call" with tthe name given by the "from".
that's very good.

thanks to all for the clarifications.

now I suppose that if I modify something in the script of a previous version it is better to build without the "from" clauses
and warn players that the save dcon't work.

I now understand why there are so many save problems in games on F95 and I would now be more forgiving with devs who having problems like this.

 

[User_286102]

Obviously it doesn't work exactly how I've described it, but it's close enough for figuring out this sort of stuff.

I confirm... for a beginner like me it's very well explain.

 

[anne O'nymous]

Imagine you're loading a save game in the middle of your sevpark call...

And for a more visual explanation :

You have this code in your game, and the player load the game somewhere in the called label :

label whatever:

    scene thisPose
    "blabla"
    call thisLabel
    "Return here"
    [...]

When Ren'py will return from the "thisLabel" label, it will display the "Return here" dialog line.

Now, in one of your update, you'll change the code like this :

label whatever:

    scene thisPose
    "blabla"
    "blibli"
    "bloblo"
    call thisLabel
    "Return here"
    [...]

Due to the way Ren'py handle return points, it will still return to the "Return here" dialog line.

But if you change the code like this (still with a game loaded inside the called label):

label whatever:

    scene thisPose
    "blabla"
    call thisLabel
    "You return here"
    [...]

Now, Ren'py will not know where to return. For him, the return point is a dialog line "Return here" in a label named "whatever". Like it don't find the dialog line, but still find the label, it will return to the start of the said label.


But if you have the from option, like here :

label whatever:

    scene thisPose
    "blabla"
    call thisLabel from whatever_1
    "Return here"
    [...]

It will create a virtual label name "whatever_1", just after the line with the call statement. And it's this virtual label that will be used as return point.
This mean that you can to this change :

label whatever:

    scene thisPose
    "blabla"
    call thisLabel from whatever_1
    "You return here"
    [...]

Like Ren'py don't use anymore the following dialog line, and like the "whatever_1" label still exist, Ren'py will return at the right point, and not at the start of the "whatever" label like in my previous example.

As you can see, there's always security (if the line where Ren'py should return don't exist anymore, it can use the name of the label where this line is), but it's just a security. Depending of the changes you do, it can works or not.
By using the from option, you define a more precise return point, one that effectively depend of the call instruction and not anymore of the following line ; which offer you more liberty to change the code between two updates.