Messages

...
4. Two separate windows to click between for properties and events. Is this really necessary or just a gimmick. (I found I kept wondering where things had gone until I remembered I had to click one pane
   or the other.)

Things like these seem 'trivial' but can have a huge effect on workflow. I often do not have a mouse, but have to use a trackpad or touch screen and so this is a pretty big deal for me, too!

My question is, how far off is 3.4 official? Is it far enough away to consider suggestions for layout modifications and more keybinds for keyboard-centric developers? Or is the plan to push 3.4 out as soon as current features are ironed out?

After considering doing all that work, I went ahead and took the shortcut: I cheated, and chopped the background image in half: http://tinypic.com/view.php?pic=210ht7d&s=5
And I stuck the other half as the background image to the talking head GUI: http://tinypic.com/view.php?pic=10pztbl&s=5

Another way to do this would have been to put the background entirely on the GUI and just make the GUI bigger (since it's going BEHIND the dialog anyways...) but a simple cut and paste job was less effort than resizing/positioning the GUI.

Everything works fine now; they match up without any divide. My issue is solved now, everything works as expected with desired results. Thanks for lending your ideas and helping me keep on track!

Something occurred to me after reading your post and fiddling around with things for a while. Since dialog options always take you to the appropriate number in the dialog script, I could tuck a GUI visibility toggle in there.

Code: AGS

// Dialog script file
@S // Dialog startup entry point
return
@1
 g.Visible = false;
ME: It even works if you don't have dialog or use stop.
return
@2
 g.Visible = false;
stop

Was that pretty obvious or what? It also seems to work if tucked away inside of a custom function Speak(), as long as I make sure to call Speak() before any return or stop in dialog.

The only issue I have now is that the dialog drawing surface is on top of the animated button, obscuring it! Example here: http://i42.tinypic.com/2cmkpk1.png Is this just a z-ordering issue I can fix or is dialog always going to cover GUI elements?

I have my character speech set up to display on a GUI with a button. Using btn.Animate() I can show a view loop of a talking head alongside the characters text. I would like a similar display for when dialog options are presented. My dialog options are set to display on a drawing surface using the technique in the wiki.

Since dialog_options_render() uses a drawing surface to display it's text, I did some research into drawing surfaces. So far I have found no clear way to create a looping display of sprites. From my understanding, I would be using info.Surface.DrawImage() to place one frame of the talking head on the surface, then I would have to use info.Surface.Release() for it to actually display the sprite, and then redraw and re-release it again and again to create the animation effect, which would not tie in well with info.Surface, since the game releases it at a very specific time.

The second thing I tried is having a GUI with a button (as with speech), and placing g.Visible = true; btn.Animate() inside of dialog_options_get_dimensions(). That miraculously worked to display the talking head, only now I can't make it disappear! If only there was a way to hook g.Visible = false into the mouse clicking on a dialog option. Or if I could keep track of whether the player is not on a dialog options screen and have repeatedly_execute() turn g.Visible off.

If anyone has any information on how to proceed, I would be very grateful. Perhaps I missed some information to do with drawing surfaces, or there's a simple way to detect when I leave a dialog options display. Or  is there an even more obvious thing I missed from the very beginning?