[CF-Devel] Patch: new sound proposal

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      Ok, finally did some code for new sound support.
     
     >
     
      I prefer to submit it here before committing :p
     
     >
     
      Only server-side code is here, client or client/server one isn't there yet.
     
     >
     
     
     >
     
      Attached a diff, and a sounds.c that should go into common.
     
     
  A few notes..

>
     
     
     >
     
      Sound works like that:
     
     >
     
     
     >
     
      * add to archetypes something like:
     
     >
     
          Object waybread
     
     >
     
          ...
     
     >
     
          soundinfo
     
     >
     
          apply eat_waybread 100    <- a sound name, and a probability.
     
     >
     
          endsoundinfo
     
     >
     
          end
     
     >
     
     
     
  Looks fine.


>
     
      Code-wise:
     
     >
     
      * items have a 'sounds' field, containing for some event codes the 
     
     >
     
      sound(s) to be played. Multiple sounds per event, random one chosen (or 
     
     >
     
      none played, depending on total probability)
     
     
  Looks good.

>
     
      * a 'sound_cache' field helps know quickly if a sound is defined or not 
     
     >
     
      for an event
     
     
  Looks fine, although the suffixe SE for the query/set/clear isn't all that 
intuitive IMO.  Better woudl be QUERY_SOUND_EVENT (or FLAG, or the like). 
Otherwise, if someone run across this someplace in the code, it would be 'what 
is an SE?'

>
     
      * right now, only events are 'death', 'move', 'apply', and only that one 
     
     >
     
      is used (from manual_apply). There are #define in sounds.h for those 
     
     >
     
      codes, and an array with 'readable' names in (new) common/sounds.c
     
     
  Minor note - I usually like to leave '0' not defined for anything - in that 
way, it is easier to tell if it hasn't been properly initialized or the like.

>
     
      * if a sound has no sounds for an event type, archetype is checked.
     
     
  not good behaviour.

>
     
      * when loading, sound info is cleared, since archetype is used by default.
     
     
  not good behaviour.

>
     
      * also, sounds structure is always saved if not null. Because if not 
     
     >
     
      null it means item has a special sound structure, so should be saved.
     
     
  not good behaviour.

  For all other objects, it is normal practice for the object to inherit the 
properties of its archetype, and those properties, not the archetypes, and used 
from that point on.  To change that expected behavior probably isn't a good 
thing.  I'm curious the rationale for making that change.

  If it was a matter of just being able to know if the data should be saved out, 
surely a flag could be used for that.

  Is this just a way to try and save memory?  If so, it isn't all that efficient 
- most of the copy objects calls are dealt with loading, and then we free that data.

  I'd also think you're going to get odd behaviour with respect to generators or 
anything else that generates an object 'in game' - the data isn't getting 
cleared out in those cases, so when it goes to save them, it will save all the 
sound info.  This then creates problems down the road - if the archetype is 
updated with new sounds, all those items won't get it if they had any sound info 
before.

  I wonder if perhaps a better approach would be to have a flag in the object 
itself to denote if this is custom information or if the soundinfo is in fact a 
private copy or points to the original.

In that way, copy object and all that stuff works fine, doesn't use much memory, 
and the code is simple.

  If the loader then sees any sound info, it then clears that flag and copies 
all the sound info so it is now private.  And in this case, saves it out.

  Also, given the current code, the behaviour seems to be that any sound info 
replaces existing sound info, and is not merged.

  This probably makes sense if I am overriding an event already set.  But it may 
not make sense for a different event.

  For example, right now there are 3 sound events.  Suppose I create a monster 
on a map that has a custom entry.  Now, as time passes, more sound events are 
added, including one for that monster.  Now I may still want my custom monster 
to get those new sound events (imagine the pain of this if a fair number of 
monsters/objects have custom values).

  So I wonder if something within the object sound info itself like:

clearsoundinfo <event>|all

  might be reasonable?  Multiple lines could be used to clear multiple events. 
Code to do that is probably relative easy - the more complicated part is knowing 
to save that out (This is more an issue if you think about objects that players 
pick up - ideally, you probably want them to keep getting updated sound info). 
I'd think it'd be pretty easy within the sound event itself to have a 'loaded 
from object' flag, so you know which ones come from the object, and which ones 
are customized.  Perhaps also a flag like 'cleared'?

  Thus, there could be a sound event allocated, with no sound, just to record it 
is a cleared event.

>
     
     
     >
     
      what needs yet to be done:
     
     >
     
      * change the collect script to get merge sound info from (yet to be 
     
     >
     
      done) .snd files
     
     >
     
      * make a way for client to get that list
     
     >
     
      * add a field for 'new sound support' to NewSocket, for backwards 
     
     >
     
      compatibility
     
     
  Documentation for all of this.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel