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
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
