Automatic Ego Motion Problem (SCI0)

[WD-40]

I'm working on a few rooms that require the ego to automatically start walking/driving upon entering a new room, WITHOUT the user pressing any keys. This is not hard to do using SetMotion within the room init code. My problem is that the game doesn't seem to truly understand the ego is moving. Example:

Ego enters a new room and automatically starts walking to the right. Pressing the Right key should stop the ego, however the game doesnt recognize the ego is moving and processes the key press as if the user wants the ego to start walking. After the first key press the ego responds normally, stopping and starting as it should.

The only solution I can think of is to scrap the SetMotion and somehow manually generate a keypress or mouse event for the desired direction of motion. Surely there is a better way?

[lskovlun]

(User canControl: FALSE, canInput: FALSE) or whatever that is in Brian's syntax.

Also, if your movement is part of a cutscene, you'll likely want to use a script instead. Scripts get notified when things like a movement concludes. Then you can use this notification to set the next part of the cutscene in motion (pardon the pun).

[WD-40]

I definitely want the user to take control at anytime. Take the following scene in Space Quest 3 for example:



The ego upon entering this room automatically walks all the way across the tunnel without stopping. The user can take control at anytime by pressing the left or right key.

My problem is that when I press the key to stop the ego, the game thinks I'm pressing a key to make the ego start walking. The effect is that the first key press appears to be ignored because the ego just keeps on walking.

If anyone wants to try this bug out, put the following line of code in the init method of your room: "(send gEgo: setMotion(MoveTo 319 150))". Notice when you try to stop the ego it will ignore your first attempt. Adjust the coordinates as necessary.

[Kawa]

Setting canControl to false makes ego not react to the keyboard. When the moveTo motion is done, that's when you set canControl back to true. Use a script like Iskovlun said to do so.

[WD-40]

I guess this hard to explain. I'm not trying to do a static script where the ego moves to an exact location and then control is given back to the user. I want the user to have full control at all times even when the moveTo is in effect.  After playing with the setMotion method I realize now its doing exactly what it should be doing, just not what I want it to be doing

Thank you anyways for your help.

[MusicallyInspired]

I know it kind of renders your whole exercise redundant and unnecessary (though I understand the allure and importance of it), but you could just decompile the SQ3 scripts and see how Sierra did it.

[WD-40]

I know it kind of renders your whole exercise redundant and unnecessary (though I understand the allure and importance of it), but you could just decompile the SQ3 scripts and see how Sierra did it.

I have been looking at the assembly scripts for clues and I also use the built in debug system for help too. I got my problem figured out, it's not super pretty but it works. Roger is driving his garbage grabber beautifully, even if the code is ugly

(class driveGrabber of Script

   (method (handleEvent pEvent)
      (super:handleEvent(pEvent))
      // handle Said's, etc...
         
      (switch((send pEvent:type))
         (case evJOYSTICK
            MapKeyToDir(pEvent)   
               
            (if (== (send pEvent:message) JOY_RIGHT)  // right key pressed
               
               (if (==(send gEgo: loop) 0) // ego pointing forward
                  (if (send gEgo: isStopped()) // grabber machine is stopped?
                     (send gEgo: setStep(3 1)) // start the grabber machine
                     (send gTheMusic:prevSignal(0) stop() number(52) loop(-1) play()) // grabber machine humming
                  )
                  (else // grabber machine is moving
                     (send gEgo: setStep(0 0) setMotion(NULL)) // stop the grabber machine
                     (send gTheMusic: prevSignal(0) stop()) // turn off the humming sound
                  )
               )
               (else // ego pointing backwards
                  (send gEgo: setLoop(0) setStep(3 1)) // look forward
                  (send gTheMusic:prevSignal(0) stop() number(52) loop(-1) play()) // start the grabber machine humming sound
               )   
             )
            
            (if (== (send pEvent:message) JOY_LEFT)  // left key pressed
               
               (if (==(send gEgo: loop) 1) // ego looking backwards
                  (if (send gEgo: isStopped()) // grabber machine is stopped?
                     (send gEgo: setStep(3 1)) // start the grabber machine
                     (send gTheMusic:prevSignal(0) stop() number(53) loop(-1) play()) // backing up warning sound
                  )
                  (else // ego is moving
                     (send gEgo: setStep(0 0) setMotion(NULL)) // stop the grabber machine
                     (send gTheMusic: prevSignal(0) stop()) // turn off the humming sound
                  )
               )
               (else // ego looking forwards
                  (send gEgo: setLoop(1) setStep(3 1)) // look backwards
                  (send gTheMusic:prevSignal(0) stop() number(53) loop(-1) play()) // start the backing up warning sound
               )
             )         
         )
      )
   )   
)

 

[Kawa]

You know there's a proper decompiler now that produces actual script code, right?

[WD-40]

You know there's a proper decompiler now that produces actual script code, right?

I didn't. Where do i get it? and can I put the decompiled scripts right into SCICompanion and run the game without any problems?

[Kawa]

The rest is in the help system under "Decompiler".

[WD-40]

WOW this is really helpful. This will speed things up about 4X+. The only down side is now I should go back and rewrite everything I have done so far. 

The decompiled code doesn't really match the syntax I've been using, but its not hard to translate. Example != instead of <>, missing brackets, and different ways of passing parameters, etc.

Thanks for the help.

[Kawa]

Yeah, that'd be the SCI Studio vs Sierra dialect, as described in the help system under "The SCI Compiler > Differences from SCI Studio syntax".

[lskovlun]

Yeah, that'd be the SCI Studio vs Sierra dialect, as described in the help system under "The SCI Compiler > Differences from SCI Studio syntax".

We should probably mention that this can be switched in the Game -> Properties dialog box if you prefer. This should affect any subsequent decompilation. When changing this, Companion will offer to convert SCI Studio scripts to Sierra dialect, but not vice versa I think.

[Collector]

It is generally recommended that you use Sierra script instead of Studio.

[MusicallyInspired]

I, for one, recommend getting used to Sierra Script. It's just better.