[crossfire] sound2 protocol and issues: sound_chance

[Mark Wedel]

On 09/29/10 09:26 AM, Nicolas Weeger wrote:
>>    Looking at the code, it also seems suspect for all the hard coded sound
>> values (most all sounds), in that they are looking at an object that does
>> not have any sound information defined - it is looking at skill values,
>> monsters, etc, as for the chance of the sound being generated.
>>
>>    In the ideal world, all those hard coded sound values go away - all sound
>> information comes from objects, so only objects that have sounds defined
>> generate noise, and in those cases, if the object does not have the sound
>> information defined, that would be a bug in the object.
>>
>>    However, the current code does not really seem to support sounds coming
>> from the objects - there is no 'sound_type' or 'sound_name' field in the
>> object.
>
>
> The idea was to have sound for many actions, so instead of having fields, the
> server would just send the action - "cast", "move", and such.
> That name is indeed hard-coded.
>
> The sound is then completed by the item's name, from which derives the final
> sound.
> Server sends action and item's name.
>
>
> So you'd have:
> - action "move" on a monster "goblin", client could find the "move_goblin"
> sound ; if not found, find the global "move" sound
> - to disable sound for an item, set the "sound_chance" (that one is a field) to
> 0
>
> I choose to send the action's name, because a string is the easiest to extend
> - pretend it's a filename, add new files, here you do, you can have any sound.

  Using a string for action name is probably fine, OTOH, there is presumably a 
finite (and actually quite small) set of actions.  Since right now, all the 
play_sound calls are basically hardcoded on where they get called, putting in an 
integer type would be fairly easy.

  That would mean there is the potential for the client getting an event type it 
doesn't know how to handle - but at the same time, if the client doesn't know 
how to handle that event type, it would be equally likely it would not have a 
matching sound file for that even either.

  But that probably is not that big a deal - it maybe saves a few bytes using a 
binary code instead of string.

  I sort of disagree with using the object names as the key however.  If I make 
a new map and put a boss creater on it called 'bob', which lets say is a goblin, 
the client would get a 'move_bob' sound - it probably won't have a sound for 
bob, so falls back to the default move sound, which may be less appropriate than 
the move_goblin sound.

  But even using archetype names is somewhat problematic - I could certainly see 
adding a new archetype of which an existing (but non default) sound is ideal, 
but there is no way to have the client use that, save for an updated sound file 
for the client.

  It would seem that this also requires that the client does in fact have a 
potentially very large sound file which lists many archetype names and actions 
and what sound file should be used for them.  While that exists now, I still 
think it would be reasonable to have some level of aliases on the server.

  The problem I otherwise see is that someone adds some new archetypes but 
doesn't know anything about the client sound files, so it just uses default actions.

  In a sense, this becomes similar to faces in many regards - we don't have the 
image an archetype use get derived from the archetype name, rather they have 
their own face field, so multiple archetypes can use the same face, and there 
are even ways to change the face.  Having sounds based on archetype name would 
seem to make it really hard to ever change the sound an object generated if one 
wanted to do it for some reason.

  For example, we first presume that there are default sounds for all actions 
(attack, move, apply, etc).

  Let us suppose I want to put a special goblin thief on a map.  I don't want 
its movements to make any sounds, but I still want its attacks to do so.  I 
don't see any way to do that right now.

  The fact that sound_chance is global for all sounds the object makes seems 
less than idea.  I could imagine one might want a 'sound_chance 25' for attacks 
(simply because so many of them happen, especially from monsters, you would just 
get a huge jumble if all were played), but want a 100 chance for some other action.

  I know this gets outside of the scope of this conversation, but if we are 
going to get serious about sound support, we should probably figure out what we 
really need and figure out best way to do it.