> > 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. > > Fine by me to have descriptive names. > > Note that in the current "sound2" implementation, the client will get an > action name and an item name. The action name is/was supposed to be a > directory, to split/sort files. But client can use it as it want :)
I think the directory method could be wasteful of space if you want to reuse the same sound for a lot of different things. > > 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. > > In sound2, server sends action and item name, the client having > responsibility > to figure the right file name. Maybe not for starters, but I think it would be nice for the client to allow a user to remap sounds/songs to their own choices. > > 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. > > Well, I'd see a "standard sound pack" distributed with the client. > Then people could manually download other packs or replace sounds for custom > needs. > Of course, ideally ftp/http support would be nice (maybe the server could > send > that url to the client), so diffent servers could have different sounds. > Like face, except for sounds :) I think a standard protocol like ftp/http is best rather than implementing it in the client/server protocol. I also tend to agree about having a standard sound pack... optional if people want to avoid a big download, but handy if they can get it. > > 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. > > True. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire