[CF-Devel] Sound proposal

Fri Apr 16 00:07:53 CDT 2004

Nicolas Weeger wrote:
>

      Hello.

     >

     >

      There has been some discussion about sound support.

     >

      If no one works on it, i'll fix it, and try to improve.

     >

     >

      Here's how I see the stuff:

     >

     >

      * add a new line for archetypes, 'sound <event name>, <sound file>, 

     >

      <optional parameters like relative volume etc>'

     >

      with <event name> something like 'cast, die, move', you get the clue

  Do you intend to have support for more than one sound file for the same 
logical event (eg, two different deaths sounds, and when one is required, it 
chooses randomly)?  If so, what is the syntax for that.

  Also, unless the commas are needed for something, I'd just assume to leave 
them out - extra punctuation probably only really adds confusion.

  In addition, I think that an english text description is needed, that denotes 
what the sound sounds like.  Thus, in the case of a death sound, it may be 
'horrible cry'.  Thus, if the client doesn't have sound, or the user is deaf, 
the client could display something like 'You hear a horrible cry'.

>

     >

      * put .raw files with archetypes

     >

     >

      * assign generic sounds to archetypes. Ex: goblin archetype gets a 

     >

      'sound die, goblin_horrible_death' line

     >

     >

      * change collect.pl to copy .raw files to crossfire/share/sounds (or 

     >

      wherever we want) and generate a /share/arch_sounds file containing a 

     >

      simple list with filenames

     >

     >

      * server will then read this file, give a unique identifier to each 

     >

      sound. When loading archetypes, link sound_event to that identifier

  Presumably, a lot of that would follow the same general logic as the image 
type code?  Note that for the images, it is part of the collect process that 
assigns numbers to each image.

>

     >

      * client can request arch_sounds file, then individual sound files (like 

     >

      1024 bytes by 1024 bytes)

     >

     >

      * when a sound event needs to occur, server just sends the unique sound 

     >

      identifier

     >

     >

      Client can then have a sound cache, based on filename.

  All looks OK.

>

     >

      An extension which could be nice: allow map-specific sounds. Like a 

     >

      special sound when your mega-monster dies :)

     >

     >

      I'd see this this way:

     >

      * add sounds in same directory as map file, or in a sound subdir 

     >

      (whatever). This way, we know which sounds go with which maps. Also, 

     >

      give a unique sound to the file - like <mapnams>_<sound_event>.raw

     >

     >

      * at some point, collect the sounds, and copy'em to the same directory 

     >

      as other sounds from archetypes

     >

     >

      * override sound event on object from archetype, as any other field

  I'd just assume not do this - it creates a lot of work - if you really want 
something like that done, it should be outside the server code, and instead part 
of the collect script (eg, it could examine the maps directory looking for sounds).

  However, I'd think that this would generally not be especially popular, given 
it is sure to increase the amount of time it takes to collect the various bits.

  I also wonder how likely it is that new sounds will show up that just can't 
get plopped into the arch directory.  I just can't see new sounds showing up so 
often that putting them in the arch directory and running collect would be much 
an issue.

  If someone is running their own server, they could just manually collect the 
sounds if they have added some custom ones (the collect script, btw, should deal 
with sounds liek it deals with images - it doesn't care that they are 
referenced, it just looks for suffix.  Eg, the collect script considers anything 
that ends with %d%d%d.png as an image file.  Similarly, anything that ends in 
.raw should be considered a sound file.

  Thus, you could have a directory in the arch area just called 'sounds', to 
toss in these sounds from maps, or other generic sounds that you still want 
collected (ideally, there shouldn't be many hard coded events, but there is 
likely to be a few of them).  Thus, may also want something like .snd files that 
describe sound events, eg, something like:

<event> <sound file> <sound options>

  So that you can specify the login event, logout event, etc.

  Now personally, I don't really see much reason for the server to store the 
sound files and serve them - as said above, I can't see sound files changing 
that much.

  What would make more sense to me is that the sound files (and description) are 
in the arch directory as described.  When collect runs, it finds all the sounds 
files and generates a soundlist file, which has 'unique_id sound_file' type 
syntax (see bmaps).  However, it does not collect the sound files itself.

  Instead, the client collects the sound files, and the collected sound files 
are shipped with the client (perhaps even in CVS, although it would seem odd to 
have two copies of the same file in CVS).  The client requests that sound_list 
at startup - if it has a sound file, great, if it doesn't, probably not a 
horrible loss (and the user could grab it if they wanted to).

  I say that in that I just don't see new sounds showing up that often, and that 
it is not likely that missing a sound will be a critical event (like missing an 
image could be).  It'd seem that not having the server do the sound stuff 
simplifies it, and saves bandwidth and other resources on the server.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

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