[CF-Devel] smoothing code.

Sun Jul 6 01:06:14 CDT 2003

tchize wrote:

>

     >

      I first tried only client side, but dropeed 6 months ago. too manny issues to

     >

      resolve, no control for mapmakers, difficulties for having 'names' associated

     >

      with images under certain configuration. The client server protocol extension

     >

      is still the cleanest way.

  Ok.  Fair enough.

>>>

     S->C: smooth <facenbr> <sm000> <sm001> <sm010> <sm011> <sm100> <sm101>

     <snip>
>

     >

      I understand this is a bad choice for the protocol. Am sorry. But this

     >

      command is not frequent (like images, server keep a list of smoothing 

     >

      sequences already send to client, for now ther are only 6 smoothing sequences 

     >

      i think) and the client/server have already been updated in cvs, i could 

     >

      switch to binary form if you agree to break client / server which have been

     >

      checked out during the past few day when this was not binary.

  This is of course one of the reasons that changes should be discussed/posted 
prior to committing.

  Given how recently this was put in, and the fact no official release have been 
made, I'd say update this and potentially break backwards compatibility. 
Alternatively, this could be replaced/enabled by a different request command, so 
that the command is at least different.

>

     >

      Like for images, if client asked the smoothing from server, server

     >

      will send the smoothing sequence when this is a new one for client

     >

      and this sequence is visible in the current map. So this work

     >

      of sending is done automatically when sending the mapextend command to client.

  Ok.  I'd just write that into the protocol, like 'the server with send a 
smooth command the first time a smooth graphic is sent to the client if the 
client wants smoothing information'.

>

     >

     >

     >>>

     C->S: toggleextendedinfos <string1> <string2> .... <stringn>

     >>>

             Ask the server to send some additionnal informations about the

     >>>

     map.

>

      see coment on mapextended below before reading this part.

     >

      This help separate things. Since a lot of infos may be, in the future,

     >

      associated with map coordinates, this command tells the client what

     >

      in the map coordinates it want. And it also respond by telling

     >

      what actually are the options activated. Thought it simply easier to handle.

  It really seems this is just a setup command, just more related to map data. 
The setup command returns the value that the server will be used, so that bit 
doesn't seem a lot different.

  It seems that setup, combined perhaps with requestinfo, would cover whatever 
mapextended woudl be.  Since the setup command already covers a wide range of 
possible options, I just don't see the need for this command.  If perhaps there 
are some specific examples of what this command would do that can't be done with 
setup/requestinfo, that is a different matter.  I just don't really see that 
right now.

>

      mapextended will contain, in the end, a lot of informations. This command has 

     >

      been developped so it is easily extendable without breaking the clients and / 

     >

      or old server. For now this contains only smoothing. Work will be done

     >

      next so when text message are used, for example from NPC, they will

     >

      be send according to the location. Moreover, the bit fields at the begin of

     >

      command allow, from case to case, the server to send only a small part 

     >

      of the info. (eg, if a nps speak, no need to send smoothing infos

     >

      with the localized text). 

     >

      When i decided to send smoothing informations, i saw all those different

     >

      map commands. And i though if we have to add commands, or use tricky code to 

     >

      upgrade old commands each time we need to send other informations related to 

     >

      the map from the server to the client, think will get even worse. So i 

     >

      prefered to create from zero a new command which is extensible. However,

     >

      in the near future, nothing prevents from having a command from client to 

     >

      server saying the server we prefer the 'classical' map informations to be 

     >

      send with mapextended and not map2 or map2a.

  The right approach is a map2 command.  Updating the current map command is 
only tricky because all the bits are currently in use (no spare capacitity). 
Adding another flag byte gives plenty of capacity for additional fields to be set.

  IMO, having yet another function/protocol command is more of a pain than 
extending an existing one.  And only one new command (map2) would be needed. 
Updating the map1 or map1a command certainly isn't needed.  The client would do 
something like 'setup map2cmd', and the server uses the map2 command, which 
would be 90% the same as the map1/map1a command.

  You have to be careful/think about what information woudl be included in the 
map commands.

  Sound information, for example, is not.  One reason is the way it is generated 
- it is generated through some other event, and isn't persistent.  Text messages 
are the same way.  So if you want to send them in this command, you then need to 
tuck away that 'xyz was said on space a,b', send the map for all the players, 
and then clear that this information in on this space so we don't send it every 
tick.

  One can see that it is almost certainly see it easier to do text messages the 
way sound is done - when a text message is generated, client does something like 
'sendtext x,y <text message'.  This is more so in the fact that text messages 
are likely to be rare events, so the little extra overhead in doing this (vs 
embedding it in a map command) isn't a very big deal either.

>

      Moreover, server may send additionnal informations the client doesn't know 

     >

      about, without having to take care 'may i put those 4 additionnal bits inside 

     >

      the packet?' 'is the client using the old 1 byte or the new 2 byte ways of 

     >

      sending smoothing?' etc. The server knows in advance the client will skip 

     >

      what it doesn't understand, while still reading what he does understand. This 

     >

      could help a lot, IMO, in the future the readability of server code 

  I still consider this a bad idea.  Send data the client expect.  Sure, there 
are a few more if's in the server code (if client wants text messages, send it). 
  Such code is really trivial, and also more efficient.  Because I also forsee 
that if this just gets extended to the extent that a bunch of extra data is 
being sent, and the client/player doesn't want it, they will say this is bogus - 
send me the info I want - I have limited bandwidth/cpu power/whatever, don't 
send all this extra stuff.

  But more over, the protocol tends not to get updated too often.  But talking 
about confusing code, the code for the extended info is already embedded in the 
same code that generates the map1 command.  To me, that is more confusing than 
just putting the data in the map routine - now one has to pay more attention to 
where this attribute is being used.

>

     >

      see mapextended as a map2 command with more future extensibility without the 

     >

      pain of handling 'old cases' in the server and guessing eveyrtime what the 

     >

      version of client is.

  There is _never_ and issue of guessing what the client supports - the client 
always tell us via setup command if it supports smoothing, text messages, 
whatever.  It is just a matter of having a few if's in the code to handle if the 
client supports it or not.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel