[Feature Request] Setup python block within screen
Posted: Mon Nov 03, 2014 3:34 am
Hi there,
sometimes I would like to have some code to run before a screen is shown. Consider the following example:
As the $ lines is computed when the screen is already shown, this isn't a particular good idea to use this code fragment as you all know. Using default on the other hand is something which is computed before the actual screen is shown and works like intended:
Unfortunately this very keyword only works with assignments and is therefore pretty limited in its use. Think about something more advanced like this:
Can't we introduce a whole block of code that is computed as kind of constructor of every screen? Something like:
Of course you can always use stuff like generators to avoid those blocks here, but there may be some advanced code techniques out there which need a whole block to run before a screen gets shown. Think about apps which will first send HTTP requests to some kind of backend before presenting the results within the screen.
To me it looks like the fundamental idea of this is already implemented by the default keyword, but is limited to assignments (which can be a pain to when it comes to advanced techniques). I know that you can always work around this problem by calling a label which than calls the screen after the python expression are evaluated, but for me this isn't a nice thing to do. If you're code belongs to a screen it should be in the screen and not require additional constructs like labels to run.
You could argue the same when it comes to a destructor as those may also be helpful (e.g. for closing an HTTP connection if the screen is closed).
So that's it basically. Tell me your view on this issue
sometimes I would like to have some code to run before a screen is shown. Consider the following example:
Code: Select all
screen foo:
$ text-color = renpy.random.choice(['FFFFFF','000000'])
text "Foobar" color text-color align(0.5,0.5)
...
Code: Select all
screen foo:
default text-color = renpy.random.choice(['FFFFFF','000000'])
text "Foobar" color text-color align(0.5,0.5)
...
Code: Select all
screen foo:
default colors = ['FFFFFF','000000','C0C0C0']
default text-color1 = renpy.random.choice(colors)
default text-color2 = renpy.random.choice([ c for c in colors if c != text-color1 ]) # take another color which is NOT text-color1
text "Foobar" color text-color1 align(0.5,0.5)
text "Barfoo" color text-color2 align(0.2,0.2)
...
Code: Select all
screen foo:
python <constructor/init-screen/enter/whatever>:
colors = ['FFFFFF','000000','C0C0C0']
text-color1 = renpy.random.choice(colors)
colors.remove(text-color1)
text-color2 = renpy.random.choice(colors)
text "Foobar" color text-color1 align(0.5,0.5)
text "Barfoo" color text-color2 align(0.2,0.2)
To me it looks like the fundamental idea of this is already implemented by the default keyword, but is limited to assignments (which can be a pain to when it comes to advanced techniques). I know that you can always work around this problem by calling a label which than calls the screen after the python expression are evaluated, but for me this isn't a nice thing to do. If you're code belongs to a screen it should be in the screen and not require additional constructs like labels to run.
You could argue the same when it comes to a destructor as those may also be helpful (e.g. for closing an HTTP connection if the screen is closed).
So that's it basically. Tell me your view on this issue
