[crossfire] Client Skill Handling, Re: New crossfire todo list

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
>> This should probably be taken to the next step, with the client providing some 
>> nicer dialogue for this, eg, a menu item like 'inscribe scroll'.  The client 
>> would then present list of possible items (based on client type attribute) and 
>> list of spells, and player chooses.
>>
>>   Of course, the client still has to send the actual request to the server, and 
>> the server would still have to validate if it works.  Thinking about this, the 
>> logic for this on the server side could actually do most of the work with very 
>> little changes.  Eg, client does something like:
>>
>> C->S: inscribe <scroll tag> <spell name/identifier>
>>
>>   The server side command for that could find the object of scroll tag, save 
>> away current marked object, mark the scroll object, store away current ready 
>> spell, ready new spell, call inscribe code, and then put back the marked object 
>> and ready spell.
>>
>>   OTOH, would probably be better for the inscribe code to take the inscribe to 
>> object and spell object and just go from that, as that would be cleaner.
>>
>>   I am really thinking, however, that having the client handle most of the 
>> presentation of this is the better way to go.
>>   
> Actually, I'd be inclined to do something such as a more general
> skill-usage protocol. Something like:
> 
> C->S: client_use_skill <skill name/identifier> [ob1:<object tag>]
> [ob2:<object tag>] [spell:<spell name/identifier>] [message:<text
> length><text>]
> 
> Which could be used to make clientside menus for other skills and such
> things.

  But can all skills be generalized to that regard?

  Most skills probably don't have any use for spell information, etc.

  It may be possible to abstract that a bit, and have a bitmask type of thing 
which denotes what data it is sending along (marked object, apply object, spell 
name, etc)

  But for that to work, all the actual skill code must have same 
semantics/calling structure.

  And the problem right now, is that there is no real way to do this - for the 
server to take that arbitrary skill/object data, the best it could do now is 
fill various fields in the player structure (marked object, ready spell, etc), 
and then invoke a general 'use_skill ...' - that would work, but would probably 
have some bad side effects.  In particular, I think that the player/client would 
see messages like 'switched to spell ..', 'switched to skill ..', etc.  And then 
the use_skill code and the like is basically undoing/redoing a fair amount of work.

  IT would be cleaner and more efficient for the dispatch code to call inscribe, 
bowery, etc, with the target parameters, so we can save the work of updating the 
player structures.  That logic could get pulled from the existing code, with 
manual use_skill using those same functions, but passing in the normal defaults 
(marked object, etc)

  But what would probably the best first step is to identify all the different 
skill usages and what parameters they may take and how they should act.  That 
way, things can be properly examined and determined, like 'this skill would 
ideally use 3 objects, etc'.

  Aside from inscriptions, I can actually think of many/any of the skills that 
take optional parameters.  The item identification skills just do the entire 
inventory.  And I thought the item creation skills basically look at the players 
surroundings to figure out what to do (player is on a bench, this is the junk on 
the bench, he is trying to make ...).  Or do the item creation skills actually 
require the player to state what he is trying to create?