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

[Mark Wedel]

On 09/29/10 09:40 PM, Kevin Bulgrien wrote:
>>>    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.

  One could get around some of that with symlinks (for OS's that support it).

  But as I mentioned in another message, I think the likely scenario is that the 
client will have a file which maps actions and object names to a corresponding 
file to play.

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

  If the client has that mapping file I mention above, this becomes fairly easy 
- look for mapping file in .crossfire (or other default location) and use the 
default one if that is not found.  Whether or not there is any nice interface to 
manager that, or it is up the users to edit that file by hand would really be up 
to the client maintainer to decide - I personally would think there are better 
things to work on than an in client sound adjuster, but that is just me.

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

  Yes - all the above is what I was thinking.

  Standard sound pack that is available as client download (that is really a 
packaging decision) - these sounds should in fact be in SVN, just like the 
limited number of sounds right now are.

  Server can provide URL for client to download additional sounds.  Client is 
not forced to download them, and if the client does download them, it would most 
likely have to store them in the players home directory and default location. 
But that is up to many factors - does the client actually do the downloading and 
unpacking, or just give the URL/bring up a web browser, etc (not that this 
really means anything, but I've noticed a fair number of commercial games 
basically fire up the web browser for updates).

  The one thing I would say is that it is probably desirable to have some 
directory schema so these different sound packs can coexist.  For example:

<installdir>/sounds/default
<installdir>/sounds/metalforge
<installdir>/sounds/invidious

  etc - I don't want my metalforge sound pack to be messing with either the 
defaults or invidious.  At the same time, these sound packs should be treated as 
additional sounds, so that they don't have to include everything.  So the 
client, when I connect to metalforge, would look in the sounds/metalforge 
directory first, and then sounds/default