Messages

1171

SCI Syntax Help / Re: Adding a clock?? And Appearing objects

« on: January 14, 2007, 12:02:17 AM »

Ok I looked it over and the first issue I see is that there are two seperate doit methods. One of the two's contents need to join the other one. Just cut and paste what's inside the second one to just before the first doit method closes.

Another thing I noticed is where you init aman
(aMan:
...
setMotion(Follow gEgo)
setMotion(Wander)
)
you can't really have him wander and follow at the same time.

1172

SCI Syntax Help / Re: Why don't we make a sci tutorial chapter 3?

« on: January 13, 2007, 11:50:20 PM »

Well but that's kind of like what the how to section is. Places to find examples of more things. When it is all said and done, I may split off a big chunk of your time thread and make it it's own how to. Any chit chat in that section should really be about expanding the code the how to talks about, explaining it better, or fixing bugs  when they show up. But even most of that will get trimmed back off when the initial code gets updated. The SCI syntax while mostly filled with questions will get alot of chit chat in them and that's fine because the good questions and resulting examples that express something new or unseen will then become a part of the how to section.

The how to is kind of the next tutorial. The next one I would like to see made though would fix the bugs of the first one, add in the second and third one and expand on what's already there. One single all inclusive tutorial. But I certainly don't want to do it, that would be alot of work.

1173

SCI Syntax Help / Re: How to make a finished game file?

« on: January 13, 2007, 11:34:56 PM »

Remove the source folder from your game folder. Then zip up what's left, a zip file is as close to a stand alone product as you can get. Look at sierra's games they aren't stand alone, we need all those same files as they did. Without the source files though, scistudio can't read the scripts. I've uped the file size limit and allowed for zip attatchments for the game contests. If anybody runs into trouble with the limit being to low then let me know how much you need and I'll up it some more, but you should be able to atatch the zip file to a post, preferably in the competition thread of course. I know a lot of people have their own webspace and if you would rather link to a zip file on your own space, that's fine too.

1174

SCI Syntax Help / Re: Adding a clock?? And Appearing objects

« on: January 13, 2007, 11:24:41 PM »

I don't know exactly I would have to see your code. If it isn't counting down it is probably because of one of two reasons that I could guess about.

1. something is wrong with your doit method, probably closing before the --milsec part at the bottom. Nothing changes till it reaches 0 th first time, so it might not be making it to 0
2. something is wrong with the display, so it is counting down, but it isn't writing it to the screen. Are you sure the procedures to write it are clear at the bottom, after every possible thing, not a single ) should come after them.

Thats my guesses anyway. Feel free to stick it up here, let's see what you did.

1175

Forum Support and Suggestions / Re: When I see who is online I want to pop them a message before they leave.

« on: January 13, 2007, 03:21:02 PM »

The online thing keeps track for 15 minutes, so when you see that they are online keep in mind that it could mean they were online 14 minutes ago and not actually present then. The pms I think pop up an alert to let you know if you have a new one if the user has that option set, while it isn't a direct chatting window, it is the next step down from that.

I can look around and see what there is though.

1176

SCI Syntax Help / Re: Adding a clock?? And Appearing objects

« on: January 13, 2007, 03:13:47 PM »

So here's the inside story on timers. Supposedly there is a whole timer class I believe but so far no one has ever realy announced that they figured out how to use it for anything.

Using a doit method however  it does become possible to count cycles so it turns out we really don't need timers necesarily.

heres the jist. If you want a clock that counts while you travel through multiple rooms then you will need to make global variables. In the main script, at the top where all of the other variable = somethings are listed add in however many countdown variables you need. It is very important to compile all scripts after making any main script edits!! This is a close approximation to my round timer for boxing in fabulous las vegas.

Code: [Select]


countdownminutes = 10 // the count
countdownseconds = 59 // the count
milsec = 5 // cycles per second
countmilsec = 5 // the count


If you only need this in a single room, and the ego can't leave the room then you could place these in a (local ... ) declaration underneath the uses stuff at the top, if the ego leaves and comes back the timer is reset to it's original value this way, using global variables then they will not forget what numbers they were on.

Now in order to see the countdown, you are going to need to display these values of numbers to the screen. the countmilsec variable is used to count the actual cycles so we won't display that. Since this is my own script and there were several different times to write the same bit of info to the screen, I made these statements into  procedures. To use these, you will simply need to place this whole bit below everything else, outside of all of the instances.

Code: [Select]


(procedure public (Writemin)                                  // display Minutes
(var textstring[50])
    Format(@textstring "%2d" countdownminutes)
    Display(@textstring dsCOORD  144 8  dsCOLOR 00 dsFONT 4 dsBACKGROUND 15 dsWIDTH 10)
)

(procedure public (Writesec)                                  // display Seconds
(var textstring[50])
    (if(< countdownseconds 0)   = countdownseconds 0) // resets seconds if it dips negative

    Format(@textstring "%2d" countdownseconds)
    Display(@textstring dsCOORD 156 8 dsCOLOR 00 dsFONT 4 dsBACKGROUND 15 dsWIDTH 12)
)


Now whenever we need to update the times displayed it can be done by simply using  Writemin() and Writesec().  Now would be a good time to add those into the rooms init instance where all of your rooms views and actors are inited, so the screen will start off with all of the necesary values displayed.

Code: [Select]


 Writemin()                     // update minutes displayed
 Writesec()


So I suppose now it is time make the part that does the counting.

Code: [Select]


  (method (doit)
  (super:doit())

    (if(== countmilsec 0)
      (if(== countdownseconds 0)
        (if(== countdownminutes 0)  // all three timers reach 0

           //  ... countdown at 0, now what


        )
        (else   // milsec and sec at 0 but not min
        = countdownminutes --countdownminutes  // so subtract one minute
        = countdownseconds 59  // changes the 0 to 60 to keep timer counting down
        Writemin()  // update minutes displayed
        Writesec()
        = countmilsec milsec // resets milsec to cycle delay
        )
      )
      (else  // milisec at 0 but not seconds
      = countdownseconds --countdownseconds  // so subtract one second
      Writesec()  // update seconds displayed
      = countmilsec milsec     // resets milsec to cycle delay
      )
    )


    = countmilsec --countmilsec  // subtract one from milisec each cycle

) // end method

And there you have a clock timer. It's not perfect in that seconds aren't always displayed as two digits. 00 - 09 are displayed as 0-9. But it counts down. Whenever you want to add more time, all you have to do is something like "= countdownminutes (+ countdownminutes 7)" or you could reset it regardless of what value it is on by doing "= countdownminutes 2"

As for number 2, you can simply add in the views init statement in the same place you told ego to get the first item. It would need an instance just like everything else. But other than that you are just moving it from the init method to the handle event method since it is being triggered by a user input instead of automatically inited.

Code: [Select]


(if(Said('get'/'rock'))
  Print("ok")
  Print("Hey, there's a strange plant under the rock")
  (send gEgo:get(INV_ROCK))
  (rock:hide())
  (plant:setPri(13)ignoreActors()init())
  // = countdownminutes (+ countdownminutes 7)
) // end said rock



the rock would disappear and the plant appear.

1177

SCI Syntax Help / Re: How to do special Death-handler code

« on: January 13, 2007, 01:57:37 PM »

you do need the ) that comes before those // blah blahs but no you don't need the // blah blahs

you are right, they are very simialar to the /* blah blah */. Those are two different ways of adding comments. The /* */ make everything that falls between them a comment and // makes everything following it on the same line a comment. Comments are part of the source code that you can see, but the compiler doesn't. It's like putting notes in there for yourself. Really I put those in there just to mark where the major statements end. All throughout my scripts you'll find where I mark the end of switches methods and instances with those comments. Just to help me find my way around my scripts.

You don't have to give me any credit for anything though, I don't need any kind of glory or recognition.

1178

SCI Syntax Help / Re: Ideas to create Keypad from SQ1

« on: January 13, 2007, 02:48:50 AM »

I've got two daughters and neither are old enough to read yet so your game is a little advanced for what I would make, but I've been considering trying to make some educational entertainment.

For the most part mine would be one of those games where there is say a sea scene and you click on different things to trigger animations and events. Really just to get them associated with using the mouse and clicking.

I'd be interested in hearing your ideas.

As far as a keypad, that all depends on what you want it to do. Like a full blown calculator that appears onscreen, that would take some work.

1179

SCI Syntax Help / Re: How to do special Death-handler code

« on: January 13, 2007, 02:29:43 AM »

Ok j, I cleaned up your code a little bit you had a couple of funny things going on. Methods should never appear inside of each other. You can have several types of methods acting in a roomscript, but they each close before a new one starts, just like instances, you'll notice that the entire roomscript is an instance of a script and it ends before the other instances begin. Each method has kind of different rules to go by just like instances. For instance it doesn't make sense to apply motion to an instance of sound or to play() a view, certain methods are used for certain things.  doit method checks your if statements every cycle. the handle event method is used to get user input either from the keyboard, mouse, or joystick, if there is no input then it doesn't bother doing anything. The changestate is used to change things around sequentially, but only when its told to.

Also instead of checking for program control around each statement in the doit method, we can just check once and stick those other if statements inside of it. But remember only the things you want to happen when program control is set should go inside there, If you want something checked regardless, it would still need to be in the doit method but outside of the "(if(not(gProgramControl))  ...  ) // ends not program control" statement

Here is what I got out of your roomscript instance. You may want to take a moment to compare yours and this.

Code: [Select]

(instance RoomScript of Script
(properties)
 (method (doit)
 (var dyingScript)
 (super:doit())

 (if(not(gProgramControl))
    (if(< (send gEgo:distanceTo(aMan)) 15)  
       ProgramControl()
       = dyingScript ScriptID(DYING_SCRIPT)
       (send dyingScript:caller(3)register("You're dead"))
       (send gGame:setScript(dyingScript))
    )

    (if(< (send gEgo:distanceTo(aMan2)) 15)  
       ProgramControl()
       = dyingScript ScriptID(DYING_SCRIPT)
       (send dyingScript: caller(4)register("You're dead"))
       (send gGame:setScript(dyingScript))
    )

    (if(< (send gEgo:distanceTo(aMan3)) 15)  
       ProgramControl()
       = dyingScript ScriptID(DYING_SCRIPT)
       (send dyingScript:caller(5)register("You're dead"))
       (send gGame:setScript(dyingScript))
    )

   (if(< (send gEgo:distanceTo(aMan4)) 15)  
       ProgramControl()
       = dyingScript ScriptID(DYING_SCRIPT)
       (send dyingScript:caller(6)
       register("You're dead"))
       (send gGame:setScript(dyingScript))
    )
  ) // ends not program control
 )// end method

 (method (handleEvent pEvent)
 (super:handleEvent(pEvent))

   (if(Said('look'))
    Print("You are in a room...ahhhh there are ghosts all around you stay away from them!!!")
   )// end said look

 ) // end method
) // end roomscript instance

(instance aMan of Act  (properties y 185 x 220  view 3))
(instance aMan2 of Act  (properties y 18 x 20    view 4))
(instance aMan3 of Act (properties y 85 x 200 view 5))
(instance aMan4 of Act (properties y 50 x 10 view 6))

Hope this helps clear some things up.

1180

SCI Syntax Help / Re: How to do special Death-handler code

« on: January 12, 2007, 10:09:38 PM »

Sorry to create repetition, I am a newbie still...to tell the truth I am still getting used to the site and not sure where everything is.  Sorry Cloudee!.....Doan is SCI king for the day though...

It's fine, any discussion is good discussion. If anything it provides an opportunity for people to provide more examples of code which can then be added to the how-to making it ever more in depth.

Take your time getting to know the place, it is a lot bigger than our old single board. But two years from now I think it will be alot easier to find things. I don't mind moving topics around, it's something that is going to happen from here on in and not just yours, so don't even worry about it.

1181

SCI Community How To's & Tutorials / How to get and use specific keyboard keys

« on: January 12, 2007, 08:11:31 PM »

This is a real old post that I dug up from the depths of Mega-Tokyo. I'm in the middle of a big mini game kick and in order to expand control options I am looking into using keys. But I wasn't sure how to check for the keys pressed because I didn't know the values to check for. This old post first describes how to check for the pressed buttons if they have been declared in the Keys.sh file and the second little bit of code describes how to output the value of a key pressed such that you wouldn't need to edit the keys file to check for it. So you can just go check for one anytime you need a keys value.


INTERCEPTING KEYBOARD AND MOUSE EVENTS

For this demonstration, Ego will change into Brian if the player presses B (capital) and back to Ego when E (capital) is pressed.

Add Brian as a view as described in the Tutorial Chapter 19 (Resource->Add Sample->View->Brian and save it as view number 1.

In the instance of RoomScript add the following code:

Code: [Select]



(instance RoomScript of Script
  (properties)
  (method (handleEvent pEvent)
    (var str)  //Local variable
    (super:handleEvent(pEvent))

    (switch( (send pEvent:type) )
      (case evKEYBOARD
          (if(== (send pEvent:message) KEY_B )  //Check if B was pressed
              (send gEgo:view(1))  //switch to Brian
              (send pEvent:claimed(TRUE))
          )//if B

          (if(== (send pEvent:message) KEY_E )  //Check if E was pressed
              (send gEgo:view(0))  //switch to Ego
              (send pEvent:claimed(TRUE))
          )//if
      )//evKEYBOARD

      //For fun intercept the Mouse event as well
      (case evMOUSEBUTTON
          (Print("You pressed a Mouse Button!"))
      )//evMOUSEBUTTON
    )//switch
  )//method
)//instance


 
The code: send pEvent:claimed(TRUE)): specified whether the event object can be used; in this case the :Said: command will ignore the event when the player presses either a B or E.

Compile and test.  Ego will be transformed into Brian if you press a B and back to Ego if you press an E.  If it does not work, the values may not be declared in the Keys.sh file.  Open the file (..\SciStudio\include\Keys.sh) to view the defined values.  You may want to expand the list with the lower case values (a=$61,..z=7a).  If you want to trap other values, you can view the value of the key code by adding the following code just below the :case evKEYBOARD: statement:

Code: [Select]



=str ""
(Format(str "str=%x" (send pEvent:message)))
(Print(str))
 

Test by pressing Ctrl-k.  The value should be $0b.  You can add the value in the Keys.sh file or using it directly in the statement (if(== (send pEvent:message) $0b)  ext

1182

SCI Syntax Help / Re: How to do special Death-handler code

« on: January 12, 2007, 04:04:37 PM »

It's a good thing I typed all that in yesterday in the sci how to's board 

http://emptysacdesigns.com/sciforum/index.php?topic=62.0

If anyone would like to explore the death handler further, I'll add all of the examples we come up with here to the death handler section thread of how-to, just to make it more comprehensive and to keep all of it in one place.

1183

SCI Syntax Help / Re: How to change screen entry positions to exact locations?

« on: January 12, 2007, 04:00:27 PM »

When you are moving from one room to another, if you want the ego's last position reflected then you need to use it as the variable.

For instance this code is directly from one of my games. room 500 is the inventory screen, and when you return from it you need to be in the exact spot that you left. room 3 is adjacent to the room so some variables need to stay the same like the egos y position and loop, but not all of them as you see I manually set the x.  Anyway, hope this little snippet helps clear up your question.

Code: [Select]

  (switch(gPreviousRoomNumber)
    (case 500  (send gEgo:view((send gEgo:view))loop((send gEgo:loop))posn((send gEgo:x) (send gEgo:y))init()))
    (case 3    (send gEgo:view((send gEgo:view))loop((send gEgo:loop))posn(45 (send gEgo:y))init()))
    (default(send gEgo:view((send gEgo:view))posn(170 130)loop(2)init()))
  ) // end switch
As far as making a character follow the ego from room to room, I would probably use a global variable, then depending on if the variable is set to true or false init the following character in the particular rooms otherwise simply don't init the character.

1184

SCI Syntax Help / Re: How do you make actors walk through walls?

« on: January 12, 2007, 03:52:55 PM »

If you want to make it so specific actors can walk through walls, it is as simple as telling them to ignore the white control lines. So if you had a ghost for example who could pass through walls. The intance would be the same for any regular actor, except when you init it try doing this.

Code: [Select]

(ghostMan:ignoreControl(ctlWHITE)init())
ghostMan can now walk through all white control lines. Similarly, if you would like a character to not cross say the blue control line you could also use.
 

Code: [Select]

(ghostMan:observeControl(ctlBLUE)init())

1185

SCI Community How To's & Tutorials / Examples of utilising the death handler

« on: January 11, 2007, 09:23:19 PM »

Alright so you have done the tutorial and now you are working on your own game, and you want the character to die but getting the user to type "die" just isn't going to cut it. Most cases of handling death can be done in the same way, by adding in a doit method. For instance being too close to a character or view, crossing a road or perhaps standing in the wrong spot, like under a piano. Would all be handled in the doit method.

Kill the character whenever something else gets too close. We will of course need to have an instance of the oPPonent actor, as well as having it inited, but otherwise to activate the death script.

Code: [Select]

(method (doit)
 (var dyingScript) // don't forget this line
 (super:doit())

   (if(not(gProgramControl))
    (if(< (send gEgo:distanceTo(oPPonent)) 40)
      ProgramControl()
//      (oPPonent:cel(0)loop(4)setMotion(NULL)setCycle(Fwd)) // switch opponent to attacking
//      (send gEgo:view(1)cel(0)setMotion(NULL)setCycle(Fwd))// switch ego to getting attacked
 
      = dyingScript ScriptID(DYING_SCRIPT)
      (send dyingScript:
       caller(3)
       register("You're dead")
       )
      (send gGame:setScript(dyingScript))   
    )
   )
 ) // end method
  
Similarly, If perhaps ego were to attempt crossing an uncrossable road. Rather than measure the distance between ego and something you can just simply lay down say a purple control color line on the road where ego can't cross. For this you will still need a doit method but the car which is still an actor since we need to apply motion to it, but you won't need to init it when you do all the normal things, but rather right when it's needed, afterall it may never actually be needed.

Code: [Select]

(method (doit)
 (var dyingScript)
 (super:doit())

   (if(not(gProgramControl))
    (if(== (send gEgo:onControl()) $0021)// purple and black
      ProgramControl()
      (oPPonent:cel(0)loop(4)setMotion(walk)MoveTo(0 165)init()) // Car starts down road
      (send gEgo:view(1)cel(0)setMotion(NULL)setCycle(End))// switch ego to getting hit
 
      = dyingScript ScriptID(DYING_SCRIPT)
      (send dyingScript:
       caller(3)
       register("You're dead")
       )
      (send gGame:setScript(dyingScript))
  
    )
   )
 ) // end method
  

Another way of doing it would aslo be to check if ego was in a rectangle and whenever they are trigger the events. It's exactly the last two examples except the beginning if statement, which is essentially what typing the word die in is in that section of the tutorial, it is simply the trigger to start the death event.  The best way by far, giving the most room for animations is to place the death handler at the end of a changestate.