A perplexing issue . . .

#1 Kevin,
I've done something similar to create an in game dialog system. I pause the game and then display the talking character's portrait and text using a new scenegraph. Here's an outline of what to do:

1.) Create a new gui that has t2dSceneWindow control called "sceneWindowDialog" (or whatever is appropriate to your project).

2.) Create a new scenegraph using one of two methods:
a.) Create load a level file

$dialogSceneGraph = "game/data/levels/dialog.t2d";
   
   if( isFile( %dialogLevel ) || isFile( %dialogLevel @ ".dso"))
   {      
      %this.dialogSceneGraph = sceneWindowDialog.loadLevel(%dialogLevel); 
      dialogManager.hideDialog();
   }

b.) Create the scenegraph in script:

$dialogSceneGraph = new t2dSceneGraph() {};
    sceneWindowDialog.setSceneGraph($dialogSceneGraph);

3.) When you pause the game, add sceneWindowDialog:

mainScreenGui.add(dialogGuiControl);

4.) Likewise, when you unpause the game, remove it:

mainScreenGui.remove(dialogGuiControl);

5.) If you add new objects to the new scenegraph, be sure to set them to the proper scene -

new t2dSceneObject(foo)
   {
      scenegraph = $dialogSceneGraph;
      ...(other data)...
   };

Let me know if you have any questions and good luck!

Patrick

#2 Patrick,

Thanks a lot for your brilliant help! I honestly was expecting it to work pretty smoothly, but unfortunately I'm having some issues.

My biggest problem may be the fact that I must set $timescale to 0 in order to pause my game. Thus any schedule based functions are out the door. At this point, I'll be satisfied if the blasted thing just gets to be functional. So I can sacrifice my fade ins and fade outs.

I was able to create the GUI and add the scenegraph to it. The problem I'm having is that the player cannot click the buttons on the menu. I created a test button on the menu, but it is like mouse events are off - even though I enabled them both on the button itself and the new scenewindow it is in. (sceneWindowInGameMenu)

If I was perplexed before - now I am completely bewildered. Your idea seemed fool proof!

#3 Argh!

Sometimes I think TGB plays games with my mind! I used:

function [insert button name]::onMouseDown(%par1, %par2, etc.)

Which worked with my Main Menu buttons, but now the only thing that works is:

function [insert button [i]class[/i]]::onMouseDown(%par1, %par2, etc.)

So in short, it works now!

Thanks so much for your help, Patrick!

#4 Kevin,
Great! I'm glad I could help.

#5 Do you think there is a way to set up different timescales for different scenegraphs? I have a really awesome ingame menu in mind, but the timescale's value of 0 during a game pause, eliminates any possibility of an aesthetic menu, due to the inability of schedules to progress, scrollers to scroll, etc.

If anyone has some thoughts, let me know! It definitely isn't a dire necessity; I'm over joyed because I have a functional in game menu at least!

#6 Kevin,
I don't know if you can have different timescales. Personally, I never use the "timescale" variable because I never use schedules for my scene objects. Scheduling is really easy to use and very powerful. However, I dislike tracking events to make sure they're all canceled when I load a new level or gui, and sometimes they're hard to debug (you can't put a break point in one and see how much time is left for example).

Instead, I manually create timers using the "onUpdate" callback, either in the object or the scenegraph. I use either a simple counter (prone to minor timing inconsistencies) or tracking current system time . I find that manual timers are more useful because they are easier to debug and easier to synchronize with other game events.

I even go so far as using my scenegraph's heartbeat to drive time based gui events. For example, in my dialog system, the text is displayed one character at a time and displays a flashing cursor at the end of the line. Although the text is part of the gui, the timing is driven by a behavior on my dialog scenegraph.

By placing the timers are part of scene graph, I don't have to worry about lurking schedules that need to be shut down when the level is loaded or paused I pop up a blocking dialog box.

Of course, this is my personal preference and others may have different views on this.

#7 Patrick,

Thanks so much for these suggestions! I'm definitely going to weigh the benefits and attempt to discern the possibilities of taking an approach like this for some of my code.

You're right in the fact that tracking schedules is very tedious and annoying and that canceling them when you load a new level is necessary. However, you can pause them easily, though if you pause one, apparently you pause them all; such is my dilemma.

Your method presents a solution, but I'm not really looking forward to changing a bunch of my core code. However, if it functions just as well - and is not bound by the $timescale - I'm willing to give it a try.

You should know that changing the $timescale allows you to slow down or speed up any and all actions in game. Its pretty sweet to have bullet time functionality in your game in under 10 minutes, lol.

Again, thanks!