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