[crossfire] 2.0 object-type refactoring

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
>>   Yes, all of this should go through a common code path, but saying those checks 
>> should be in the 'command' code may not be the right answer, depending on what 
>> the command code is defined as.
> What I'm saying, is that 'character initiated' actions should be
> separated from 'raw actions'. In particular, in some way such that all
> 'character initiated' calls follow a common code path that only applies
> to the 'character initiated' aspects. I was thinking that only 'raw
> actions' should be in the callback system. Though now that I think about
> it, one could potentially add in a central location, pl_ob_apply(),
> pl_ob_drop() and similar functions, which would do 'character initiated'
> aspects then run the callback (ob_apply() and ob_drop, etc.).

  I'm not sure if it should really make any difference how the 
operation/callback is happening.

  If there is a callback for dropping objects, then any way they are dropped 
(explicit player command, monster dying, chess being burned up, etc) should all 
use that same callback.

  This gives us consistent behavior.  This is better than cases where different 
things happen, as from a player perspective, that doesn't seem to look right.

  That said, for some operations, there is likely need for some upper function 
that finds/gets the parameters that the callback needs.

  In the apply example, you'd have the case where the player does 'apply bow'. 
In that case, the apply command has to find the object of the correct name, and 
then do the callback.

  If the player applies it via mouseclick in the client, the server has to look 
it up by tag, and then pass into callback function

  Then there could be the other methods (player steps on something like a 
teleporter that causes the apply logic to come into place).