[crossfire] 2.0 object-type refactoring

[Mark Wedel]

Alex Schultz wrote:
>> It may be better working on getting all of this infrastructure/callback methods 
>> in place, and implementing one type of object using them instead of focusing on 
>> the specific callback method (the web page mentioned doing all the apply stuff). 
>>   Why?  That way, if someone does write code for a new object type, all the 
>> pieces are in place so they can use the new method.  If only the apply callback 
>> is implemented, they can use that logic, but are left using old coding method 
>> for the other areas, that then needs to be converted down the road.
>>
>>   Also, by doing all the different callback methods, it provides better coverage 
>> of the callback logic, eg, if there are issues with any of the methods, they 
>> will be found sooner vs later.
>>   
> Well, my original thinking, was that if I were to do it by completing an
> object type, instead of a callback type, then it would be somewhat of a
> pain to make it redirect to legacy methods for other object types not
> yet implemented in the new system. What's your view on that issue?

  Some of it depends on how this is done.

  If you replaced the specific calls to apply, drop, etc as they are sprinkled 
throughout the code, then doing one type of function is easier.

  However, what I was thinking is those functions would still exist, but instead 
of the case statements they have now, they would have something like:

  if (callback_Exists_for_this_type) do_callback()
  else { do switch statement}

  In that model, doing a few types at a time is easier to do.

  I also think you still want to have common top level/generic functions so that 
you can have some common code.

  An example of this (albeit a trivial one) is checking that objects are paid 
for before doing an apply.  Rather than have that duplicated in every object 
type apply function, you have it in the one generic one that calls the specific 
ones.

  A better case here may be something like examine/describe item, where many 
objects may have some specific/unique properties, but many also have common 
properties (value, cursed, applied, etc).

> 
>> Second, if we're going to be writing all new functions, we should use some other 
>> 'best practices'.  In particular, for anything that would return a string value, 
>> they should be modified so that a string pointer (and length of that pointer) is 
>> passed in, instead of using static return buffers.  This will assist if we ever 
>> thread the server, but it will also help prevent a few bugs (related to this, 
>> sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, 
>> and strncpy instead)
> Well, I wouldn't say necessarily writing all new functions: I believe
> some existing functions can be tweaked fairly easily to fit into the new
> system. However I believe that when moving functions that map well over,
> we should hand review them anyways, and perhaps use a checklist of
> things such as those issues you mention like avoiding static buffer returns.

  I think a lot of existing code can be re-used.  I'm not sure how many 
functions can be re-used completely.

  I suppose the apply code is a reasonable example.  For some object types, the 
logic has been broken apart into its own function.

  But some object types are still handled within a case statement.  In those 
cases, you'll basically need to write a new function.

  But this really needs to be thought at the time of callbacks, as you'll need 
to set up the function pointers to consistent.

  To be honest, the only case I can think of right now would be the 
describe/examine object logic.


  Other thought not related to the above:
Given this is a major restructure, would it make sense to collapse/redo some of 
the types, particularly the equipable equipment?

With the change of equipment (body info), for the most part, there is not the 
need of all the types right now (boots, shield, helmet, etc) Really, the only 
types (or subtypes) needed are likely:

WEAPON - some classes or gods are prohibited from using them so need to know 
what are weapons and what are not.
BOW - like weapon above, but these also fire other objects
ARMOR - some classes can't use armor, so need this info.  helmets, boots, 
gloves, shields, etc fall into this.
MISC - anything else equipable that is not in the above that conveys adjustments 
to the players (eg, wands/rods/horns are not here, because they do not provide 
ac, protections to the player simply by equipping them).  But things like rings, 
amulets, necklaces (some of these don't exist but are being used as examples) 
would be in this category