Community
SCI Programming => SCI Syntax Help => Topic started by: WD-40 on September 13, 2018, 04:25:38 PM
-
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?
-
(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).
-
I definitely want the user to take control at anytime. Take the following scene in Space Quest 3 for example:
(https://thumb.ibb.co/ey6729/Image1.gif) (https://ibb.co/ey6729)
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.
-
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.
-
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.
-
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 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
)
)
)
)
)
)
-
You know there's a proper decompiler now that produces actual script code, right?
-
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?
-
(https://i.imgur.com/3YFXGxU.png)
The rest is in the help system under "Decompiler".
-
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.
-
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".
-
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.
-
It is generally recommended that you use Sierra script instead of Studio.
-
I, for one, recommend getting used to Sierra Script. It's just better.
-
I, for one, recommend getting used to Sierra Script. It's just better.
I have always used Sierra script, just because it's always been the default in my installations :)
I finally solved the problem of the ego not stopping for the first keypress during a setMotion. Something in SetUpEgo() was causing the problem, I'm too lazy to pinpoint exactly what it is. My updated grabber script is tiny and dare I say even better than sierras. :o
-
I have always used Sierra script, just because it's always been the default in my installations :)
I'm confused... all the code you posted is SCI Studio script. But when you create a new project, SCI Companion should default to Sierra script.
-
I'm confused... all the code you posted is SCI Studio script. But when you create a new project, SCI Companion should default to Sierra script.
Well darn, I have been learning SCI Studio script all this time. Is there anything wrong with that? are there any advantages other than being "a hardcore sierra programmer"?
I find both scripting languages ugly, but I find Sierra script even uglier than SCI studio script. :(
Would it be so wrong for these scripts to have "x = 1" rather than "= x 1"? My brain crashes every time I see this backwards style. :P
-
It's not ugly, it's Lisp (https://en.wikipedia.org/wiki/Lisp_(programming_language)).
-
Would it be so wrong for these scripts to have "x = 1" rather than "= x 1"? My brain crashes every time I see this backwards style. :P
It's called prefix notation, and like Kawa said, LISP uses it. It feels weird to you because you're not used to it.
It's also fairly easy to write a parser for it for the compiler, so I'm guessing maybe that's why Sierra used it?
-
It's easier if you read it a different way in your head. "= x 1" can be read "assign x the value of '1'". That's how I wrapped my head around it anyway.
-
Not that anyone cares, but I nailed down exactly what was causing the ego to ignore my keyboard input to stop.
When calling a setMotion the ego will walk just like you pressed a key to make him/her/it walk. However, when asked to stop with keyboard input the ego will ignore your first key press.
When calling a setMotion on the ego it's also necessary to notify it that it's moving in that direction: "(User:prevDir(RIGHT))". This way when you press a key to stop, it will know to stop with a single key press.
-
I care! Always nice to see someone solve their problems for posterity. There were so many cases of this on the mega-tokyo boards that are now simply lost to time.
-
When calling a setMotion on the ego it's also necessary to notify it that it's moving in that direction: "(User:prevDir(RIGHT))". This way when you press a key to stop, it will know to stop with a single key press.
Another option is to disable input until they've completed the entrance animation.
-
When calling a setMotion on the ego it's also necessary to notify it that it's moving in that direction: "(User:prevDir(RIGHT))". This way when you press a key to stop, it will know to stop with a single key press.
Another option is to disable input until they've completed the entrance animation.
I'm not talking about an entrance animation. In some games the ego will enter a room and walk clear across that room and into the next room without any keyboard input. You can stop the ego in its tracks at anytime to explore that room by taking control with the keyboard. To make the ego respond normally to keyboard control you have to tell it what its direction is with "(User:prevDir(RIGHT))". I hope that clears things up.
-
Yes, that's how AGI egos always behaved from screen to screen.