Author Topic: Using timers  (Read 4227 times)

0 Members and 1 Guest are viewing this topic.

Offline lskovlun

Using timers
« on: January 29, 2007, 05:48:58 PM »
The Timer class in the template game has gone largely unused, and that
is a shame. So here's my attempt at explaining how to use it.

First, there is no need to instantiate an object unless you want to
change the timeout later on. The class methods are designed to take
care of that. Second, the Timer class works by cueing a script when it
expires. I can't recall whether that's in the documentation or not,
but it simply means incrementing the current state number by 1 and
calling changeState. Third, the only real advantage of the Timer class
is its mutator methods. All other functionality is available directly
in the Script class, so if your timing needs are simple, you don't
need this class at all.

Next, I'll describe the architecture of Timer (and Script, in this
regard) objects. There are actually two separate properties devoted
for timing: They are called 'cycles' ('cycleCnt' in the Timer class) and
'seconds'. The difference between them is (obviously) their
resolution and, consequently, also their range. A cycle in SCI
parlance is 1/60th of a second. Thus, the maximum range of a timer if
you choose to use the cycle counter is about 18 minutes. If you choose
to use the second counter, the range is about 45 hours.

The mutator functions I hinted at above are called setCycles, set, and
setReal, respectively. The first one is simple; it takes a cycle count
(which you would have to calculate yourself) and starts a new timer
with that timeout. You would call it like so:

(Timer:setCycle(RoomScript 30))

where RoomScript is the script that will be cued when the timer
expires. The timeout will be half a second (30/60).

The set method is a bit smarter. It automatically calculates the
correct cycle count given a count of seconds, minutes, and hours. This
method also adjusts the final count for the currently set game speed,
which is not always what you want. And it uses the cycle
counter
(see above for a description); the real range of the Timer
class may vary if you use this method. You would use it like so:

(Timer:set(RoomScript 30))

for a thirty-second delay.

Finally, there's the setReal method. Like set, it
performs all calculations on its own, but it uses the seconds
counter, and it does not adjust for game speed. Thus, it is
ideal for game events that depend on how much "real time" passes.
However, it does not work out of the box due to a typo in the template
game. To fix it, find the doit method of the timer class (in
Timer.sc), and the line that says:

(if (not seconds)
    CueClient()
)

Fix the first line so it reads:

(if (not --seconds)

and you're all set.

Finally, the cases where you don't need a Timer object. As I've
mentioned, the Script class has comparable properties (but no methods)
to the Timer class. So you can simply use your room script and the
cycles and seconds properties directly, if you are so inclined. This
is what Sierra did in most cases; you don't really see the Timer class
used much in the games. You would simply do

(instance RoomScript of Script
     (method (changeState newState)
        (super:changeState(newState))
        (switch (newState)
           (case 1
            = seconds 15)
           (case 2
            Print("Time's up!")))))

When using the Timer class, you would similarly put your initialization code in case 1 above (or in a room's init method).



Offline troflip

Re: Using timers
« Reply #1 on: February 11, 2007, 03:08:12 PM »
Is there a way to use timers across screens?  That's how I would expect/hope they would work (e.g. "the ego is holding a bomb, and in 30 seconds, it will explode"). It doesn't look like they are designed for that because they are deleted on every room change.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: Using timers
« Reply #2 on: February 12, 2007, 03:27:14 PM »
There is a way, actually. You need to combine the use of the Timer class with a region. I believe I described those in a post on Mega-Tokyo long ago. I can't find the post right now, but I did find a post by cloudee1 saying you have written one as well. If that is the case, I don't need to go back and dig it up (I'd write a summary here, but my recollection of it is spotty).

Offline Cloudee1

Re: Using timers
« Reply #3 on: February 12, 2007, 08:42:01 PM »
I often seem to remember things differently than they actually happened, so it may not actually be true. But didn't you tell us once how to use region's Troflip. I remember one of the last lines of that post ... But I find it uses more memory than to just enter it in the room script. I remember that, and that was the last time I worried about using regions. I think it may have started out as a thread about Provost's game and the mosquito repellent or it was around the same time... if I remember right.

But both of you guys, more than anyone else have the most interesting how to do this... kind of posts at mega-tokyo. There are a ton that I'd like to bring over (once I track them down again) but I didn't want to start a thread about your codes, mainly because you guys wouldn't be able to edit them. With the new organization of the boards, those topics won't get lost so easily. Please please copy and paste that good stuff here too, likewise any template fixes you remember posting about.

I'm going to add a script to the tutorials page which will pull all of the how to post titles as well making them links to the posts. It would be great if we had some of those posts included. Making it even easier for noobs and me alike to quickly find examples that are well coded and well structured.
« Last Edit: February 12, 2007, 08:46:07 PM by Cloudee1 »
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline troflip

Re: Using timers
« Reply #4 on: February 13, 2007, 12:28:21 AM »
Yeah, I have a post (I think), and a tutorial about how to use regions.  Maybe I did eventually get timers to work across rooms, I'm not sure.  Just looking at Brian's template game right now though, it looks like the doit method in Game.sc deletes all timers on every game cycle.  I notice I have that commented out in my game though.  I know they were still getting deleted on every room change though... when I have time and inclination, I will look at it again.

Regions are pretty useful.. the small amount of extra memory they take is worth it, since they will make your game a lot easier to maintain than it would be if you copied the same code into every room.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: Using timers
« Reply #5 on: February 13, 2007, 06:29:06 AM »
Come to think of it, I don't think you even need to do that. All you need is a Script (capital s)that is guaranteed to survive when the script (small s) goes away. The thing going on during a room change is a kind of garbage collection. It checks whether the client property is NULL before doing anything (note that #delete and #dispose are distinct methods).

Offline MusicallyInspired

Re: Using timers
« Reply #6 on: August 29, 2011, 01:11:22 PM »
Anyone have any ideas here on how to make the Timer class work across screens a la regions in light of the information here?
Brass Lantern Prop Competition

Offline lskovlun

Re: Using timers
« Reply #7 on: August 29, 2011, 02:42:16 PM »
Does anyone know for sure that timers go away inappropriately? As I wrote below many years ago, that should only happen if their clients become NULL - which they do after signaling the client. If so, that is a matter to be investigated. Otherwise, in summary, the things to watch for are:
  • Make sure the Script you gave to the timer remains valid until timer expiration. That is, place it in a region or globally.
  • Make sure that you use the right kind of timer for the job (as described in the original article)

/Lars


SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.091 seconds with 23 queries.