[crossfire] 2.0 object-type refactoring

[Mark Wedel]

Alex Schultz wrote:

> Well, the way I was thinking of doing it, would be to replace specific
> calls to apply, drop, etc as they are sprinkled throughout the code, and
> keep common code such as you say, in a "common" subdirectory of the
> types directory, and then have the callback called by ob_apply(), call
> something like ob_apply_common() at the start of it's code.
> IMHO, with this method, the best way to handle legacy non-separated
> logic would be to move that legacy logic to the "types/common"
> subdirectory, and set it up so ob_apply() and such will call that if it
> can't find a callback registered for the type.

  That works I suppose.  You do get into various questions that have no clear 
answer.  Like 'should the main drop function be in the commands.c file (since it 
is a command the player issues) or should it be in the types/common.c file'

  I'd be somewhat inclined to have the command logic still in the command 
(c_...) files, and from there, it does the callback.  It seems (to me at least) 
that is a little better - the basic command logic is still in the commands file, 
and the actual object specific drop is in the types area.  But I can also see 
the other point - lets put all the common object operations together.

  I also do think that if there are standards in place that all objects should 
follow (like not letting unpaid objects be used), that should be enforced, and 
not something that is affected by object type.  If some objects really should 
change the behaviour, I'd be more inclined to say they should have specific 
flags for such variations - one reason there are some many object types right 
now is that there is some of that 'if type==FOO, I behave 95% like BAR, except 
for this one little case'.  The problem this leads to is down the road, someone 
says 'which do I use, FOO or BAR', where if there was just a flag which 
controlled that basic actions, that is clearer.

  The other reason I'd like there to be common functions is that I think it will 
make debugging a little easier.  With a single function that then makes the 
callbacks if necessary, I can easily set a breakpoint in there to catch when any 
object of any type does that action.  Otherwise, there isn't any easy way to 
catch 'if any object of any type is dropped' type of thing, unless there is a 
common function that every object type uses 100% of the time.

  But it probably is more stylistically - to me, this seems cleaner:

void action()
{
  some common code
  make object callback
}

vs

void action_for_type()
{
    make_common_call_for_all_types()
    do my specific code
}

  It just seems that if everything is going to call 
make_common_call_for_all_types(), why not just call that in the first place?


>>   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?
> IMHO This should be done as well, though one question is: would it be
> worth completely redoing the type numbers and converting all of the
> maps/arches? Or should we try to keep the numbers the same where
> possible, and have the loader change type values that were collapsed to
> the new value?

  If maps are changing the object types, they are broken.  While it is sometimes 
done, changing object types is pretty much never good behaviour, because other 
aspects of the object are not updated.

  However, for the archetypes, they should be updated with the new numbers - it 
shouldn't be hard to do, and is definitely the right approach.