[crossfire] requestable spell lists.

[Brendan Lally]

On 12/17/05, Mark Wedel <mwedel at sonic.net> wrote:
> Brendan Lally wrote:
> > This could work, but requires a new command in the protocol.
>
>   I don't know why it would require a new command.  the setup command is not
> true/false values, it is setting some variable to whatever value.
>
>   So a 'setup spellmon 6' is perfectly valid.
>
>   And to push the data, the same command could be used - it'd just need to be
> clarified that spellist would represent updates to existing data.  Or the
> spellist command could send optional params to denote what it is updating.

There is no 'same command' the existing implementation uses stats and
request/reply info.

> >>   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.
> >
> > I thought about that, but I can't see how it can be done without the
> > server storing the spell list for each player, which is a fairly ugly
> > way to implement things. (the only other thing I could think of is to
> > abuse the spell objects, and set an update value for each one (added,
> > removed, changed costs, changed damage, etc)
>
>   Same way it is done for most objects - you send it at the time of the event.
>
>   So in server/apply.c, in learn_spell, you'd make a call to send_spellist()
> when the player learns a spell.
>
>   This is how most all of the object updates for player inventory are currently
> done - the update is sent in the code that makes the change - we don't hold the
> results and send them later.

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)

> >> 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, ...).
> >
> > Lore and damage seem reasonable, although then the question is, should
> > that be base damage or effective damage? Both of these values have
> > issues, effective damage may not do as much damage as stated (even
> > before resistance) owing to quirks in how each spell propagates, if
> > base damage is sent, then you need to send a lot more data and
> > hardcode the calculation. (more on that below)
>
>   For damage, we obviously can't take into account resistances of creatures.  So
> it'd be basic damage - if the spell does more, like cones, because of multiple
> effects on top of each other, we don't factor that, as you can't really know for
> sure how that will work out (likewise for fireballs - damage would vary greatly
> based on where the creature is in the effect).  The lore info could note those
> increased effects.

This requires a substantial increase in the number of spells with such
information.

> >> 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)
> >
> > This could work, although currently the clients have no information
> > about spellpaths.
> > This could be added, although maybe then a request_info spellpaths
> > would be better to initialise it? (this way clients couldn't fall out
> > of sync, and there is no restriction on adding new paths).
>
>   Perhaps, adding requesting adds complication, but not that much.  At the same
> time, there is a lot of communication that is defined stable.  IF someone were
> to add another stat for example, that would require some significant changes -
> the client isn't designed for dynamic stat information.

Requesting spell path names, at least on the server side, is easy, I
had it working locally already.

The way I'm dealing with stats is to only send them if spellmon is
set, anyone sending that should know what they will get back.

>   At some level, it could be nice for the server to somehow note what current
> client version is and tell the player if their client is out of date.  So if the
> client is out of date, they'd know to go update it - that'd be good for reasons
> beyond just spellpaths.

I'm not sure this is such a good idea, consider the case of someone
running a distro that has its own package management and creation,
they may be told to update their client, but not have any packages
available.

>   well, settings.spellpoint_level_depend determines if spellpoint costs differ -
> it is either an on/off value.

Ok, how do you propose to let the client know what it is set to?

>   Looking at other values:
>   Since the spell is linked to a skill, the client does know the skill level.
>   The client also will know the spell level (one of the most importent bits of
> the spell).
>   As per notes above, it would also know the spell paths.
>   To figure out actual sp costs, it would need the sp/maxsp and grace/maxgrace
> values.
>   the PATH_SP_MULT macro is perhaps the most variable.  However, since that
> macro has values hard coded in (not pulling it from settings or anyplace else),
> probably relatively hard coded.
>
>   All that said, one could see something like a C->S: requestinfo spell_conf,
> in which the server responds with those values.  But that does make things more
> complicated.  But I don't think those values have changed in 5+ years, so I'd
> call them relatively stable also.

In that case, it would need to be accepted that any change to such
calculations would require a change in the server protocol version
number.

> >>   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.
> >
> > This would be where the logic behind letting the client decide when to
> > request the information comes into play.
>
>   But I don't really see how the client can make any real intelligent decision
> on that.  It would basically seem to me that the client will request a spell
> dump if the spells have changed and it matches why it wants updates.
>
>   I can't see the client really being able to know that the player is in combat
> and thus now is a bad time to request all that data.

It would be possible to wait for the rate of drawinfo's to drop below
a certain level (since there are normally lots of these in combat.

>   I'd think at best the client could perhaps decide 'at most, I'll request spell
> info every 10 seconds' or something.  But then you'll get the case where a
> player equips something that makes them attuned, goes to cast the spell, and is
> confused because the client is still showing old data in terms of spell cost and
> damage.

If the cost and damage are sent as base values, this information will
be updatable client-side as soon as the new stats data is sent.

>   Right now, I believe it is basically a requirement that spell names be unique.

Well, if it isn't, using the cast command becomes interesting.

>   This, it can be assumed (within the protocol) that if a spellupdate contains a
> spell name that the client already knows about, it is just and update for that
> spell.  If it contains info it doesn't know about, it is a new spell.

fair enough.

>   Right now, other than DM action, there is no way to lose a spell.  But for
> that, might just be easiest to do something like 'spellremove ....', and just
> like do_learn_spell() being the only place to add a spell, the only place to
> remove a spell is probably just a few places so wouldn't be hard to do.

I think do_forget_spell is the only place it is used.

>   In terms of bandwidth, I wonder if it is reasonable to do some form of caching
> of the message info, eg, the client have a spell file that contains the info it
> got.  Instead of the server sending the message text each time, it sends a
> checksum of the message data.  The client could load the spell up from its
> history file and see if the checksum match - if so, use the one in the history
> file, if not, request info from server.

This seems overly complicated, the msg field is only a couple of lines
anyway, and, if the list is mostly static (as your suggestions would
make it be) it would only really be sent once per session. Certainly
this is untrue of message fields on visible items, and no checksumming
is used for the descriptions of them.

Overall, I am inclined to go with your approach, but I am still unsure
how to inform the client about spellpoint_level_depend.