[CF-Devel] Client/server protocol enhancements.

[Mark Wedel]

Scott MacFiggen wrote:
>
     
     
     >
     
      Could have swore if you hit the corner of a map that wasn't true. I can't
     
     >
     
      try it now though since the client doesn't seem to work very well
     
     >
     
      with the server anymore. I log in and all I see is darkness except the
     
     >
     
      square the player is in.
     
     
 I think in ancient times (when the server did the gui), this may have been true
- as you approached the edge of a map, your relative position on the display
would move, so if you were at the right side of the map, your figure would be at
the far right side of the screen.  That isn't the case anymore - that stuff to
the right is now just drawn as black.

 Of course, the client could try to do its own optimizations, eg, if the client
machine does not have the power to render the 25x25 map in reasonable time, but
the server to client bandwith is high, the client could still use a 25x25 map,
and show a smaller portion of it on the screen.  If the client detects that
everything to the right is blackness, it could shift the display so that the
portion the client sees is still filled up.

 A minor wishlist for me would be to make the map in the gtk client scrollable -
if using fog of war, it is sometimes convenient to thing 'so what was over there
again', and being able to scroll to over their would be cool.  That probably
isn't too hard, but for reasons of optimization, you really only want to render
what is actually being shown on the monitor, and not the entire canvas.

>
     
     
     >
     
      ...Oh I see, the sun wasn't up. New feature I guess. Ok, when the
     
     >
     
      sun is down, the gtk client gets really confused. The server
     
     >
     
      doesnt' seem to be telling the client the square that was
     
     >
     
      just vacated is now dark and should be painted black. I end
     
     >
     
      up with a copy of my player character everywhere I have stepped.
     
     >
     
     
     >
     
      Does this new time feature not use the darkness code or something?
     
     
 Best I know, it uses darkness.  More likely the handling in either the server
of client for the darkness isn't quite right.

>
     
     
     >
     
      >  Server already provides this on an image by image basis, so if the client is
     
     >
     
      > caching, the client can know if its version is up to date with what the server
     
     >
     
      > has.  If your talking about something else, please do followup.
     
     >
     
     
     >
     
      I'm thinking of an optimization of that idea. If the client knows the
     
     >
     
      server image file is the same as it was the last time, then checksums
     
     >
     
      for each image don't need to be sent or checked, and imagename/faceid
     
     >
     
      mappings should be the same too. And caches could be shared for
     
     >
     
      multiple servers. Since most servers probably use the stock
     
     >
     
      imageset that ships with the server, that would be good.
     
     
 This could get done.  Currently, the name->number mappings is not stored, so
that data would only be persistent when that particular instance of the client
is still running.

 Now looking at the lib/bmaps file, it is about 70k.  Given that in the format
of that file, there are 7 characters other than the image name, it would mean
that if an optimized way of sending a bunch of that information to the client is
done, that would also be about 70k (eg, allow one face2 command to send
information on say 500 images, and not just one at a time, so the 5 bytes for
the face2 command aren't there).  If your connectictivy is 100 kbs, it would
take 7 seconds or so to download that.  If you have DSL, in theory sending that
data will just take a couple seconds.  Of course, normally that information is
just send when needed, so it doesn't really effect startup time.

 I suppose in the information for each of the image sets, a checksum of the
image file for that set could also be included.  Up to the client what to do
with it (after all, the same name to number mappings may be in use, it may just
be that one image in that set was modified - and if that is the case, your now
back to getting checksums).

 I guess I'm sort of mixed on the usefulness of the client tracking that
information - yes, it saves some bandwidth, but not a great deal.  It certainly
makes the client more complicated (need to store and load that).  IMO, the more
useful aspect would be to better seperate the rendered image numbers, eg,
suppose I play on server one, and have a bunch of images it has rendered.  I go
to server 2 with that same client instance at a later point, it has a different
image file (added a few images let say) - rather that the client clearing all
the images it has rendered and then re-loading and rendering them, it would be
nice for the client to be able to adjust to that new mapping.

 This basically amounts to the gui aspect using an array that indexes into the
rendered images - that also makes things more complicated.  But IMO, that is
probably a more important aspect in terms of cpu consumption on the client
compared to the bandwidth for sending the face name to number mappings and
checksums.

 OTOH, it is easy enough to add an checksum for each of the total faceset image
files and send that along to the client when it requests it.  I probably won't
do anything more than that aspect, but if you want to, feel free.  It just seems
to add a fair amount of complication for not a lot of gain, but that opinion
probably depends a lot of what type of bandwidth you have available - if your
playing of 28.8 modem, saving every byte becomes pretty important.

>
     
     
     >
     
      > > Umm, can the client currently get a list of all spells and spell
     
     >
     
      > > descriptions and stuff from the server? What about skills?
     
     >
     
      >
     
     >
     
      >  The server doesn't even have a list of spell descriptions.
     
     >
     
      >  Now are you talking about what the player knows, or what just
     
     >
     
      >  exists on the server?
     
     >
     
     
     >
     
      What the player knows. Something a little more formal than the
     
     >
     
      'invoke and 'skills commands since parsing that output would
     
     >
     
      be a pain and the format should be strictly defined anyway.
     
     >
     
      But actual descriptions should be available too, not just
     
     >
     
      spell/skill names. And while you are at it, maybe send
     
     >
     
      over formulas for damage/range/etc so the client can show
     
     >
     
      that info based on the current level of the character?
     
     
 As said, currently text descriptions are not contained anyplace within the
server.  That of course could change.  For spells, we could send along spellpath
and spellpoint information.  AS said, that last one can vary based on many
things.  That could be useful for requestinfo protocol command.

 Formulas for damage/range/etc get complicated.  One reason is that the client
does not have that information for the items (client has no idea that the sword
does 8 points of damage for example).  Or are you talking damage etc for spells?

 If that later, probably not a big deal unless people consider that private
information (eg, if on my server I changed the spell_params file to change
damage and other factors, do I necessary want players to know about those
changes easily?)  To be honest, I'm not sure the answer.  One one hand, damage
for weapons is currently very public.  OTOH, I could see some server admins
adjusting things and wanting that to be a mystery to the player.  Probably no
one currently does modify that file, so probably not a big deal, but its a lot
harder to undo something after the fact that someone says 'wait, I don't want
players to know precisely how much damage that spell will do'.

Of course, if you do send over the spellpoint cost and the rate it goes up, at
least you don't have an issue of trying to figure out how many spellpoints it
will cost.  If you also send over the spellpath, then the client can figure it
all out.  Even easier if you make the current 'spellpath' the player
has like a stat that gets sent to the client - the client could then figure it
all out.  Since that information is already public, not a big deal sending it. 
So I guess the real answer might be, sending spell information, spellpoint cost,
how it advances, and the spellpath would be no problem.  Sending along range and
damage and how it increments could be a little iffy depending on if people
consider that secret information or not.


>
     
      I'm not so concerned with ability rolling but a more generalized
     
     >
     
      mechanism would be nice so server operaters can change it if they
     
     >
     
      want. But for newbie players it would be nice to show the
     
     >
     
      strengths and weaknesses of each race in a more obvious way when
     
     >
     
      creating a new character.
     
     
 current way does an OK job IMO.  could certainly be better.

>
     
     
     >
     
      Plus the current way just looks really unprofessional,
     
     >
     
      in the gtk client anyway.
     
     
 the popup method was a little annoying IMO. 

>
     
     
     >
     
      >  My thought on how this could perhaps work is something like:
     
     >
     
      >
     
     >
     
      > S->C: newplayerstats <total
     
     >
     
      > points><race1><adjustments><description><race2><adjustments><description>...
     
     >
     
      > C->S: Newplayer <str><dex><con>...<race>
     
     >
     
      >
     
     >
     
      >  Server then verifies that the data is OK (eg, valid race, that the point total
     
     >
     
      > is within range, and that the stats themselves are within valid range for the
     
     >
     
      > race)
     
     >
     
      >
     
     >
     
      >  This first removes the necesary of rolling a dozen times to get a good
     
     >
     
      > character.  It also means that the client can have a much nicer interface, and
     
     >
     
      > it also removes a lot of code from the server.
     
     >
     
     
     >
     
      Looks ok to me.  So this would allow both random rolling and for
     
     >
     
      the client to take points from one abilty and move them to a
     
     >
     
      different ability instead of just swapping scores? So then if a
     
     >
     
      server operater wanted to do a set point total instead of random
     
     >
     
      scores, he could just hardcode the server to send the same
     
     >
     
      ability scores every time? That would be nice.
     
     
 Would need to extend it a little, eg, 


s->c: newplayerstats <str><dex><con>...<flag><race information as above>

flag would be set/cleared depending on if a point total was being used, or if
the stats had to come back legitimately.  Note that presuming swap stats is
still allowed, the str/dex/con values for each race are the adjustments (eg, +1,
-2, etc), and not the stats if they choose that race, because the swapping is
not symmetrical.  EG, thing of an elf with +1 dex, -1 con.  Suppose 16 was
rolled for both of those, so 17 dex and 15 con.  If you swap those,  you would
still have 17 dex and 15 con because the base roll is 16.
 
>
     
     
     >
     
      The server would also have to send max/min ability scores, so the
     
     >
     
      server operater can customize...
     
     
 The adjustments for the race basically determine that (unless we decide to
change that, currently min is always 1, max is always 20 + adjustment (which
could be negative).

 IMO, the way to display this in the client would be to have a window, one
column with the rolled stats (or ability to set them if a point total system is
used), another column that shows the adjustments that the current race has
selected, and then another column that shows the adjusted totals.  Have a select
list that lets you select the race, which then updates the other adjustement and
total columns.

 
>
     
     
     >
     
      Since this is all startup stuff the server can be verbose and
     
     >
     
      send lots of info, so no reason to hold back info. I think the
     
     >
     
      server should send over starting skills too, and maybe allow
     
     >
     
      the client to pick a starting spell or two instead of a
     
     >
     
      random one. Or is that all based on class and not on race
     
     >
     
      at all?
     
     
 Spells (and most equipment) is based on class.  Some skills and equipment are
on race, some on class.  So you would then have to extend it the newplayer stuff
to also send the available classes.  However, I'm not positive if that is as
easily done as the race is (I'd have to look at how the hall of heroes does
it).  It would certainly be possible to set up archetypes for the classes that
then send along the right stuff.  Could have another selection list above that
also contains the class, shows the adjustments it has.)

>
     
     
     >
     
      Maybe it would be better to dropped this hall of heroes idea and
     
     >
     
      make picking class/race all one procedure. The hall of heroes
     
     >
     
      thing is cool but it isn't very consistent with how race
     
     >
     
      is chosen, and doesn't let you change your mind once a class
     
     >
     
      is picked...
     
     
 Problem is that the old stuff basically needs to remain until we get to a point
where we can say 'those with old clients, too bad'.   But having a much better
interface for new clients certainly wouldn't be bad.  But at the same point, the
above scheme is largely based on having a nice gui.  If you don't, and no one
plans to write way (say for the x11 client), the current scheme of course works
OK.


>
     
      No, it is just a pet peeve. The Protocol doc basically says at startup
     
     >
     
      the client should send X and Y commands and the server at some point
     
     >
     
      should really respond but doesn't really have to if it doesn't want to
     
     >
     
      kinda thing even though in practice it does the right thing.
     
     >
     
      Just seems the protocol should be defined a bit more strictly on
     
     >
     
      when commands can and can't be sent.
     
     
 There certainly is a 'flaw' in the design in that commands don't need to be
acknowledged by either side.  Thus, if either side sends an invalid command, the
other side just drops it, but the originator has no idea of that fact.  That of
course shouldn't happen for well behaved clients and servers, but since neither
side really knows what happened, it causes problems.

which is one reason that more and more, the new features actually acknowledge
back.  Eg, the generic requestinfo would do that, if you try to request
something that the server doesn't understand, it at least sends back saying so.