Re: [crossfire] requestable spell lists.
On 1/6/06, Mark Wedel [EMAIL PROTECTED] wrote:
All looks good - just a one minor question:
+ name (1 (non-zero) length byte, followed by that many bytes
of ascii text)
+ This is the name of the spell, and should be sent to the
server
+ in order to cast/invoke it.
+
+ display name (1 length byte (which may be zero) followed by that
+ many bytes of ascii text)
+ This is the name to display to the player regarding the
spell.
+ If length is zero, then the name should be used instead.
Just curious what these these two names are far. As far as I know right
now,
each spell only has one name, so not sure why there are two.
gros wanted a way to do it, I think the reasoning was that there could
be the 'internal' name of the spell, and a more flavourful display
name.
Currently I have it set up to send the name and then name_pl as the
display name, but only if it is
1) present
2) different from name.
I could of course use a different field instead ('title' maybe?)
As an aside - it doesn't need to be part of this patch, but it might be nice
to have the cast/invoke command be able to tag a numeric value instead of
string
name, eg:
cast 12345
Which casts the spell associated with tag 12345. This provides a slightly
more efficient way of the client communicating to the server what spell to
cast,
and also provides a fairly good optimized way for the server to find the spell
(doesn't have to worry about duplicates - just has to see if an item with that
tag exists in the inventory (of which there is already code that does it) and
verify it is of type spell.
This could be done quite easily, although to not break older clients,
it would have to be the case that no spell names currently start with
a number. I believe this is the case however.
one other point, should I send the face number (if there is one) too?
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable spell lists.
Brendan Lally wrote:
On 1/6/06, Mark Wedel [EMAIL PROTECTED] wrote:
All looks good - just a one minor question:
+ name (1 (non-zero) length byte, followed by that many bytes
of ascii text)
+ This is the name of the spell, and should be sent to the server
+ in order to cast/invoke it.
+
+ display name (1 length byte (which may be zero) followed by that
+ many bytes of ascii text)
+ This is the name to display to the player regarding the spell.
+ If length is zero, then the name should be used instead.
Just curious what these these two names are far. As far as I know right now,
each spell only has one name, so not sure why there are two.
gros wanted a way to do it, I think the reasoning was that there could
be the 'internal' name of the spell, and a more flavourful display
name.
Currently I have it set up to send the name and then name_pl as the
display name, but only if it is
1) present
2) different from name.
I could of course use a different field instead ('title' maybe?)
Ok. I wonder if we should just not worry about it until there is actually a
case where it is used (unless there is something on the drawing board right
now?) As otherwise, we start going down the path of including all sorts of
fields in all sorts of commands because they could be useful at some point -
designing for that just becomes more complicated.
In some sense, because it also comes down to what does the client do with this
info? Unless there is a clear idea where this info comes from and how it will
be used, it just seems like we shouldn't include it until we know that point.
Otherwise, I can see the client not doing the right thing with it, so when it
does become time to actually use that info for some purpose, the client needs to
be updated to use it. At which point the question is - why not just wait until
that point.
As an aside - it doesn't need to be part of this patch, but it might be nice
to have the cast/invoke command be able to tag a numeric value instead of string
name, eg:
cast 12345
Which casts the spell associated with tag 12345. This provides a slightly
more efficient way of the client communicating to the server what spell to cast,
and also provides a fairly good optimized way for the server to find the spell
(doesn't have to worry about duplicates - just has to see if an item with that
tag exists in the inventory (of which there is already code that does it) and
verify it is of type spell.
This could be done quite easily, although to not break older clients,
it would have to be the case that no spell names currently start with
a number. I believe this is the case however.
I believe that is the case also, and putting that in as rule would I think be
fine.
one other point, should I send the face number (if there is one) too?
I'd say yes - I'm not sure how many spells have good icons set, but I could
see it as being nice for the client using the icons in pull down menus/whatever
to denote the spells.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] requestable spell lists.
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) Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C-S: spell id[fields] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional fields argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S-C: spell nrspellsid 1information 1id 2information 2... This is either an answer to an explicit C-S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - typeofchange (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - name (string): The internal name of the spell, as used in cast or invoke commands (burning hands); - caption (string): The visible name of the spell, as displayed by the client (Small Firestorm of Lhangwival). The client is free to do whatever it wants with its value. - cost (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C-S spell flags/setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S-C spell message is sent as soon as its trigger (reception of the C-S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a base value sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic spell name for the command names - for what matters, it could in fact be requestinfo spell/replyinfo spell, or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] requestable spell lists.
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) Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C-S: spell id[fields] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional fields argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S-C: spell nrspellsid 1information 1id 2information 2... This is either an answer to an explicit C-S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - typeofchange (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - name (string): The internal name of the spell, as used in cast or invoke commands (burning hands); - caption (string): The visible name of the spell, as displayed by the client (Small Firestorm of Lhangwival). The client is free to do whatever it wants with its value. - cost (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C-S spell flags/setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S-C spell message is sent as soon as its trigger (reception of the C-S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a base value sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic spell name for the command names - for what matters, it could in fact be requestinfo spell/replyinfo spell, or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable spell lists.
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
Re: [crossfire] requestable spell lists.
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. 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
Re: [crossfire] requestable spell lists.
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, XY, 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
Re: [crossfire] requestable spell lists.
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. 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. 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. 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, ...). 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) 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. 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. The only change needed for that to really work would be to send down the players current spellpaths in the stats command. 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
