Brendan Lally wrote:
On 12/17/05, Mark Wedel <[EMAIL PROTECTED]> 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.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
