Staredit Network

is there a way to stop a sound at one point in the game and the sound is like the backround music for a trailer

No, sounds only stop when there finished. You need shorter wavs.

You can always go to the windows sound recorder and delete unnessecary parts of the wav to make it shorter

I hate that about SC sounds. I found it annoying when I made an RPG, they old background sound would continue playing at the same time as the battle sounds, and vice versa until one of them finished. I wonder if there is any way at all to block out a sound when you want to so you can stop it at anytime. WIll playing a blank sound over and over make it so you can't hear other sounds?

1. Take your map with a sound.
2. Find a trigger that plays it, add a wait a several plays of a blank wav.
3. Tell us what happens.

What's wrong with you people and not testing the simplest things?

If you play a blank wav that won't help because it will just play alongside the Background music. Thats exactly the problem if the second wav executed took over the first one then the problem would be solved

Import a bunch of sounds and play the piece like it was a midi or something. The advantages are;

1. Better quality(possibility)
2. Lower filesize
3. Can stop, pause, start at a certain time, fast forward, etc.
4. Will always play when it's suppose to, like if the game is paused, it will pause the music as well instead of making it go out of sync with the map.
5. Longer music pieces.

The only thing is that it takes a lot more time and effort.

SO youre having PROBLEMS with wavs playing on top of each other...

Okay, as a solution to your music files doubling on each other like your
'background music' and 'battle music' wavs running on each other... just add "bridge triggers"


like this:


<Trigger Background Music>
::Conditions::
[Switch"Back".set.]
[Switch"Battle".cleared.]
[Switch"Bridge".cleared.]
-----------------------------
::Actions::
[SetSwitch"Bridge"]
[Play"Background.wav"]
[Wait"Duration of Wav"]
[ClearSwitch"Bridge"]
[Preserve Trigger]





<Trigger Battle Music>
::Conditions::
[Switch"Back".cleared.]
[Switch"Battle".set.]
[Switch"Bridge".cleared.]
-----------------------------
::Actions::
[SetSwitch"Bridge"]
[Play"Battle.wav"]
[Wait"Duration of Wav"]
[ClearSwitch"Bridge"]
[Preserve Trigger]






and finally add a trigger like this:




<Initiate Battle>
::Conditions::
[Switch"Back".set.]
[Switch"Battle".cleared.]
[Switch"Bridge".cleared.]
-----------------------------
::Actions::
[ClearSwitch"back"]
[SetSwitch"Battle"]
[SetSwitch"SwitchOver"]
[Preserve Trigger]





<Battle Commencing>
::Conditions::
[Switch"SwitchOver".set.]
[Switch"Battle".set.]
[Switch"Background".cleared.]
[Switch"Bridge".cleared.]
-----------------------------
::Actions::
(Whatever Battle setups or actions happen here)
[Preserve trigger]






and vice versa for ending the battle like:



<Battle Ending>
::Conditions::
[Switch"SwitchOver".set.]
[Switch"Battle".set.]
[Switch"Background".cleared.]
[Switch"Bridge".cleared.]
(Whatever Battle conditions, cleanups or actions happen here)
-----------------------------
::Actions::
[ClearSwich"SwitchOver"]
[ClearSwitch"Battle"]
[SetSwitch"Background"]
[Preserve Trigger]









If this is done correctly, whenever a player has hit a certain condition, there are two backbone triggers:

<Trigger Background Music> and <Trigger Battle Music>, and these two triggers are called upon when certain conditions are met or completed. The trigger that prevents the music from playing on top of each other is the <"Bridge"> Switch, that is only cleared when the wav has completed its job... thus only allowing a switchover when the "bridge" is cleared... when completed, the music should flow seemlessly and quickly.... if you want to add some dazzle, or wav that signals a battle, just add it into the <Battle Commencing> trigger along with waits. (Sliced of course...)



ask me if you can't get it to work... [Private Message] me...

I wonder if ill get in trouble for double posting.... here goes...


bridge triggers are best for any other kinds of things,
such as 'wait stack' prevention, as well as actions occuring at different rates and times...

I shoulda posted this in some tutorial spot... -.-


oh well..

WHy didnt you just edit... But the midi thing sound really cool!

Aye, the "Midi" idea would be cool, but would require an incredible amount of work... just for the music! You'd have to, for example, have all the basic Notes: E, G, B, D, F, and F, A, C, E, and that's just BASICS, not including sharps and flats, and HOLDING a note.
I don't know how you'd hold a note through triggers unless you just had an extension of already made notes.

Yes, it's possible, no ( I, Personally! ) do not think it is worth the work. I've only heard of one person attempting to do this in their own map, and they havn't finish, nor are they close.

Maybe there's a map with "midi" music in the maps section? I don't know.
The closest thing I can think of (concept wise) is the "StarCraft CLOCK" map. It tells you the exact time, all the time, with a few kilobites.

What you do is only get the pieces for the notes you NEED. Each note would be three wav files. The start of the sound, the end of the sound, and the part to be played over and over for holding. This way, you can use the same three sounds for the same note throughout the song no matter how long the note is held.

The system would use death counters for each "measure". This allows you to load a certain part of the song, loop without playing the beginning, and switch to another song easily and efficiently.

You would need this much triggers:

# of songs * number of measures + song controll(actions to play the song and load it).

You would use waits to play the notes properly.

You would use death counters like this, each trigger has a condition of two death counters:


SONG BEGIN
would have one death condition to indicate what song is needed to play
would have another death condition with 0

BAR ONE
Same first death condition as the first trigger
Second DC would be 1

BAR TWO
Same first death condition as the first trigger
Second DC would be 2

...
BAR ??? (Last)
Same first death condition as the first trigger
Second DC would be ?
The last action would set the death counter you used for the second condition to 1, looping the song properly.

Switching the first death counter in the first condition would change the song(Use 0 for no song, 1 for intro for map, etc).
The second would indicate a position in the song. You would copy all these and edit them to your liking, and make sure you add comments to clearly show what is what because it WILL get confusing. So use comments like this:

+-+-+-+-+-+-+-+- SONG 1 - INTRO +-+-+-+-+-+-+
(no comment)
(no comment)
....
+-+-+-+-+-+-+-+- SONG 2 - BATTLE +-+-+-+-+-+-+
(no comment)
(no comment)
....
etc

Also making sure they are in order, so Starforge is out of the question.

Note that these are only for simple songs. Complicated ones will need more triggers.(Example: Drums. You will have to play 3 wav files for each note, one for every drum beat, set deaths, preserve trigger, waits,etc. You are limited to 64 actions remember?)

Switches only work for a Single Player, you'll need Death Counts and setting with Current Player to enable it to work for more than one Player, Bolt killed me on this on many occasions, you will not get away with it either!

Ha Ha Ha, I wasn't really trying to read the triggers Red2Blue wrote. I didn't want to spend the time to figure out what on earth all those switches were for. Plus i don't like the format he writes his triggers in.

Switches can be used in multiplayer coko. But the only thing they are good for is randomizing.

You could split your sound into many sound bytes of about 5-10 seconds each. Then you have a 5-10 second wait before the other one initiates. So if a song starts it checks if another song is playing, then it plays the first part, goes to next trigger that is the next part of the song, then checks again, etc. The main work would be finding an effiecient way of keeping track of what is playing and what is supposed to be playing.