Well, to me, the only thing that is likely to change for sp calculations may
be the attunement bonuses.
But a couple more random thoughts:
Using the object id to denote spells is probably easiest, as that is a unique
value that already exists. The disadvantage is that it is a 4 byte value, so a
few extra bytes of data.
After what gros says, I wonder if we could follow something like the
updateitem command, eg, a command like:
spelldata <flags><tag><name><val1><val2>...
where flags denote what data is being sent.
Thus, when the player logs on, all data is sent (perhaps not some based on
client preferences), as when the player learns a spell.
When the player gains a level in a skill, a function could go through all the
spells the player knows and see if any have changed in damage or sp cost, and if
so, send the data down (but in this case, the amount of data actually wouldn't
be much - < 10 bytes/spell (flags, tag, sp, dam).
Similarly, if a characters spellpaths change, updated spells info is sent.
Once again, not a lot of bytes per spell (one question is what to do with spells
that are denied - you can't really update the cost, as it can't be cast. So I'd
imagine the client should be 'smart' in that regard and grey them out or
something. However, when a spell transitions from being denied to something
else, we'd need to send the data down, because we don't know the last state the
data was in (maybe player is now attuned, where last time we sent it it was just
'normal').
I'd also suggest that a binary format is used - this is typical for S->C
communications. but also, I'm thinking that things like the msg/endmsg may
contain newlines - if sent binary, no special processing is needed on those. If
sent as text with newline (or something else) being a delimiter, some escape
code is needed.
In addition, if text form is used, my <10 byte probably increases a bit (3 for
flags, maybe 7 for tag, 2-3 for sp and dam values, and add in spaces - maybe
talking 20 now). But in addition, packing and unpacking binary data is just
easier and faster.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
