Audioprofiles.cs and general script organization

#1

Quote:Why not just have the audioprofiles defined on the client?

is it that the server cannot trigger an audio profile that was created on the client?

#2 The client audio profiles are only played on the client. Mainly for things like background music and button sounds, ect.

#3 Sure I understand that, but is there a reason it has to be in two different places?

some background on what I'm doing:
I'm making a single player game, I was thinking that if I put all my audio datablocks on the client side, then the phase where datablocks are downloaded to the client will not have to pass them all. also if I have all my audio datablocks in one place it might be a bit easier for me to organize them.

#4 Aside: it's interesting that the audioprofiles and audiodescriptions on the client side are created with new, while on the server side they are created as datablocks. I don't quite understand this.

for instance:
client side audioprofiles.cs

new AudioDescription(AudioGui)
{
   volume   = 1.0;
   isLooping= false;
   is3D     = false;
   type     = $GuiAudioType;
};

new AudioProfile(AudioButtonOver)
{
   filename = "~/data/sound/gui/buttonOver.ogg";
   description = "AudioGui";
   preload = true;
};

serverside audioprofiles.cs

datablock AudioDescription(AudioDefaultLooping3d)
{
   volume   = 1.0;
   isLooping= true;

   is3D     = true;
   ReferenceDistance= 20.0;
   MaxDistance= 100.0;
   type     = $SimAudioType;
};

datablock AudioProfile(takeme)
{
   filename = "~/data/sound/takeme.wav";
   description = "AudioDefaultLooping3d";
	preload = false;
};

#5 That is interesting... ;)

I'd leave your game sounds on the server, unless you want ot be calling clientCMDs everytime you want to play a sound. I don't think that would even work right for 3d sounds.....

Unless you can load them on the client and still play them from the server...?

I've always found tha keeping the client/server seperate is a good idea, but I'm not making a single player game.

#6

Quote:unless you want ot be calling clientCMDs

oooooh good point, I wasn't thinking there.

Quote:Unless you can load them on the client and still play them from the server...?

ahh yes see this is what I'm getting at, if the server knows about all datablocks on the client then theoretically it will just work, I mean the sounds all play on the client anyway not the server. I wasnt' thinking about issueing clientCMDs back to play the sounds, just defining the datablocks on the client....err either way I'm being a bit silly. even if they are defined on the client and we want the server to know about them, then they will have to be passed to the server, just like they were passed _from_ the server before, so I wouldn't get anything out of it.

separation it is. :)

#7 AudioProfiles on the client is meant for things like GUI sounds, music, and so forth. These are sounds that are used when connected to a server or not. What these sound profiles should not be used for are for playing audio such as a weapon fire sound or an explosion sound. Basically any sound that isn't an in-game sound should go here.

audioProfiles on the server is meant for all the sounds you hear while playing a game: explosions, environment audio, weapon fire sounds, 3d positional audio.

As you have pointed out there is a major difference in the way the profiles are setup. On the server the profiles are setup via a datablock. Essentially a datablock is a chunk of information or data that needs to be transmitted from the server to the client before that client can join the game.

#8 Regarding the link to the general script organisation - I guess you saw David Michael's .plan file.

#9

Quote:
AudioProfiles on the client is meant for things like GUI sounds, music, and so forth. These are sounds that are used when connected to a server or not. What these sound profiles should not be used for are for playing audio such as a weapon fire sound or an explosion sound. Basically any sound that isn't an in-game sound should go here.

thanks for the explanation, but I do understand the way it's currently set up and the intent for each. Josh said the same basic thing a couple posts above. I guess I'd like to know the why behind your statement about what client profiles should not be used for.

Quote:Essentially a datablock is a chunk of information or data that needs to be transmitted from the server to the client before that client can join the game.

ahh I see, I didn't realize it was a one way thing I had thought that datablocks were used on the client as well as the server. I see now. thanks.

#10 @Dirk, thanks for the link, good notes, but unfortunately not what I'm looking for. As I recall, it was someone who was reorganizing and cleaning up the starter fps scripts...I just spent another long while searching and I give up for now :) maybe It was all a dream.

#11 Ah hahhh..


here it is

#12

Quote:
I guess I'd like to know the why behind your statement about what client profiles should not be used for.

I'll give you an example of a why. Lets say you are making a counterstrike clone. Would you want your audioProfiles for the footstep sound to be on the server, wherein the information about that sound: how loud the sound is, how far the sound plays before it begins to fall off, ect. is transmitted to the client every map essentially guaranteeing that all is fair. Or would you rather the audio profile for those footsteps to be on the client, wherein they can be changed and more importatly exploited to get some kind of advantage?

Quote:
ahh I see, I didn't realize it was a one way thing I had thought that datablocks were used on the client as well as the server. I see now. thanks.

They are used on both, technically speaking. Tho that use on the server is more for informational purposes then anything else. Ie: for sounds the server doesn't really care nor does it want to play them, but it would like to tell objects what sounds they can use, as an example.

#13 Of course: I should have known better ;-).

Yes, this is a very promising ressource. AFAIK he is working hard on this, can't wait to see that, too. I was under the impression you wanted the structure of the existing .cs files.

From the .plan file the SSK (Super Starter Kit) will be not even similar to the existing structure, due to the major overhaul in it.

#14 @Robert,

Quote:map essentially guaranteeing that all is fair. Or would you rather the audio profile for those footsteps to be on the client, wherein they can be changed and more importatly exploited to get some kind of advantage?

but as I said, I'm making a single player game :) so those reasons don't apply to me.

#15 I am working with the the Torque game engine. I am attempting to alter the racing starter kit so that I can get music to play at the main menu (the GUI that is loaded up after the Garage Games GUI intro). Where do I add the code to get the .wav file to play? From what I understand, my audioDescriptions and audioProfiles should be in the client side audioProfiles.cs file. Where do I add the code to get the music to play when the main menu GUI is loaded and stop when the player initializes the actual racing game? This may be a trivial issue, but it's giving me problems.

#16 @Todd

I use something like this in mainMenuGui.gui:

function MainMenuGui::onWake()
{
	$gameMusic = alxPlay(LoadingMusic);
	
}
function MainMenuGui::onSleep()
{
	alxStopAll();
}

...where LoadingMusic is defined in the client-side audioProfiles.cs as:

new AudioDescription(GameMusic)
{
   volume   = 1.0;
   isLooping = true;   
   is3D     = false;
   type = $GuiAudioType;
};
new AudioProfile(LoadingMusic) {
      fileName = "~/data/sound/music/LoadingMusic.ogg";
      description = "GameMusic";
      preload = true;
};