realTimeManager object | events.t[870]

Real-Time Event Manager. This object manages all of the game's real-time events, which are events that occur according to elapsed real-world time.

`realTimeManager : BasicEventManager InitObject`

Superclass Tree (in declaration order)

`realTimeManager`
`BasicEventManager`
`object`
`InitObject`
`ModuleExecObject`
`object`

Summary of Properties

`curEvent_ elapsedTimeAtSave events_ startingTime`

``

``

Inherited from `ModuleExecObject` :
`execAfterMe execBeforeMe hasInitialized_ isDoingExec_ isExecuted_`

Summary of Methods

`execute execute execute executeEvents getElapsedTime getNextEventTime restoreElapsedTime saveElapsedTime setElapsedTime`

Inherited from `BasicEventManager` :
`addEvent removeCurrentEvent removeEvent removeMatchingEvents`

``

Inherited from `ModuleExecObject` :
`_execute classExec`

Properties

`curEvent_` | `events.t[1091]`

the event currently being executed

`elapsedTimeAtSave` | `events.t[1097]`

saved elapsed time - we use this to figure the virtual starting time when we restore a saved game

`events_`OVERRIDDEN | `events.t[1088]`

our event list

`startingTime` | `events.t[1042]`

The imaginary real-world time of the starting point of the game, treating the game as having been played from the start in one continous session. Whenever we restore a saved game, we project backwards from the current real-world time at restoration by the amount of continuous elapsed time in the saved game to find the point at which the game would have started if it had been played continuously in one session up to the restored point.

We set a static initial value for this, using the interpreter's real-time clock value at compilation time. This ensures that we'll have a meaningful time base if any real-time events are created during pre-initialization. This static value will only be in effect during preinit; we're an InitObject, so our execute() method will be invoked at run-time start-up, and at that point we'll reset the zero point to the actual run-time start time.

Methods

`execute ( )`OVERRIDDEN | `events.t[1050]`

Initialize at run-time startup. We want to set the zero point as the time when the player actually started playing the game (any time we spent in pre-initialization doesn't count on the real-time clock, since it's not part of the game per se).

`execute ( )`OVERRIDDEN | `events.t[1108]`

Real-time manager: pre-save notification receiver. When we're about to save the game, we'll note the current elapsed game time, so that when we later restore the game, we can figure the virtual starting point that will give us the same effective elapsed time on the system real-time clock.

`execute ( )`OVERRIDDEN | `events.t[1125]`

Real-time manager: post-restore notification receiver. Immediately after we restore a game, we'll tell the real-time manager to refigure the virtual starting point of the game based on the saved elapsed time.

`executeEvents ( )` | `events.t[927]`

Run any real-time events that are ready to execute, then return the next event time. The return value has the same meaning as that of getNextEventTime().

`getElapsedTime ( )` | `events.t[1000]`

Get the current game elapsed time. This is the number of milliseconds that has elapsed since the game was started, counting only the continuous execution time. When the game is saved, we save the elapsed time at that point; when the game is later restored, we project that saved time backwards from the current real-world time at restoration to get the real-world time where the game would have started if it had actually been played continuously in one session.

`getNextEventTime ( )` | `events.t[889]`

Get the elapsed game time at which the next real-time event is scheduled. This returns a value which can be compared to that returned by getElapsedTime(): if this value is less than or equal to the value from getElapsedTime(), then the next event is reay for immediate execution; otherwise, the result of subtracting getElapsedTime() from our return value gives the number of milliseconds until the next event is schedulable.

Note that we don't calculate the delta to the next event time, but instead return the absolute time, because the caller might need to perform extra processing before using our return value. If we returned a delta, that extra processing time wouldn't be figured into the caller's determination of event schedulability.

If we return nil, it means that there are no scheduled real-time events.

`restoreElapsedTime ( )` | `events.t[1077]`

Restore the elapsed time - this is called just after we restore a game. We'll project the saved elapsed time backwards to figure the imaginary starting time the game would have had if it had been played in one continuous session rather than being saved and restored.

`saveElapsedTime ( )` | `events.t[1064]`

save the elapsed time so far - this is called just before we save a game so that we can pick up where we left off on the elapsed time clock when we restore the saved game

`setElapsedTime (t)` | `events.t[1016]`

Set the current game elapsed time. This can be used to freeze the real-time clock - a caller can note the elapsed game time at one point by calling getElapsedTime(), and then pass the same value to this routine to ensure that no real time can effectively pass between the two calls.

TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3