> Yes - there is compelling reason - subtype might very well be used in > the future as additional matching code. > > Also, changing subtypes may have bad effects down the road. > > subtypes are extensively used in the new spell code. And I personally > see adding more objects to use type/subtype (really, all the stuff a > player may equipment should be of something like 'type equipment, > subtype shield/weapon/armor/helm/....'. Hum, that's exactly how i use subtype in my building code: general material has type 161, and subtype is used to discriminate between what you are building (floor, wall, other items). Also, from your comment I think I wasn't clear enough: the question is, rather, would it be bad if an artifact could override the archetype's subtype (using the 'subtype' in artifact, as weight/title/stats can be overriden)? You just need to NOT use this field for most items, and it'll make it easier for my building patch :) Actually, problem occurs (in my building case) because I implemented different 'instances' of material using artifacts, not archetypes. I thought 'they all share some fields, like type & stuff, so i'll make a global ''virtual'' archetype and different artifacts'. Now of course I can reimplement using different archetypes for different materials, instead of one archetype and different artifacts (would remove the need for my treasure.c hack) > Arguably, the artifact stuff could be done better (have some area which > lists what to match against, and another area which lists what to set). > > However, at some level, I'd just rather the artifact file disappear or > otherwise get completely redone. Couldn't we use something like what is used for archetypes? Add .art files that get collected by a script to make artifact file? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel