I am changing an actor from one state to another, and it seems to work OK if I use setCurState (actor, newState). This seems to pull the actor out of the old state and put him in the new one.
But the Technical Manual says some of the most commonly used methods/properties defined on the ActorStateClass include…
When I look at Actor.t, this all seems to happen under the hood with setCurState, which is just fine with me. Are there instances where I should try to use activateState & deactivateState directly in my code?
These methods are meant not to be called directly, but that you can inherit them (don’t forget to call inherited) and insert a code when you need to be notified about a state change. For example in my game I use activateState to set conversation node under some conditions:
+ captainTalking: InConversationState
stateDesc = "Kapitán sedí v pilotním křesle a baví se s tebou. "
specialDesc = "Kapitán sedí v pilotním křesle a baví se s tebou. "
Well, when you explicitly switch a state using setCurState, then you have no need to worry about these methods. But sometimes the state is switched not by you as a programmer, but by the player’s actions such as greeting a character in a game. Then the NPC automatically switches from ConversationReadyState into InConversationState (and back after being bored for few turns) for example.
My character is on a board of spaceship and can talk to a captain who is currently driving the ship. Player can came and leave and talk to the captain several times about various topics. Until he eats a breakfast and exercise on treadmill to prevent a boneloss there is nothing special in the conversation. But just after that, when ‘treadmill-run’ flag is revealed, when he starts a conversation with captain, game suggests to him that he can take the duty and drive the ship. That’s the captain.setConvNode(‘me-driving’).
So in other words the overriden method activateState is executed automatically whenever the conversation with the captain starts and under the right circumstances it activates a conversation node containing special topic to take the duty and drive the ship.
Drive the ship? Surely that’s an odd way of looking at piloting a spacecraft. It presumably has momentum, so you shouldn’t need to do anything to “drive” it, other than monitor the instruments and possibly make a course correction once in a great while.
Jim, sorry, my English is quite bad, I know. I read a lot of technical stuff, but write only ocasionaly and barely speak so I’m usually not so eloquent. By driving the ship I mean just sit on the chair, fasten the seatbelt and look on the instruments, ocassionaly push the “pilot is not sleeping” button. I just need the player to hold still few turns until captain goes offstage and something happens.
Please accept my apology. I tend to forget that not everyone on the Internet is a native English speaker!
Your description of the pilot’s job makes sense, except for the part about the seat belt. In a space ship, any unplanned change in momentum is likely to rip a hole in the hull, resulting in the death of the entire crew. A planned engine burn would involve acceleration, but in that case a belt would be of less importance than a well-padded contour seat.
(Sorry to be so fussy, but I used to write science fiction, and I’m a maniac about getting the details right.)
I think you need a belt so you’ll stay in place and not float away as a reaction to every move of arms and such if there is no gravitational or other force holding you in place. Even if we have an anatomical seats. You actually make me remember endless debates over many useless details we held back then We watched some nasa videos and take some inspiration, but of course we are not entirely realistic and from time to time we rely on suspension of disbelief.
The real challange was to design an overall storyline to hold up and make some sense, to allow for a freedom of exploration while still progressing the story, to build responsive NPC’s and to finish the translation of TADS into probably most difficult slavic language on time, to seamlessly integrate a tutorial, deal with segfault in VM just few weeks before release and all this just to surprise a bunch of kids who never ever heard of interactive fiction before and who’ll need to compete against each other to win the game first.