Waiting or delaying an amount of time.

#1 For me, i plan on obtaining the system time, and using that for various delays

though i'm interested in hearing how scenePause works as per your question...

#2 Have you thought about using "schedule" for a specific function?

Sort of like:

function PauseAndSplash ( %dlgToShow )
{
   Canvas.pushDialog ( %dlgToShow );
   setScenePause ( true );
   schedule ( 20000, UnpauseAndContinue, %dlgToShow );
}

function UnpauseAndContinue ( %dlgToShow )
{
   setScenePause ( false );
   Canvas.popDialog ( %dlgToShow );
}

#3 @Jason
Unfortuantely, i wouldn't have a clue as to how to go about getting the time. That would be nice, though, I can thikn of lots of other things to do with the actual time.

@Scott
I wish I could use SVN from work, so I could see how it was I tried using schedule. I'm pretty certain though that I was trying to cram it into one function. I'll give your solution a try tonight, I really like it. I can also see including 'tutorial complete' flags in the unpause function, and I'm sure that it could be used to track other variables of that type as well.

Thanks to you both,
Don

#4 I set up my own time manager which basically gets the current scenetime (%scenegraph.getSceneTime()) and then calculates a delta since last update and hands the delta to other managers. They all use this single delta and thus are in sync (or if delta becomes 0 they all pause). I used $timescale for pausing in my last game, but that freezes everything (ie, animations etc) so it's no good for that. Schedule is useful, but it ignores scenetime (uses simtime) and you have to keep track of each scheduled event if you need to possibly cancel it.

Something like what Scott suggested would work, but you can't do anything while the splash screen is showing (like cross-fade it with the next one).

So instead you could create a timed object which gets timer updates from the time manager which you control. For instance, pause the time manager and all the sub-managers will pause. Or you can have submanagers pause themselves without affecting anything else (unlike $timescale). In my current game, popping up the menu during a level stops the updates to the level objects but nothing else. The game is broken into various "states" which receive time deltas and input events (dispatched by the top-level manager) which then control the objects each state manages.

Basically I've got a framework within a framework because I want to control input, animation, etc but Torque just doesn't make that easy. Sorry this is all probably really cryptic and vague, but eventually I might post some code to demonstrate things somewhat. It's not really that much code, and it's all 100% TorqueScript because that allows me to port from Mac to PC or back with no hassles at all.

Good luck with your explorations! :)

#5 @JasonM
Hmm - I understand the concept behind what you're doing, but that's a little beyond me at this point. Fundamentally, I didn't realize the engine was using 2 different clocks - i.e. Sim and Scene times. (There are some gaping holes in my understanding of the GG engines.)

Having fiddled some more, I now understand what you're referring to about $timescale affecting so much. I added $timescale = 0; to my scene pause function and I couldn't figure out why my editors weren't working anymore!

Without $timescale, I did notice what you're referring to about the issues with schedule. I walked away from the editor for a bit and when I came back a spawn enemy loop had been running so long that it crashed T2D when I toggled back over.

Lastly, and I'm embarassed to even admit this, it would seem that in my efforts to keep my scripting clean I erased the section where I was playing with figuring out a wait-type function.


Found it. I was wanting to put in a delay for the player getting control back when restarting after being killed. The goal was to not let the player move until the audio had finished playing. I'd forgotten about it since my enemies are still hardcoded to detect the player and my more pressing task is to get them to leave the player's start point so the player doesn't die immediately.


I still plan to try the GUI idea I had, that might in fact work out to be pretty snazzy even if I still have to sort out the in-game function a different way.

Thanks again,
Don