[crossfire] requestable spell lists.

[Mark Wedel]

  Well, to me, the only thing that is likely to change for sp calculations may 
be the attunement bonuses.

  But a couple more random thoughts:

  Using the object id to denote spells is probably easiest, as that is a unique 
value that already exists.  The disadvantage is that it is a 4 byte value, so a 
few extra bytes of data.

  After what gros says, I wonder if we could follow something like the 
updateitem command, eg, a command like:

spelldata <flags><tag><name><val1><val2>...

  where flags denote what data is being sent.

  Thus, when the player logs on, all data is sent (perhaps not some based on 
client preferences), as when the player learns a spell.

  When the player gains a level in a skill, a function could go through all the 
spells the player knows and see if any have changed in damage or sp cost, and if 
so, send the data down (but in this case, the amount of data actually wouldn't 
be much - < 10 bytes/spell (flags, tag, sp, dam).

  Similarly, if a characters spellpaths change, updated spells info is sent. 
Once again, not a lot of bytes per spell (one question is what to do with spells 
that are denied - you can't really update the cost, as it can't be cast.  So I'd 
imagine the client should be 'smart' in that regard and grey them out or 
something.  However, when a spell transitions from being denied to something 
else, we'd need to send the data down, because we don't know the last state the 
data was in (maybe player is now attuned, where last time we sent it it was just 
'normal').

  I'd also suggest that a binary format is used - this is typical for S->C 
communications.  but also, I'm thinking that things like the msg/endmsg may 
contain newlines - if sent binary, no special processing is needed on those.  If 
sent as text with newline (or something else) being a delimiter, some escape 
code is needed.

  In addition, if text form is used, my <10 byte probably increases a bit (3 for 
flags, maybe 7 for tag, 2-3 for sp and dam values, and add in spaces - maybe 
talking 20 now).  But in addition, packing and unpacking binary data is just 
easier and faster.