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

[Kevin Bulgrien]

> >   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.