[crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[13885] server/trunk/doc/Developers/protocol

[Mark Wedel]

On 09/26/10 02:48 PM, Kevin Bulgrien wrote:
>> Extract from the Developers/protocol:
>>
>>        Change background music. Server will send NONE as the string to stop any
>>        music from playing. This song data is set in a map property.  (Due to
>>        someone forgetting to update this file when he/she implemented the
>>        command, it is unknown what exactly should be done with the string
>>        parameter, is it a filename? If yes: relative what?)
>>
>> That wasn't precisely defined during server implementation, because client-side
>> wasn't yet implemented.
>>
>> There were 2 global ideas:
>> - it's a song or file name, the client knows where to find it (either bundled or
>> to be downladed from some site to be defined)
>> - it's a mood name (eg: "dangerous place", or "port area") that the client
>> would pick up to arbitrarily decide what music to use from its pool
>>
>> Arguments I remember are that it would be better to have music match on the
>> clients, because if you were playing together it would be weird to have
>> different musics at the same place.
>>
>> So the best idea is probably to make that a filename.
>>
>> Of course that means to wonder where the client should get that one, and how
>> to handle custom background musics.
>
> I agree that using the name as the base file name is a good idea with the
> exception of specifying path and extension.
>
> I think it should be a case-insensitive name, not a file name... i.e. with no
> file extension like .ogg or .wav, and no path.  The idea being that the client
> should be able to determine how to get files, what format of files to play, etc.
> It is important that the name not include path.  This was a weakness of the
> cfsndserv program.  The case issue is to prevent the possibility of having
> similar names that vary only in case as these cause problems with windows.
>
> With it being a name, it could be up to the client to use it as a filename, or
> simply as a unique name that a player could map to his/her own choice of music.
> I prefer to require that the name not have spaces for various and sundry
> reasons.

  I think that was one reason I was more in favor of symbolic names 
(dangerous_song, port_area) - it seems in many cases the client may do some 
amount of remapping for what songs it has.

  OTOH, using file names does not preclude that - it can just make it harder if 
one adds a new file name - if the file name is really arbitrary, the client 
would really have no idea - but perhaps more to the point, a person would have 
to listen to that new file to try to figure out what the song is.

  So even if it is file names, I would suggest that the names be descriptive of 
what the sound is/its intended effects, and not something like 'mwedel_5' to 
denote it is the 5th song I've done.

  Currently, the server has nothing to do with the sound files either - for the 
sound effects, it sends a number of the intended effect - for the songs, it just 
sends the song name, but has no idea if that name is valid.

  I don't see adding download support for sounds to the server - a lot of 
bandwidth there.  I would see that possibility of the server telling the client 
where it could download the songs via some well known protocol (ftp, http), and 
if the server has added custom songs, that location should point to a location 
that includes those custom songs.

  As far as different clients playing different songs - even with using 
filenames, that could still happen (although, probably pretty unlikely for a 
client maintainer to get rid of a song/replace it, given limited number of songs 
in the first place).  But even with that sound, IIRC, the music command is sent 
when a player enters a map - so it is almost a sure thing that while 2 different 
players are hearing the same song, it would be out of phase with respect to each 
other - thus it could seem to be a different song.