Help Requested: Understanding changeState

[claudehuggins]

After having success with the changestates in my previous script, I decided to try another one, with ego entering a vehicle and ending up in another room. However, I feel like I might be missing something, as case 1 never triggers. Perhaps some SCI wizard could tell me where my code is going wrong? I'm including the whole thing, in case I messed up somewhere in one of the other cases as well, so I won't be flooding the forum with constant questions. 

Code: [Select]

(instance egoEnterScript of Script
(properties)
(method (changeState newState)
= gProgramControl TRUE
(switch (= state newState)
(case 0
(send gEgo:setMotion(MoveTo 186 130 egoEnterScript)) //Ego walks to the pod. I assumed putting "egoEnterScript" there would activate case 1, but once he arrives at the pod, nothing happens.
)
(case 1
(Print("TODO: Animate ego crawling in and set that as his view."))
(self:setScript(egoEnterScript)) //I don't know how to activate a changestate with a print statement, but when I have a view here I won't need that
)
(case 2
(pPodLid:setCycle(End self)) //The pod closes
)
(case 3
(Print("Blah blah I have dialogue" #title "Mark:"))
(pPodLid:loop(1)setCycle(End self)) //The pod lights up
)
(case 4
(Print("I have more dialogue here and there will be a black screen." #title "Mark:"))
= cycles 20  //A short pause after the text is dismissed
)
(case 5
(Print("In the real game you'll go somewhere else but for the sake of having somewhere to go you go here"))  //This is just a note to myself
(send gRoom:newRoom(1))
)
)
)
)
I really appreciate the patience and helpful nature this community has with me as I struggle to wrap my head around this fun programming language. 

[troflip]

My guess is that he never actually reaches the pod. If the ego is blocked, say by a while control line or bumping into an object (is this SCI0?), MoveTo will never reach its destination, and the caller will never be cue'd (and the Script's state won't be incremented).

If the problem is that he's bumping into the white line, then change the destination (or make the ego ignore white control lines during the MoveTo). If the problem is that he's bumping into the pod or some other object on the way, then I think you can tell the pod (or whatever) to "ignore actors" (it's been a while since I've done SCI0, so I forget what you do exactly).

Also, why are you using the SCI Studio syntax instead of the Sierra syntax?

[Cloudee1]

I am agreeing with Phil on this one. I would bet money that your Ego isn't actually making it to that spot. I just tossed your changeState into a game to see what happened and it appeared to work fine. I had to change a couple of things because my current project is in sci1.1 though, so I am not positive.

I don't know about this line "(self:setScript(egoEnterScript))" in case 1, for now a "= seconds 1" would probably fit your needs just fine. Also, the "=  gProgramControl TRUE" Try putting that in case 0, instead of outside the switch. But I don't think that is preventing it from hitting case 1, just something that I noticed.

If you want ego to ignore white lines to make sure he isn't getting hung up on one, in case 0 change the send gEgo statement to this...

Code: [Select]

(send gEgo:ignoreControl(ctlWHITE)setMotion(MoveTo 186 130 egoEnterScript))

I am assuming that the pPodLid is where ego is crawling towards, here is what you could do to make sure ego isn't getting hung up on that. In case 0,  add in a quick call right underneath the ego line above, this...

Code: [Select]

(pPodLid:ignoreActors())

If there are any other views in the way, you will want to do the same for them too. If there are any other control lines that might be blocking ego, for instance yellow if you are using one of the door scripts you might want to ignore them too.

If you need to undo these changes, I believe it's observeControl(ctlWHITE) and ignoreActors(FALSE) and don't worry, I use the Studio syntax too lol

[claudehuggins]

My guess is that he never actually reaches the pod.

Bingo, that was it. Thank you so much for your help 

Also, why are you using the SCI Studio syntax instead of the Sierra syntax?

I'm sorry, I'm actually not sure what you mean exactly. I'm very new to SCI and have just been writing what the tutorials told me to.

[MusicallyInspired]

The SCI Syntax is relatively new. It's just a new set of rules for how to write the code. It's formatted much the same but without as many brackets, I guess, among other things. It's very close to the syntax Sierra actually used, if not identical. SCI Studio syntax was the syntax Brian Provinciano came up with when we thought Sierra's syntax was more like LISP. It's just more authenticity and maybe a little easier on your head. But if you've already mastered Studio Syntax and aren't good with languages, you may want to stick with it. Up to you. You can convert your source to Sierra Syntax in the game properties window (button that looks like a light switch on the toolbar). It'll back up the Studio Syntax version for you in case you change your mind.

[Collector]

Or if you are not that familiar with either yet, best to start out with the Sierra Syntax.

[troflip]

... except the SCI0 tuts are still in Studio syntax.

(Sierra syntax should be the default when creating a new game in SCI Companion, so I'm assuming claudehuggins intentionally changed it).

[claudehuggins]

(Sierra syntax should be the default when creating a new game in SCI Companion, so I'm assuming claudehuggins intentionally changed it).

I suppose I was using a version that defaulted with Studio syntax when I originally began the project, because I don't remember changing anything. (I have since updated to the newest version of SCI Companion.)
I did switch over to Sierra syntax to see how it compared, and it does look a lot better and simpler (to me at least) than Studio syntax did. I was originally hesitant to change syntax because I had gotten so used to the way I had been coding previously, but I'm definitely using Sierra syntax from now on (unless a tutorial I read in Studio syntax completely baffles me when I'm attempting to write its code in Sierra syntax). Thanks for the pointer 

[claudehuggins]

I have another question that is similar to the point of not wanting to create a new forum post.
I went for a similar effect on another room, and somehow this one doesn't want to work. I'm using Sierra syntax this time, so since I'm not as familiar with this syntax I'm including the entire room script in case I borked something elsewhere that's causing the problem, but just know it's egoWashUp that's crashing the game.

Code: [Select]

;;; Sierra Script 1.0 - (do not remove this comment)
(script# 3)
(include sci.sh)
(include game.sh)
(use Controls)
(use Cycle)
(use Door)
(use Feature)
(use Game)
(use Inv)
(use Main)
(use Obj)

(public
rm003 0
)


(instance rm003 of Rm
(properties
picture scriptNumber
north 0
east 0
south 0
west 0
)

(method (init)
(super init:)
(self setScript: RoomScript)
(switch gPreviousRoomNumber
(else
(gEgo posn: 240 140 loop: 1)
)
)
(SetUpEgo)
(gEgo init:)
)
)

(instance RoomScript of Script
(properties)

(method (doit)
(super doit:)
; code executed each game cycle
)

(method (handleEvent pEvent)
(super handleEvent: pEvent)
; handle Said's, etc...
)

(method (changeState newState)
(= state newState)
(switch state
(0 ; Handle state changes
(if(== washedUp FALSE)
(self setScript: egoWashUp)
)
)
)
)
)
(instance egoWashUp of Script
(properties)
(method (changeState newState)
(= state newState)
(switch state
(0
(gEgo view: 5 loop: 0)
(= cycles 2)
)
(1
(Print {placeholder text})
(self setScript: egoWashUp) ;This is where it freezes. Even themusic stops. Case 2 is never called.
)
(2
(gEgo view: 5 loop: 1 cel: 0 setMotion: NULL setCycle: End self)
)
(3
(gEgo view: 5 loop: 2 cel: 0 setMotion: NULL setCycle: End self)
)
(4
(gEgo view: 5 loop: 3 cel: 0 setMotion: NULL setCycle: End self)
)
(5
(Print {placeholder text})
(self setScript:egoWashUp)
)
(6
(gEgo view: 5 loop: 4 cel: 0 setMotion: NULL setCycle: End self)
)
(7
(gEgo view: 0 loop: 1 cel: 0 setMotion: NULL setCycle: Walk observeControl: ctlWHITE)
(= washedUp TRUE)
(= gProgramControl FALSE)
)
)
)
)

[Kawa]

Instead of setting RoomScript's script to egoWashUp in RoomScript::changeState, why not set rm003's script in rm003::init? I've seen many Sierra games do so (enterFromSouth anyone?) and I do it like that too.

At the end of egoWashUp, set the room's script to RoomScript if needed, or clear it, but don't set the script's script.

[troflip]

Code: [Select]

(self setScript:egoWashUp)
Script objects do have their own "sub scripts" that they can call out to, but I don't think that's what you want to do in this case (especially since you're setting the Script's script to itself).

What exactly are you trying to accomplish with that line? Are you just trying to advance to the next case after the Print dialog finishes? I believe Print is a blocking call, so you can just pull the next case into the same one as the Print.

e.g.

Code: [Select]

(instance egoWashUp of Script
(properties)
(method (changeState newState)
(= state newState)
(switch state
(0
(gEgo view: 5 loop: 0)
(= cycles 2)
)
(1
(Print {placeholder text})
(gEgo view: 5 loop: 1 cel: 0 setMotion: NULL setCycle: End self)
)


Of course, you'll need to adjust the case numbers so they're still sequential (or use a switchto statement).