A Question...

[Trachmyr]

I've been going over the tutorial and wracking my brain, but I can't figure something out. I wanted to ask if what I'm trying to do is even possible, if not then I need to decide an alternate method.

------------------------

I'd like to have 2 widgets appear on the screen while the Say Window is active... in fact I want them to always be on the screen when the say window is present. The Say window will be 640 x 150 pixels and be positioned in the lower left-hand corner of the screen (Screen 800 x 500)

The first widget will be a UI.Image... this is basicaly a health bar, but since it "fills" verticaly, I realize I can't use the bar widget. The bar only has 35 possible variations and are easy to track, so I've already made them in 35 different .jpg images. The "Bar" will be 10 X pixels by 150 Y pixels, and should lay flush against the Say window.

The second widget will likely be a UI.Imagebutton. This will use the last 150 X pixels of the bottom screen (and be 150 Y pixels high like the Say window and "Health Bar"). When Idle it should display one of 6 simple pictures denoting what time of day it is (i.e., sun rising for morning, moon midsky for night, etc.), ontop of the picture it will contain text of: Day of the Week, Day #, and Time of Day (i.e., Sunday - Day 8 - Evening). When hovered it will change to a 'button' with the text "Click for Character Status". When clicked it should allow the player to enter a different UI for Character Status... which will be a seperate screen with no need of the Say window.

Is what I'm trying to do even possible? If so can you give me an idea of how to go about it?


Thanks for listening!

Edit: There were actualy 2 questions here, but I figured out the first one so I removed it.

[PyTom]

Hm...

I think that what you're trying to do is going to be hard in the current verson of Ren'Py, as right now the text widget is greedy, and will consume all of the width it can, meaning that it's hard to put things to the right of it on the screen.

In the next version of Ren'Py, I'll probably add some style properties that let one control the width of widgets manually, and hopefully this will make it easier for you to layout widgets to the right of each other.

The second new feature that's coming soon is that I'm planning on routing all text and dialogue through either character objects or a similar, user-overridable, function. Right now, this happens with character dialogue, but the new feature will mean that it also occurs with thoughts as well.

I need to think about how to do the DoW, Day#, Time overlay... but worst comes to worse, we can precompute all those images. (Time for a little gimp-fu.)

This should make it much easier to do what you want. Your best bet is to focus on the story and game logic for now, and in a couple weeks come back to this, as the next release will make it much easier.

[Trachmyr]

Well, I actually succedded (As far as I can tell) to get the Say Window to behave properly:

$ config.screen_width = 800
$ config.screen_height = 600
$ style.window.background = Image("window.jpg")
$ style.window.xmargin = 0
$ style.window.xpadding = 11
$ style.window.xfill = 640
$ style.window.xminimum = 640
$ style.window.xanchor = 'left'
$ style.window.xpos = 0
$ style.window.ymargin = 0
$ style.window.ypadding = 14
$ style.window.yfill = 150
$ style.window.yminimum = 150
$ style.window.yanchor = 'top'
$ style.window.ypos = 450

Where Image.jpg is a non-tranparent image 640x150 in dimension.

What my main concern is, is that from what I can tell the process to call any widgets takes control from the Say Window and the normal flow of the game while the widget property waits for a value to be returned. What I need is for the code to be read as normal unless the widget is clicked.

I don't think the Day/Time widget will be too difficult to make, upon further consideration it will have to be a UI.Window/UI.Vbox that uses the appropriate image as a Background, then presents 4 child widgets... 3 text and one a text button... It's not so bad if the only compromise I need to make is that the "Status Screen" always appears as a button at the bottom of the box.

----------------------------------

Unfortunately, while it seems that concentrating on the dialog and pathing might be best for now, my mind doesn't really work that way. I need the "skeleton" or infrastructure before I'm comfortable fleshing it out.

I'll just do a bit more brainstorming... but if you think of a way to implement the widget behavior I need, please let me know...

Thanks again!

[PyTom]

What my main concern is, is that from what I can tell the process to call any widgets takes control from the Say Window and the normal flow of the game while the widget property waits for a value to be returned. What I need is for the code to be read as normal unless the widget is clicked.

I honestly don't know what you mean by this. Could you clarify, or perhaps provide an example of what you want/what you have?

[Trachmyr]

I'm sorry if that wasn't too clear...

Let me explain what I'm trying to incorporate from the player's perspective:

The game will be presented to the player in a "Letterbox" aspect, the letterbox being at the top portion of the screen. This is where all graphics will be dispalyed. The lower portion of the screen will include The Dialog Box at the Left-Hand corner (running 80% of the screen width), the Date/Time Box at the right-hand corner and a small Health Bar between them.

The game would then play as a normal Interactive Novel... dialog & menus appearing in the Say Window, and time/date being adjusted as appropriate in the Date/Time window. However, if the player clicks on the Date/Time window (or a button located within it), the player is then taken to a completely seperate UI screen (A character Status screen).

From the code I looked at in the Demo Game, it appears that you can't have the Say Window active at the same time you have other widgets on screen. The widgets appear to be a seperate subroutine that keeps control of the execution of the code until the player interacts with it and thus the game returns to the point at which the widgets were called.

Perhaps I simply reading too much into the way the Ren'Py Demo was designed.

[PyTom]

If I get you correctly, it's that you want a button that, when clicked, brings up a stats screen. Then you want to be able to return to your game when the user clicks dismiss from the stats screen.

You want to use renpy.call_in_new_context(). This saves the current state of the game and calls a label. Unlike the call statement, call_in_new_context also saves the screen and music. If you save when you're in a new context, you restore back to the old context. (So in your case, if the user saves while in the stats screen, he will restore to the normal screen.)

Anyway, here's some code that does this using a simple textbutton. Season and flavor to taste:

Code: Select all

init:
  python:
    def call_stats():
        renpy.call_in_new_context('stats_screen')

    def display_hud():
        if show_hud:
            ui.textbutton('Show Stats', clicked=call_stats)
        return [ ]

     show_hud = True

    config.overlay_functions.append(display_hud)

label stats_screen:
    scene black

    $ show_hud = False

    "Here is the code that displays the stats screen."

    $ show_hud = True

    return

I haven't tested this code, but it should be fairly close.

[Trachmyr]

I appreciate that snippet of code very much...

Not only are you saving me from adding in a "save-related" bug... but you've illustrated to me what I've been doing wrong.

I didn't notice in the example code that the function need only be defined in an init statement. I also didn't realize that you could tie in a variable (i.e., show_hud) and simply turn the overlays/widgets on & off by simply updating the variable when needed.

Thank you oh so much!

Edit: One problem though, by clicking on the button it also advances the Say script foward to the next logical line. So when you return you're actually one line further into the story. Is there anyway to avoid this? I really am sorry for bugging you so much.

[PyTom]

You caught a bug in Ren'Py. I haven't really played around much with buttons that return to the same interaction, so I didn't catch it.

The bug was that Ren'Py failed, in some cases, to suppress an event that was consumed by a button. So the say behavior would get it when the call_in_new_context exited... and it would advance to the next line.

It'll be fixed in 4.4.2 (probably coming out this weekend). There isn't really a good workaround for this, so you'll just have to live with it until then.

The good news is that fixing this clears the way to having on-screen buttons call up the save, load, and preferences screens. So that's probably a good thing. (The game menu stuff is really just calling a special label in a new context.)