Tim Rightnour wrote: > > On 06-Oct-01 Mark Wedel wrote: > > I do think the easier approach is to just clean up all those multiple > > meanings. This may mean adding 20 or so new fields to the object structure, > > but > > see not above about memory not being that big an issue. And of course, call > > these these new elements something that makes sense to their purpose, and not > > something like 'last_heal', which has some meaning for skill objects when > > using > > permanent experience (or food representing charges in a wand, etc). Some of > > these things could have names that are used across object classes - you could > > add a field called 'uses', which could represent both the wand charges as > > well > > as how much a teleporter could get used (not that there is any functionality > > like that right now, but IMO, rather than things being use_once or use > > forever, > > having charges on other attributes would probably be useful). > > I really like this idea the best. I think it gets everyone what they want, > without having to rewrite the whole engine. And this can also be done in a piecemeal fashion. One can decide to fix up one field, and update the code, and not touch any of the other fields that maybe should get done at some point. The only slightly tricky part is legacy/compatibility information, eg, when loading up, you would need to know that being this object is a wand, the 'food' value really needs to get put into the uses field. But even that is just a bunch of checks - probably best done after the object is loaded, as there is no current requirement that the fields in the object be in any order. Its bad practice for objects in maps to use an arch and then change the type (better to use the right type and change the face), but it may be done in some places.