[CF-Devel] Client/server protocol enhancements.

[Scott MacFiggen]

On Sun, Dec 30, 2001 at 10:02:31PM -0800, Mark Wedel wrote:
>
     
       I can't think of any cases where the player is not in the center of the map. 
     
     >
     
      The functions that pack the map data and send it to the client always 
     
     >
     
      place the player in the center (starting at player position - half size 
     
     >
     
      of viewport to player position + half size of viewport).
     
     
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.

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

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

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

>
     
       I agree that the current method is not good.  IMO, in addition to it rolling
     
     >
     
      dice, the player should just get some number of points to make the stats he
     
     >
     
      wants.  I know peter at one point made some hack to a client for it to roll
     
     >
     
      stats until something 'good enough' was achieved, but given the handshaking
     
     >
     
      involved, that was still a slow process (eg, server rolls stats, send them to
     
     >
     
      client, client has to examine them, and then say, no roll again, but you have
     
     >
     
      the issue with latency for all of those, so if your server is 100 ms away, it
     
     >
     
      basically means you can perhaps do 2 characters/second)
     
     
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.

Plus the current way just looks really unprofessional, 
in the gtk client anyway.

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

The server would also have to send max/min ability scores, so the
server operater can customize...

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? 

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

>
     
       We can certainly make things more strict - is there anything specific you 
     
     >
     
       have in mind?  
     
     
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.

	-Scott