Quick thoughts:
1) Why not just go for a straight push approach, eg, have the server send
updates whenever needed?
It seems as written now, you'll get the case like:
S->C: stats ... spells have changed
C->S: requestinfo spell_list
S->C: spell_list ...
I just don't really see what we get by having to do it via a purely request
basis. I can't really see the client not sending a request when things change.
If there is the potential of client only sending requestinfo based on what
changed, that could also be done with a push approach (setup spellmon val, and
based on val determines what events we send spell updates.
the other advantage of push is we can be more bandwidth efficient. If a
player learns a new spell, only need to send that spell down the line, and not
all the spells if done on a pull approach.
2) I wonder if more spell info should be sent. For example, base damage values,
lore information, etc. If we only send spells on push, bandwidth shouldn't be
that costly, and it then gives the player more info to choose spells (fireball,
24 dam, ...). Related, I think it'd be easier all around to send the spell path
information as a bitmask - saves some bandwidth, and the bitmasks values should
be pretty stable (can't remember last time a new spell path was added, and even
then, the client could just display something like 'unknown' or whatever)
3) Related to point #2, I wonder if it would be 'easier' to just send the base
values for costs that the server users to calculate real cost.
Otherwise, whenever the player equips an item that changes their spellpaths,
you get the case of potentially all the spells changing in value. Level changes
can also effect costs, and that is likely to happen when you really don't want
more data sent down, eg, in combat. The only change needed for that to really
work would be to send down the players current spellpaths in the stats command.
Thus, the only time in this case you really need to send spell information is
when the player learns a new spell. That said, it does complicate the client a bit.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
