Since you pass a lot of data around, let's use an object to store it in.
Code: Select all
init python:
class ScreenData(object):
def __init__(self):
self.map = "geographic"
screen viewport1(data):
viewport id "vp":
style_group "actual_map"
edgescroll (100, 200)
xmaximum 1055
ymaximum 768
draggable False
mousewheel True
child_size (2000, 1777)
add (data.map + ".png")
screen map1toggle(data):
hbox:
xalign 0.65
yalign 0.9
textbutton _("{b}GEOGRAPHIC{/b}") action SetField(data, "map", "geographic")
null width 10
textbutton _("{b}POLITICAL{/b}") action SetField(data, "map", "political")
screen mapchoice1(data):
add "gui/unit_selection_background.png"
use viewport1(data)
use map1toggle(data)
label start:
$ data = ScreenData()
"Where do you want to go?"
$ _rollback = False
call screen mapchoice1(data)
$ _rollback = True
The object provides a nice namespace that lets you easily pass data around from one part of the game to another. SetField lets you set fields on the object. The object's data is initialized by its __init__ method.
Some other notes:
"modal True" in the viewport1 screen doesn't do anything. Modal only works in the screen that's actually shown, which I assume is mapchoice1.
xalign 0.0 and style_group "actual_map" don't do anything where they are. They have to be applied to a displayable. I'm surprised this even compiles.
Unless I don't understand something, "tag menu" isn't necessary. It's used to have the various game-menu screens replace each other, which is unlikely to be what you want here.
screen mapchoice1():
$ config.rollback_enabled=False
Is something a horrible person would write. Config variables should not be changed outside of init blocks. It's doubly bad because python code in screens isn't allowed to have side effects, since such code can be run when a screen is predicted. The result is that you will disable rollback at completely random times - not what you want.
As some bonus advice, in my - untested - code, I wrote:
Code: Select all
$ data = ScreenData()
"Where do you want to go?"
# intentionally omitted as unimportant.
call screen mapchoice1(data)
This sets up the data for the screens a few statements in advance. This lets the prediction system understand the screen as it's about to be shown to the player, and gives its time to pull in any images required. If you did:
Code: Select all
"Where do you want to go?"
$ data = ScreenData()
call screen mapchoice1(data)
The more obvious approach, data wouldn't be defined in time for screen prediction to occur. (Ren'Py will still have a go at it, but the predicition will be a lot less accurate.)