[crossfire] sound2 protocol and issues: sound_chance

[Kevin Bulgrien]

> > The problem is that the sounds already defined were disabled by the change,
> > so it is not a matter of simply not implementing things incrementally. 
> > All that used to work no longer does..
> 
> I don't remember disabling previous sound support, but maybe I indeed did, 
> considering not many people used it...

Because sound_chance is not restrictive on what it operates on, the absence of
any sound_chance in any arch completely disables all sounds...  Ragnor is the
one that clued me on it.  The client never, never received any sound messages
until the sound_chance check was disabled.

The old sounds were number based.  sound2 sends strings where a number is
expected.  That borked up the client sound.  It might be that numbers are
still passed for old sounds and I didn't notice because I kept seeing the
strings after I deleted the sound_chance check.

Anyway, on trunk, all sounds are disabled because of sound_chance.

> > It also seems somewhat counter-intuitive to require adding something to an
> > arch for a feature that should be the default behavior.

sound_chance is what requires adding things to arches as I think that is the
only way to set sound_chance non-zero, but I don't really know the code.

> > Perhaps an alternative is to add a property that must be present for the
> > new feature to be used.  I think that it is not that great to have to go in
> > and find all possible items that should emit sounds and modify them.  It is
> > almost inevitable that items will be missed.  Basically, I want to get rid
> > of the patch I have to have to play sounds because it means all public
> > servers don't work for sound, and a small simple change seems better than
> > a lot of arch and/or map changes.
> 
> Actually, you don't need to add anything to archetypes.
> 
> To have a sound, have the client use setup sound2, then when you get messages 
> with "sound2 (params) action name", find the file "action_name.ogg", play it.

The sound_chance feature prevents it from reaching the client.

> The idea was to just send free-form strings, to enable clients to "override" 
> sounds.

Really, on trunk, sounds are entirely disabled at present due to these changes.