I have. Children are a bit far, but they stay in touch with me, as well as my boss and co-workers. One of the junior is even unwittingly funny, trying to making me feel better by showing that he take seriously the fact that he's now responsible for the tests writing, while doing his best to not make me feel useless. To summarize, each time we talk it looks like, "you see, we can still works at 100% without you... this doesn't mean that I took your place, we have to be at 200%... but not you, you need to take it easy... not that you're old..."
He probably play a big part in the fact that I take all this not so badly
There's no "best" here, it all depend on the context.
It's like for transportation devices. What is "best" ? A sport car ? A family car ? A bicycle ? If you want to impress girls, the first is the answer. But if what you want is just buy some bread, the last one would be way better. And for a holiday trip with you wife, two kids and pets, there will be nothing better than the second.
Yes, but it's "if the dev makes major changes". If he don't, what will be the cases for most of the code, in most of the updates, you'll have nothing to do.
This being opposed to a more invasive way to mod, that would need that you copy/past your changes every time there's an update. So, in the end, even if there's changes time to time, it would still be easier and faster to rely on label overrides.
Totally agree.
But label overrides can help you organize all this.
/!\ wrote on the fly, with a half working brain /!\
Python:
# What apply to "start" label.
default linesOverrided = { [...] }
init python:
config.label_overrides["label1"] = "label1_modded"
config.label_overrides["label1_OUT"] = "label1"
label label1_modded:
# What apply to "label1" label.
$ linesOverrided = { [...] }
jump label1_OUT
side note:
So far, Ren'Py do not validate the content of
config.label_overrides. Therefore you can use label that do not exist at all, like the "label1_OUT" in my example. Ren'Py will find it in
config.label_overrides, change the name of the label accordingly, and like it's an existing label, will branch to it.
With this, you don't hijack the game flow, but hook in top of the label. Ren'Py flow become this:
- [previous label]
- label1_modded
- label1
And doing so, if a line have change in whatever label, you know precisely where to find it in your own code, it will be in the same label with the "_modded" suffix.
This also permit to keep
linesOverrided as small as possible. Strictly speaking it don't impact the performances, but it's always a good practice to have as less data as possible.
Hmm... there's many way for devs to do this, but for modders, if it rely on jump, there's an easy way to fix this.
Let's say that you've this as original code:
Python:
label whatever:
[...]
menu:
"pass the night with Anna.":
jump anna_night
"Go to the coffeeshop to flirt with the barista."
jump coffeeshop
"Meet Sarah in the park."
jump sarah_park
label anna_night:
[...]
jump next_scene
label coffeeshop:
[...]
jump next_scene
label sarah_park:
[...]
jump next_scene
label next_scene:
[...]
What you can do is something like:
/!\ wrote on the fly, with a half working brain /!\
Python:
# intentionally left blank.
default labelsStates = {}
init python:
config.label_overrides["next_scene"] = "next_scene_hub"
config.label_overrides["next_scene_OUT"] = "next_scene"
label next_scene_hub:
# You never been there yet.
# This mean that you come from "anna_night" label, jump to the second scene.
if not "next_scene" in labelStates:
$ labelStates["next_scene"] = 1
[Place here the variables changes that possibly happen in the menu]
jump coffeeshop
# You've been there before, but only once. Time to jump to the third scene.
elif labelStates["next_scene"] = 1
$ labelStates["next_scene"] = 2
[Place here the variables changes that possibly happen in the menu]
jump sarah_park
# You've seen all the scenes, time to get back to the normal flow.
else:
jump next_scene_OUT
It will not apply to every games, because it need for each scene to have its own label. But when it's the case, then it will works all the time, whatever how many changes there's in each label.
You only have to ensure that the variables changes haven't been updated, and that the name of the label they all branch to is still the same.
As for games where the scenes are directly embedded in the menu, there's still something you can do to limits your work.
The game will looks like this:
Python:
label whatever:
[...]
menu:
"pass the night with Anna.":
[the scene]
"Go to the coffeeshop to flirt with the barista."
[the scene]
"Meet Sarah in the park."
[the scene]
[...]
You'll have to do two things. Firstly a small update in the original code:
/!\ wrote on the fly, with a half working brain /!\
Python:
label whatever:
[...]
# Add an implicit jump to make label overrides possible.
# I used a sub label (the leading dot), but it's not mandatory.
jump .selectionMenu
# Explicitly give a label to the menu, once again to make label overrides possible.
menu .selectionMenu:
"pass the night with Anna.":
[the scene]
"Go to the coffeeshop to flirt with the barista."
[the scene]
"Meet Sarah in the park."
[the scene]
# Give a label to the following common part, because you need to find your way back.
# Once again I used a sub label, but it's not mandatory.
label .continue
[...]
Then your mod will looks like:
/!\ wrote on the fly, with a half working brain /!\
Python:
init python:
config.label_overrides["whatever.selectionMenu"] = whatever_modded
label whatever_modded:
[scene with Anna]
[scene with the barista]
[scene with Sarah]
# Return to the common flow
jump whatever.continue
You'll still have changes to make on the original code with every updates, but it's small changes that will apply whatever have changed in the said original code. As long as the dev do not totally remove the menu, it will works.
You'll still have to update your code if he change something in one of the three scenes, but that's all you'll have to do. As long as the changes happen outside of those three scenes, it will not matters because the modded version use the original code for this.
Oh god, what I love thinking about code... A chance it was still something basic, it needed more time that I thought, but yeah, what a pleasant feeling that thinking and still being fine right after it.
Thanks a lot, seriously.
