> 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