[crossfire] requestable spell lists.

[Mark Wedel]

Brendan Lally wrote:
> 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.

  There are several setup commands that currently pass in numeric values and not 
just a simple true/false.  mapsize is the most obvious.

  There is currently the 'exp64' setup command that determines if exp values are 
sent as 64 bit in the stats command.  So having a setup command that takes a 
numeric value and effects operation of other things is pretty standard.


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

  Since spell are objects, you could use the object tag as a unique identifier. 
  That'd at least be easier on the C->S request.

  But this does complicate things - if a player learns a spell, you need to send 
a stat command at that time (or you need to hold that player learned spell X, 
which would be a pain).  If player equips something, then a bunch of spells 
could change, and you somehow need to record that all those changed.

  It is much easier to send the differences when they happen - then you don't 
have to hold any state in the server.

  I'd also be a little concerned about using the stats command to denote what 
spells have changed - this seems to be getting away from what it was really 
designed for, which was a simple method to communicate stats.  I'd be more 
inclined to create a new command then, like spells_changed.  I guess it sort of 
comes down to what data is expected.

  I'd personally prefer not to see holding of a lot more state data on the 
server side - for this project, I don't think that is needed (other than 
spellpath communication).  Just easier to send the data as you know it changes, 
but that gets messy with level changes and spellpath changes (otoh, if client 
knows spellpaths, it would then know what on its own what spells have just 
changed, and could request info on those specific spells).

< much about spell info/lore cut about>
> 
> This requires a substantial increase in the number of spells with such
> information.

  True, but that has to be written at some point.  At some level, however, 
providing damage information is still a step forward - right now, the only thing 
a player easily knows about spells is level and cost.  If we provide damage 
info, it'd be hard to imagine people saying 'this is bad - shouldn't provide it 
because I don't know what it means'.  And if nothing else, it at least provides 
some guidance for spells of the same type (hmm, small snowball does X damage, 
small fireball does Y, X>Y, I'll cast the snowball)


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

  OTOH, you get the flip side of that - someone trying to play on an old client, 
having troubles, and giving up.  Maybe a new client isn't available for their 
distro, maybe one is.  But right now, a user trying to play just sees something 
is broken - my normal practice is more info usually isn't a bad thing.  At least 
if we tell the player there is an updated client, he can decide if he wants to 
try and install it, etc.

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

  Easy enough to be part of a request command or something.  Or for that matter, 
the spellinfo could have some option parameters, like:

spellinfo <level depend> <attune reduction> <repelled increase>, etc.  That 
might be overkill to send that each time however.


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

  If the calculation method is changed a great deal, then some form of 
communicating that would be order.  Or for that matter, could just have a field 
like 'spellpoint_calculation_mode ...'.

  However, I was thinking about this, a simpler approach would be to send base 
values based on current level, but not spell path data.

  Thus, when player equip/unequip. easy to apply the spellpath costs (as its 
just a simple multiplier).  When the player gains a level, then costs get 
re-sent.  I'm not positive I like that approach - I'm more tempted for an all or 
nothing approach on that calculatable information.



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

  True, there are lots of things you could try and do.  Just I don't see any 
info the client has right now as making that decision easy (it doesn't record 
rate of drawinfos for example).  And even then, you'd get weird cases - player 
goes to a shop, drops a pile of good on the identify altar, sees what all his 
stuff is, and says 'oh, a new spellbook'.  Client just got a bunch of drawinfos, 
thus doesn't think now is a good time, etc.

  All that said, if we're only sending the occasional spell now and again, that 
bandwidth cost shouldn't be an issue.  I really only see it being an issue if we 
dump all the spells to the client, because that is enough data to cause some lag.

> 
>>   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, which is one reason I like that apporach.

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

  True.  That said, for visible items, message information is only sent when 
player examines the item - it is not sent when it becomes part of the player 
inventory.  You can look at the itemcmd code and see that the amount of data 
sent for items is relatively basic.

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

  Well, the cost variation based on level is documented in the 
doc/Developer/spells file.  I'd make the case that behaviour is unlikely to change.

  As said, the attunement/repelled costs are currently hard coded, so I'd say 
those are unlikely to change (would probably be good to at least replace those 
with a #define value however)

  I think it is perfectly reasonable to expect the current calculations to 
remain stable, save for there being some error found in them.  So I'd say at 
least that it is reasonable to assume the way costs are calculated is not likely 
to change.