[crossfire] server map code redo.

Mark Wedel mwedel at sonic.net
Wed Aug 31 02:26:57 CDT 2005


tchize wrote:

>>
     
     5) To convey some of these changes to the client, a new protocol command is
     
     >>
     
     needed.  But no reason to write that until we have data to actually send to
     
     >>
     
     it.
     
     >>
     
     
     >
     
     
     >
     
     
     >
     
      I'll opt for a complete rework of whole client/server protocol in a branch. 
     
     >
     
      This way we can easily tweak new protocol for performance and not take 
     
     >
     
      care of old protocol compatibility. Backward compatibility could come 
     
     >
     
      afterwards when new protocol is mature enough.
     
     
  The problem, as mentioned in layering thread, is that some of these changes 
basically necessitate some mechanism for backward compatiblity.

  Basically, right now, the server stores 3 layers of information in the 
mapcells.  I don't want to have to have those as well as all the new layers - 
I'd want those old layers to go away - this means some mechanism to pull the 
right data to display.

  As far as new protocol, I'd actually argue that there is less reason to branch 
that than making a change to an existing protocol.  After all, we could pretty 
easily put something in at the top of socket/request.c which will basically have 
it refuse to serve the new protocol (by refusing setup command) unless 
uncommented - if someone is savy enough to mess with that, they can live with 
the consequences.

  I do note that I wrote up a 'map2' protocol proposal a while back and it does 
sit in the doc/Developer/protocol file as the proposal.  I think tha should 
cover everything, but in that one, I only did 8 image layers (including 
smoothing), which wouldn't cover the proposal I just sent out.


    
    


More information about the crossfire mailing list