Brendan Lally wrote:
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.
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.
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.
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.
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.
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.
But hardcoding them or doing via requestinfo both work. Note of course the
spell path info in this case is really the bitmask to name mapping. For all
spell calculations itself, the client wouldn't really care (player bitmask is
attuned 4, denied 24, repelled 1. This spells path is 16, so it is denied to
the player, etc). It doesn't need to know what spell path 16 is to make those
calculations.
But that is one reason why I say giving the client hte numbers is easier - it
makes handling easier. Otherwise, what I'm sure will happen is at some point
someone will come up with code in the client that takes the spellpaths and
converts them into bitmasks, etc.
If I've learned one thing through lots of client/server programming, almost
always best to send the raw data and let the client figure out what it means vs
having the server try to figure out what it thinks the data should look like and
send that processed data to the client.
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.
well, settings.spellpoint_level_depend determines if spellpoint costs differ -
it is either an on/off value.
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.
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.
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.
This may seem trivial, but when it happens, I'm sure bugs will be filed and
people complain.
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.
See note above. You'd just inject the appropriate send spell data command
wherever the player can learn a spell. And in fact, the number of places a
player can learn a spell is limited- in fact, I think it all leads back to
do_learn_spell(), and all the data that is needed to send the data to the client
is there (player object, spell object, etc).
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.
Right now, I believe it is basically a requirement that spell names be unique.
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.
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.
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.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
