Wait-and-Go Using Switch Statements to Drive Automated Scenes

[NilG]

Another question for the SCI gurus, I'm using a switch state to move along an automated scene (perhaps there's a better way to do this, I'm all ears for sure).

Currently, I have the following set up within it.

(2
   (theMessenger posn: 155 160)
               (= seconds 1)
)
(3
   (theMessenger setCycle: Walk setMotion: MoveTo 155 157)
   (= cycles 1)
)
(4
   (theMessenger loop: 0 setMotion: MoveTo 205 143)
   (= seconds 2)
)
(5
   (theMessenger loop: 1 cel: 0)
   (= seconds 2)
)

This works okay, but I'd like to cut out the waiting periods between the states, if possible.  Two issues I'm seeing with this:

• Setting cycles or seconds to 0 just seems to stop everything entirely, rather than skipping over the waiting period.
• If I set #4 to something low like 1 cycle, the loop updates even though the movement is still going on, I'm guessing because MoveTo waits for an ok call while loop doesn't.

So it works, but I have awkward halts between movements and am sure there must be a better way to do this then figuring out the animation cycles required to wait before travel is complete to change loops.

Is there some alternative to seconds and cycles that waits for the commands to fully be carried out in each state and all called methods to get the ok when necessary, then immediately moves on to the next state?  Or is there another way to do this?  Is a switch state not even the best option?

Also, while I'm asking, if I'm working an SCI0 parser, it looks like there's no Path Motion method; is the best way to make multiple MoveTo calls like above, or is there some other way to direct a multi-step path?

Thanks in advance!  Trying to figure things out on my own the best I can, but occasionally getting caught up between the two different scripts, various versions of SCI, and limited documentation.[/list]

[Kawa]

Cutscenes are indeed done by switch blocks so you got that right.

Many commands like setMotion can take a caller parameter. That way, once the messenger has moved to 205 143, it'll call back and cue the caller, which is the script you show here: (theMessenger loop: 0 setMotion: MoveTo 205 143 self)
That way you don't need to set cycles or seconds, but just let the script sit back and wait for the messenger to arrive. You can wait for a loop to finish the same way.

Every time cycles or seconds reaches zero, the script cues itselfs. Thus, setting them to zero yourself won't cue.

Also, try DPath: (theMessenger setMotion: DPath <pairs of coordinates> self).

[troflip]

Yes to what Kawa said ^^^

Also, for scripts like these where you're just chaining a series of events, you can use switchto instead of switch so that you don't need to make sure to maintain all those numbers correctly.
http://scicompanion.com/Documentation/Compiler/switchto.html?highlight=switchto

[NilG]

Thanks guys, that's much neater and works like a charm.  Another question about cutscenes; I disabled user input during this one, but is there a way to still listen so that if the player hits for example 'x' or some other control key (I may allow for looking during other cutscenes) I can let them break the switch to skip the cutscene?

[troflip]

(assuming SCI0)
If you look at the code from ProgramControl in Main.sc, you can see it sets two things on User. canControl determines whether the ego can move, and canInput determines whether you can respond to events. So you could manually set canControl to FALSE, and canInput to TRUE, and then your room script's handleEvent method should be called when a key is pressed, despite the ego not being able to move.

Code: [Select]

(procedure (ProgramControl)
(User canControl: FALSE canInput: FALSE)
(gEgo setMotion: NULL)
)


(procedure (PlayerControl)
(User canControl: TRUE canInput: TRUE)
(gEgo setMotion: NULL)
)