[CF-Devel] Sounds, continued

Thu Apr 29 02:58:53 CDT 2004

Mark Wedel wrote:
>

       Looks good.

     >

     >

       I'd document that you probably want to have more generic names, unless 

     >

      there are going to be that many sound files (eg, should you use 

     >

      goblin_death with orcs?  It would seem confusing if you do)

The idea is to let people make as many sounds as they want. IE if i want 
to use 'small_monster_death' as sound for all monsters, i can. But fi i 
want a sound per race, i can too :)

>

       The sound files should really get moved into the client CVS area, vs 

     >

      being their own checkout, but thats not a major deal.

yep & yep.

>

       In practice, the collect should deal with removing duplicate names, 

     >

      like it does faces, and complain if two different files use the same 

     >

      sound name but are different.  Otherwise, I'm sure someone will run into 

     >

      the case of adding a new sound and it not working as expected, because 

     >

      he chose a duplicate name of another sound.

Hum, that's what i was using names like goblin_death <- to avoid 
confusing with orc_death sound, for instance.

>

       I'm not sure what you mean by that last sentence of event->sound 

     >

      number. Pretty much it is almost aways better to use english/words in 

     >

      the files than just numbers.

I meant, if there are 10 sound event types, objects have a int 
sound_event[ 10 ] field. So just map event to sound number.

>

       I'd also note that you should be able to define more than one sound 

     >

      element to an event, eg, something like:

My proposal is to do that on the client - let the client handle the 
different sound possibilities.

>

       I take it this is to cover the case above - you might have three 

     >

      different goblin_death definitions?

Yes, sorry if i wasn't clear enough.

>

       I'm not sure I like it - it means it that it is more likely that you'll 

     >

      need to set up more sound info lists for objects.  Eg, lets say the 

     >

      goblin does have 3 death sounds.  Lets say that I want to use one and 

     >

      only one of those for the orc, plus a couple others that may get shared 

     >

      (maybe one from the ogre also or something).  this may mean that the 

     >

      number of .snd files could easily be many times the actual number of 

     >

      sounds.  It also means it is harder to use already defined sound files 

     >

      for map customizations.

Well, make one .snd file with 3 'sound goblin_death' blocks. Server 
picks the first one only, client will ready 3.
But yes, if you want to use one for both orc & goblin, you'll need to 
add 'sound orc_death' somewhere.

>

       But the other case is this oddity - since the client would choose which 

     >

      sound to play, if there are multiple sounds associated, two players on 

     >

      the same map could get different sounds even though they are hearing the 

     >

      same event.  This would seem particularly odd if those two players are 

     >

      in the same physical room, and thus hear the sound from the others 

     >

      computer.  I think it'd make more sense for the server to choose the 

     >

      sound to play, so that everyone gets the same sound.

Hum, got a point there.
My idea for multiple sounds was to let client handle all that. Server 
just sends a sound name, client takes care of the case when multiple 
sounds match and plays one randomly.
This also lets easily a player customize a sound - tweak .snd file to 
add or remove customized sounds, without needing server access.

>

       If you do that, it also means that as part of the optional parameters 

     >

      for the sounds, you could have different weightings.  Eg, something like:

     <snip>
>

       Thus, goblin_death2 is played only 10% of the time, compared to 30 and 

     >

      40 for the other ones (and perhaps if the totals are less than 100, then 

     >

      have that remainder 20% have nothing played?  EG, I could certainly see 

     >

      cases where you want the sound played some of the time, but not all the 

     >

      time the event happens.

Could be done adding a 'weight' line to .snd - again, client would take 
care of those weights.

>

       I also changed the way the sound events are listed - put it in a 

     >

      soundinfo/endsoundinfo block - I think this would make it easier on the 

     >

      editor - I'm not sure how the editor deals with fields that start with 

     >

      the same apparant name - it might strip some of those out.

Since my proposal was just to add 'sound xxx' to archetypes, editor 
would (unless i'm wrong) handle that just right.
Your block idea is nice too, though.

>

       The problem here is that at startup, the server needs to know it has 

     >

      has that sound it needs to associate.

That's why server could read two files: sound_arch & sound_maps.

>

       I personally don't think there is any need for this - to add a 

     >

      congratulate player event, you're going to have to add the sound to the 

     >

      list of available sounds, and if you've already done that, making up a 

     >

      .snd file should be trivial.

Right, but then you'd need to actually tweak archetypes, rebuilt files 
and so on just to add your sound. If with a 'sound_maps', your don't 
need archetypes - just maps.
(and in both cases, for now, player needs to manually download sound files)

>

       Which as said above, I don't quite think is correct, as it would mean 

     >

      different players would here different sounds even though they should 

     >

      here the same thing.  And I think at some point, it'll be found that the 

     >

      server will want to customize the sound based on other events.

     >

     >

     >

       For example, right now, when you hit something when attacking, 

     >

      different sound it played based on the amount of damage - I'd probably 

     >

      say you don't want to have 5-6 different hit sound lists - rather, it'd 

     >

      be nice to have just one 'hit' event, and through some mechanism, the 

     >

      server can choose which one to play based on damage.

Could be nice, indeed.
Gah this is starting to get complicated :)

>

       Certainly a list of sound events that the server players, or perhaps 

     >

      have event_type tag in the the sound information itself.  Thus, you 

     >

      could hve something like:

     <snip>

I was more thinking of something like:
#define SOUND_EVENT_LOGIN	"player_login"
#define SOUND_EVENT_LOGOUT	"player_logout" <- sound names

but

#define SOUND_EVENT_CAST_SPELL	1
#define SOUND_EVENT_APPLY	2 <- number used on 'sound xxx' lines in 
archetypes
...

but yes, maybe wouldn't be that nice...

I think basically we both have our ideas about sounds, and they both 
have advantages & disadvantages :)

Nicolas 'Ryo'

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel