[CF-Devel] Patch: new sound proposal

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Mon May 17 02:12:56 CDT 2004


>
     
       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?'
     
     
ok, i'll change accordingly.

>
     
       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.
     
     
same as above :p

>
     
       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.
     
     
>
     
       Also, given the current code, the behaviour seems to be that any sound 
     
     >
     
      info replaces existing sound info, and is not merged.
     
     <some parts snipped>

The logic behind my inheritance choice is to solve the loading 
/saving / changing issue.
When loading an object, first a copy of archetype is made. And then 
object is loaded.
So if sound info gets copied from archetype, then how can we override 
events? Will there be a flag so that, when loading object, first time 
a certain sound event type (apply, cast, ...) is found, clear matching 
sound structure? Seems overkill.
It seemed easier to clear sound info first, then load custom ones, 
using archetype's sounds if not found.

Note that you can override only one event type. As the 
'play_object_sound' is implemented, we query the sound info for item, 
and if not found for archetype.

So you could have in archetypes:
	Object potion_generic
	soundinfo
	apply apply_potion 100
	pick pick_potion 100
	endsoundinfo
and in an object:
	arch potion_generic
	soundinfo
	apply apply_special_potion 100
	endsoundinfo

The item will replace 'apply' with it's own version, but keep the 
'pick' from archetype - thats how play_object_sound works (or i missed 
something :p)

Note that this also solves the saving issue, since archetype contains 
information - thus only 'special' sounds are saved with object.
And if the archetype's sound ever changes, objects will be updated 
automatically if they don't have their own version.

Now my code may be totally wrong, but that's what i was planning on 
doing ^_-

>
     
       Documentation for all of this.
     
     
lol, always the thing i forget :)

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

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


More information about the crossfire mailing list