[crossfire] New crossfire todo list

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
>> - Change inscription - instead of looking at range field of the player,
>>    have the spell to be inscribed part of the inscription command, eg
>>    'inscribe scroll of identify'
>> (is this still something that needs to be done?)
>>   
> Yes. When inscribing spell scrolls, one needs to do something along the
> lines of "mark scroll-to-inscribe-over; cast meteor swarm; use_skill
> inscription". The change suggested there would make it so one would use
> something like "mark scroll-to-inscribe-over; use_skill inscription
> meteor swarm" instead.

  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.

> 
>> - Generalize the code better - split between 'rules' and 'engine'
>> (see TODO for more info - wonder if we really want to go that route - the code 
>> re-orgs as suggested is different from this, so maybe it just goes away as 
>> something TODO?)
> Personally I don't think we want to go that route, however the suggested
> code re-orgs such as what I proposed a while back in the mailing list,
> would as a side affect make splitting the 'rules' and 'engine' easier,
> if at any point we decided we wanted to. IMHO we should do the code
> re-orgs and decide if we want to split the 'rules' and 'engine' after.

  And I'm not sure how much reason there is to split the rules and engine in any 
case.  But if it is easy to do that, that could help in the testing actions perhaps.