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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire