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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
