[crossfire] requestable spell lists.

[Brendan Lally]

On 12/16/05, Mark Wedel <mwedel at sonic.net> wrote:
>
>   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.

I can, that's why I started off with the status values. If a client
only shows spell names, or only names and denied status, they would
only request a new copy of the list on status 4 or 4 & 2 respectively.

>   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.

This could work, but requires a new command in the protocol.

>   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)

> 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)

> 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).

> 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.

more consistant in terms of data sent in a single iteration. but
SP_level_spellpoint_cost - the function that does this server side,
calls on about half a dozen other values, all of which the client
would need to know, and some of which
(settings.spellpoint_level_depend for example) are quite obscure. If
ever the method used to calculate cost changed, then this would fail
hopelessly. I don't think a commitment to keep the same spell costing
rate can be made, therefore hardcoding it into clients is a bad idea.

>   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.

> The only change needed for that to really
> work would be to send down the players current spellpaths in the stats command.

This seems like quite a good idea, it is simpler and yet more powerful
than the status I have been using.

>   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.

I'm more concerned with how it complicates the server, it will mean
that each spell will need to track its status independently.

It might be possible to pick an unused value in the spell objects, and
use this to hold states, and then iterate over them with a diff like
syntax.

so we might have

spellupdate
!spark shower:1:176:Electricity:0:5:0:Sparkshower is a cone of
electrical energy.
Creatures caught within the cone take magical and electrical damage.
+holy word:1:170:Turning:0:0:4::
-burning hands:1:174:Fire:1:4:0::
(icidentally, these last two do not have msg's)

In this case then, every line altering a spell would start with + - or
! to add, remove or modify a spell respectively, any line not starting
with one of these characters, would be the next line of the msg
associated with the previous spell.

This could still lead to a lot of traffic at login, although maybe
that is preferable than a lot of traffic during combat.