[crossfire] sound2 protocol and issues: sound_chance

[Mark Wedel]

On 09/26/10 02:38 PM, Kevin Bulgrien wrote:
>>> I retract the "I think sound_chance should be dispensed with".  I finally
>>> found the mail list note that mentioned some changes to sound so it could
>>> support random ambient sounds to improve overall immersion in the game
>>> environment...  Still, the idea that 0 behaves the same as 100 seems
>>> compatible with this.  Any objections?
>>
>> I'm not against it (though it breaks the "0 or empty by default" rule that is
>> always used elsewhere), but sounds should be defined anyway for archetypes and
>> other things, so it shouldn't be too hard to add the "sound_chance" line at
>> the same time.
>>
>> As for why there is no sound_chance defined for now, the reason is that I
>> expected sounds to be added incrementally, one sound here, another there. So
>> no massive changes, but progressive ones.
>> Alas, never managed to do those changes.
>
> 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..

  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.

  As such, I think it would be reasonable that for the existing hard coded sound 
types, it ignores the sound_chance value.

  As far of better sound support, I think sound information needs to be an 
object attribute, but that would likely require a different sound playing 
mechanism (I'd favor a string approach, or if integers are going to get used, 
they should probably get moved to shared/newclient.h)