> With the change in spells, the sound handling for them sort of broke. > > Before the change, each spell had a unique number. There was a sound > associated with each of those numbers. > > With the spell code, there is no longer a unique number per spell, so > there is no way to simply identify a fireball based on the object (you > can identify spells by subtype, but firebolt should obviously have a > different sound than lightning bolt). What about sending the spell's name to the client, so it could play the 'right' sound? Like 'fireball', 'frostbolt', ... > The proper way to deal this is to re-do the sound system. > > the general idea I have is to add a new structure like: > > struct soundlist { > char *sound_name; > uint8 volume > uint8 play_event > ... any other flags.. > struct soundlist *next; > } > > where play_event could be set to things like SPELL_CAST, SPELL_END, > APPLY, MOVE, etc.. > > Thus when an object is used, check to see if any of the events apply, > and if so, send the appropriate sound event to the client (to speed > things up, probably add something like a sound_flags to the object > structure itself, and have the play_event be a bitmask, so if an object > is applied, the code can simply look at the sound_flags, and only if the > event there is matched, do we have to bother going through the sound list). Seems nice, but I don't see the need for the volume - since it's a client setting, not a server one. And, if we redo the sound structure, could I suggest adding sound direction/propagation information too? This way, in the future, clients could add doppler effects to sounds, making'em coming towards, stuff like that. > Believe they are at 11025 sample rate. I'm not sure if the sounds > themselves are stereo, or if the sound module converts them to stereo > when played. Many thanks. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel