[crossfire] requestable spell lists.

[Yann Chachkoff]

>One thing that was suggested by gros on IRC earlier was almost a
>hybrid approach, instead of having a stats value that says what type
>of change has occurred, you have a stats value that contains a number
>for the spell object, these would be assigned sequentially, and be
>unique for any one player on each run of the server. (everyone would
>have their spells numbered 1,2,3,4, etc.)

>Then, if ever a spell was added or removed (by moving the attunement
>into a seperate stat, and sending only the base cost, this can be the
>only time an update is needed), the stats command can send the number
>of the spell that was changed, and the client could then requestinfo #
>and get back only that spell. (this was my understanding of gros'
>suggestion, I hope he will clarify if I misunderstood some detail)
>

Well, not quite.

My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached.

My vision of the communication scheme would be:

C->S: spell <id>[<fields>]

Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player.

The optional <fields> argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose.

S->C: spell <nrspells><id 1><information 1><id 2><information 2>...

This is either an answer to an explicit C->S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells.

The information field would be something like this:
- <typeofchange> (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=).
- <name> (string): The internal name of the spell, as used in cast or invoke commands ("burning hands");
- <caption> (string): The visible name of the spell, as displayed by the client ("Small Firestorm of Lhangwival"). The client is free to do whatever it wants with its value.
- <cost> (16bit): The base casting cost.
... and so on.

The information content would depend on the content of the C->S spell <flags>/setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent.

The S->C spell message is sent as soon as its trigger (reception of the C->S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process).


Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK.

I'd also like to underline that IMHO the client should never ever have to compute any value from a "base value" sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server.

Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things.   I also used a generic "spell" name for the command names - for what matters, it could in fact be "requestinfo spell/replyinfo spell", or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case.