[crossfire] requestable spell lists.

[Brendan Lally]

It took a little while, but I've now gone and implemented most of the
suggestions from earlier in this thread. The server now sends the data
in binary form, as well as a couple of other changes. The tracker item
mentioned previously has had the associated patch uploaded.

what follows is culled directly from my proposed change to
doc/Developers/protocol.

I propose:

That there be a new setup option:

+       spellmon (0/1)
+           If set to 1 the client has indicated that it wishes to be
+           sent the spell list and updated when it changes.


That the stats command additionally has:
+       -spell paths: if spellmon is set in setup, the bitmask of attuned,
+        repelled and denied paths is sent. These are all 32bits

That the request_info command may additionally cope with:

+     spell_paths (no parameters)
+       This returns a list of all spell paths in the game, along with the
+       number associated with them. This should be used to parse spell_path
+       data in the stats command. The number is a bitmask but is sent as a
+       decimal value.
+
+       All data is sent in text format. Format is:

+       number:name

!       eg

+       16:missiles


That there be new commands as follows:

S->C addspell <tag1> <level1> <casting time1> <mana1> <grace1> <damage1> <skill>
+       <path1> <name1> <display name1> <message1> <spell2 ....>
+       Tells the client to add the spell(s) listed to the list of spells
+       the client knows about. This will be sent at login, and again whenever
+       new spells are sent.
+
+       The fields are;
+       <tag> - (4 bytes - int) The ID number for the spell item. This is
+               going to be unique, for each spell and will be used to refer
+               to it henceforth.
+
+       <level> (2 bytes, signed int)
+               The level of the spell.
+
+       <casting time> (2 bytes, signed int)
+               The time it will take to cast the spell, in server ticks.
+
+       <mana>  (2 bytes, signed int)
+               The mana cost to cast the spell (may be zero)
+
+       <grace> (2 bytes, signed int)
+               The grace cost to cast the spell (may be zero)
+
+       <damage> (2 bytes, signed int)
+               The current damage done by the spell. Note that the meaning of
+               this number is to a large part spell dependent, what damage it
+               actually does will depend on how the spell works.
+
+       <skill> (1 byte, unsigned int)
+               The skill that the spell uses to be cast, if zero, no skill is
+               used in the casting of this spell.
+               The numbers are the same as for request_info skill_info
+
+       <path>  (4 bytes, unsigned integer)
+               The path that the spell belongs to.
+               The client should determine the effect of this by comparing
+               these values to both the spell_paths request_info data and the
+               stats info concerning attunement/repulsion, etc.
+
+       <name> (1 (non-zero) length byte, followed by that many bytes
of ascii text)
+               This is the name of the spell, and should be sent to the server
+               in order to cast/invoke it.
+
+       <display name> (1 length byte (which may be zero) followed by that
+               many bytes of ascii text)
+               This is the name to display to the player regarding the spell.
+               If length is zero, then the <name> should be used instead.
+
+       <message> (2 length bytes (which may be zero) followed by that many
+               bytes of ascii text)
+               The description of the spell. Note that this has an extra length
+               byte because the messages may well be longer than 256 bytes in
+               length.
+
+ S->C updspell <flags><tag><vals>+
+
+       This updates some spell (of tag) with new values. The flags are 1 byte
+       and determine which values have been updated, and should be re-read.
+       Not all fields may be updated by this command, only those that can be
+       changed.
+
+       If new fields are added in future, they will extend the flags bitmask
+       and the order will remain the LSB order of the flags - that is, the
+       value associated with bit 1 set is sent first, then bit 2, etc.
+
+       The format of the values is same as the addspell command above.
+
+       Only one spell can be updated with the updspell command.  A spell
+       command should have been sent by the server before an updspell
+       command is set.
+
+ S->C delspell <tag>
+       Tells the client to remove its information about the spell Tag is a 4
+       byte value, the same as the one sent when the spell was added.

Currently the checks for spell updates are in level_adjust and in
fix_player, I think that covers any way for spells or damage to
change, if I am missing any, please let me know.

Other than that, please reply with comments/criticisms/suggestions/flames etc