Need help adding pause between setCycle command and send to new room

[stateofpsychosis]

Hi, I'm totally new to SCI programming.
I need help with something you folks would probably find simple. (couldn't find a solution in the tutorials or forums)


I'm trying to add the ability to dig holes with a shovel where the ego falls into the hole into a new room after digging...  I got the digging view all set up and working, but when I add the send new room command afterwards... it skips the shoveling animation all together and goes strait to the new room...  I'm also getting a problem where I can still move the Ego around while the animation is going... maybe i should hide the ego and bring in an actor instead. some tips on that would be appreciated as well

here's the bit of code i'm stuck on

  (if(Said('dig'))
  (if(not (send gEgo:has(INV_SHOVEL)))
    Print("you don't have a shovel.")
  )(else
    (if(send gEgo:inRect(233 113 311 180))
      Print("O.K.")
      (send gEgo:view(5)
      setCycle(Fwd) loop(0)
     )
     (send gRoom:newRoom(4))   
)
 (else
      Print("The ground is too hard here.")
    ))))
             )

I tried using wait(120) but that just freezes it for 2 seconds... i tried using = cycles 50 but that did nothing and also tried seconds=120 or whatever and that did nothing as well..

totally lost on this one

any help would be appreciated

[Cloudee1]

You will need to trigger a changestate method in order to build in the pause.

You are correct on the wait that it freezes everything... pretty useless in my opinion.


Heres an example of what you could do...

Code: [Select]

...


  (if(Said('dig'))
    (if(not (send gEgo:has(INV_SHOVEL)))Print("you don't have a shovel."))// no shovel
    (else // has shovel
      (if(send gEgo:inRect(233 113 311 180)) // in rectangle
       Print("O.K.")
       (send gEgo:setScript(digScript)) // this bit triggers the changestate found in the digScript Instance
      )// ends in rectangle
      (else Print("The ground is too hard here.") ) // not in rectangle
    )// ends have shovel
  )// end said dig


...

//************************************
// comes after the end of the RoomScript
//************************************

(instance digScript of Script
(properties)
  (method (changeState newState)
  (= state newState)
    (switch (newState)
    (case 0 = cycles 5) // just a slight pause
    (case 1 (send gEgo:view(5)setCycle(Fwd) loop(0))// switch ego to animated view
                = cycles 25 // how long
    )
    (case 2  (send gRoom:newRoom(4))
    )// end switch
  )// end method
)// end instance

Just a thought, but you will probably want to add in a ProgramControl() in case 0 so that the user can't take control of the ego, and likewise a PlayerControl() in the last case, to give control back before going to the next room

[stateofpsychosis]

Great!

thanks, it worked

had to do a bit of tinkering but I got it


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



  

Code: [Select]

  (if(Said('dig'))
  (if(not (send gEgo:has(INV_SHOVEL)))
    Print("you don't have a shovel.")
  )(else
    (if(send gEgo:inRect(233 113 311 180))
      Print("O.K.")
      (send gEgo:setScript(digScript))
     )
       (else
      Print("The ground is too hard here.")
)
    )
 )
              )
                   )
            
            
(instance digScript of Script
(properties)
  (method (changeState newState)
  = state newState
    (switch (newState)
    (case 0 ProgramControl()
    
     = cycles 5)
    (case 1 (send gEgo:view(5)setCycle(Fwd) loop(0))
                = cycles 50
    )
  
    (case 2 Print("You dig until the ground crumbles beneath you and you fall into an underground cavern.")
     (send gRoom:newRoom(4))
   = cycles 1)
   (case 3 PlayerControl()
    
)
     )
  )
                 )

now I understand change state methods which is one thing I was having trouble with. thanks again

[Cloudee1]

Here  is how to think of methods and instances...

Methods belong to an instance. You can have multiple methods in each instance but one method has to end before the next one begins. Likewise you can have multiple instances in a script but one instance has to end before the next one can begin.

I am assuming that the bit of tinkering you had to do was because your first attempt landed the digScript inside the RoomScript instance.

[stateofpsychosis]

yea a misplaced ) caused it.

cool cool. that clears that up. time to work on the falling into the hole view!

[Collector]

Falling down holes, eh? "I'm Late, I'm Late for a very important date, No time to say hello, goodbye, I'm late, I'm late, I'm late"

[Cloudee1]

Here's something else to note, if the changeState method is in the RoomScript instance, then it will automatically fire off as that is the active instance of script at room load. Doing like we did for the digging, it started firing off as soon as it was activated by the ego.

So for falling down a hole, you  could either extend the changeState you just created to have it handle the falling down the hole cutscene, or you could launch them into room 4 and put a changeState in the RoomScript instance that would then do the animation when the room loads.

Just a couple of different ideas to get you thinking about possible approaches that would lead to the same result.

[stateofpsychosis]

yea I'm going to try to get it so the hole stays there after and can fall down it again rather than continuing to dig every time, but I'm having seconds thoughts about that now
since I want it so you can dig just about anywhere to find cool secrets
and then my game would be full of potholes... literally


can't seem to get audio effects for the falling to work yet. do they work under the change state method?
might be because I'm using the sciAudio script to patch in my own soundtracks
might have to go write some falling sounds with some basses or something in pro tools rather than use midi

[Cloudee1]

SciAudio is for mp3 and wav playback, but does not support the midi format. You are in  luck though because the sci engine itself does. If you have midi's that you are attempting to use, then you will first need to use soundbox to convert them into sound resources. You can find it on the tools page here.

Using it is relatively easy, First open soundbox. Select "file" and then "import midi". select the midi file and open it.



Now select "edit" and  then "channel properties". This will allow you to select which sound cards play which specific tracks. For the most part New GM is your go to card and you will want every channel flagged to use it. Select the track number on the left side 0-15 then click the check boxes next to the sound card names.



You are all done, click "file" and "save as". It will attempt to save it as sound.000 which is fine for now, or you can change the 000 to whatever resource number you would like to, but leave the SOUND. part of the name alone. You now have a sound resource you can use in your game. In SciCompanion, click on the Sounds tab and then just drag that new SOUND.000 file into the game



Hit the rebuild button and now you are all ready to actually play the sound... almost.

I don't remember if the last time I packaged up the templates if I included the file MPUMIDI.DRV this is kind of an important one. This is the driver that can be utilized to make use of the New GM selections that were in soundbox. Look in your games directory and see if this file is there. If it isn't, it will need to be. And while you are at it, you may want to add it to your template game file so that it will always be there when you start working on a new game. Also, take a peak at your resource.cfg file and make sure that soundDrv = MPUMIDI.DRV

I have gone ahead and attached both the driver file and the config file here so if you want you can just copy these directly into your game folder.

Ok, so now where are we, we have a sound resource, and we have the driver, and the config file is in order... all that is left to do is actually add the call in the script so that it plays in game. You say this is a falling sound, so looking at the last bit of changeState that you posted, I'll just add it in there...

Code: [Select]

...
    (case 2
              Print("You dig until the ground crumbles beneath you and you fall into an underground cavern.")
              = cycles 1
    )
    (case 3
              (send gEgo:hide())
              (send gTheSoundFX:prevSignal(0)stop()number(000)loop(1)play())
             = seconds 2
    )
    (case 4
              PlayerControl()
          (send gRoom:newRoom(4))
      = cycles 1
    )
    )// end switch
  )// end method
)// end instance

Hopefully this helps.

[stateofpsychosis]

hmmm... good to know
but I think I'd still be better off making my own sounds

I have about 20 years experience producing soundtracks and whatnot

might as well not waste it

Plus, why use soundbox when I can use 10 grand worth of music gear to get the highest quality results right? midi is universal anyways, but even without that a falling bass note to make a falling sound is super easy to do probably will only take 10 minutes

still good to know this stuff though for future reference
much appreciated

[Collector]

Plus, why use soundbox when I can use 10 grand worth of music gear to get the highest quality results right? midi is universal anyways, but even without that a falling bass note to make a falling sound is super easy to do probably will only take 10 minutes

Because SCI cannot use MIDI directly. Soundbox converts a MIDI to an SCI SOUND resource so the game can use it. You start with an existing MIDI and then convert it with Soundbox. Its options allow for tracks designed for the different audio hardware at the time. The most common was probably the AdLib card. Most of soundtracks for the Sierra SCI0 games were primarily designed for the Roland MT-32. The Tandy sound would have been limited to its native 3 voice plus Noise. Casio and Yamaha would have been relatively rare. The New GM driver is a fan made driver to add GM support to SCI0. Remember that for SCI0 games (SCI0 is the version used by SCI Studio and Companion) predates the GM standard. The New GM results often leave a bit to be desired.

Whichever tracks you decide to include remember that you must also set the driver in the RESOURCE.CFG to access that track in game. Also not that for a couple, you will also need to configure the dosbox.conf and or your system's MIDI device. For Tandy, you must set "machine=tandy" to get Tandy sound. You will also need to select the "TANDY320.DRV" graphics driver in the RESOURCE.CFG.

For Roland you must have a real MT-32 sound module or the Munt emulator installed. You will also have to set you MIDI device to MPU-401, either through your system or in the dosbox.conf.

[Cloudee1]

It probably won't be an issue starting out, but sciaudio uses a sizeable chunk of heap memory. Using the native midi support once a file has been converted to a sound resource does not require the memory usage that sciaudio does. If you have the memory space to use mp3's then go for it. If you don't, then there is the midi support to fall back on.

That's the boat I am in now with the halloween competition game, very few of my rooms have the heap space available to make use of sciaudio. The ones that do, I am using it, but the ones that don't I am trying to slip in some midi's.

[stateofpsychosis]

Oh damn that's a very good point since I plan on featuring a lot of different tracks in this game. I should probably leave room for those instead. Hmmm... maybe I can get away with it if I use very little sound effects or reuse the same ones for different stuff... and keep the mp3 very very short.. I'll have to play around with both ways I guess.

comps are a great way to get exposure for any medium. smart move!
I'm entering a songwriter one on the 31st as well. Hope you win!

What type of theme are you going for?

[Cloudee1]

Lol, well I am not sure it will result in much exposure, it is a competition hosted here on this site. In the General area there is a board titled community competitions. And there is a real good chance that I will win as it appears I am going to be the only entrant. Which for me is pretty good, because Doan is much better at coming up with plots than I am.

http://sciprogramming.com/community/index.php/topic,1069.0.html

As for the mp3's, it is the sciaudio script that takes up the heap memory and not the audio files themselves. So you don't actually have to worry about their size. I didn't mean to worry you there. The mp3's are actually played by an external program that is started simultaneously with the game, so the game itself never actually touches the audio files hence their size is irrelevant. For example in another project I have going, the intro song is 4.6 MB and it plays just fine.

[Collector]

One last thing that I forgot to mention is that DOSBox does not emulate either the Yamaha or Casio hardware, so those are useless for anyone not playing on a real DOS PC with either of those real hardware.

in another project I have going, the intro song is 4.6 MB and it plays just fine.

VooDoo Girl?