[crossfire] Re: Map Protocol Question

alex_sch at telus.net alex_sch at telus.net
Sun Aug 21 18:53:54 CDT 2005


Quoting Andreas Kirschbaum <
     
     kirschbaum at myrealbox.com
     
     >:
 
>
     
      I'd like to come back to this issue: I think the current implementation
     
     >
     
      of the newmap command does not work at all. (And cannot be made work
     
     >
     
      without changing semantics.)
     
      
>
     
      - client receives "map_scroll +1/0"
     
     >
     
        client basically ignores it because it has a cleared map state
     
     This ignoring as I see it is the main issue with the current semantics. For one
thing the python bot that I started on a while ago wouldn't ignore the
map_scroll in this case, and therefore there isn't such a display error in that
respect (though it's probably not a good thing to model a proper implimention
based on because it has even more display errors).
 
>
     
      - client receives "map1a <difference of Scorn to gatehouse>"
     
     >
     
        Note: this information is not correct because it is a difference from
     
     >
     
              Scorn, not a difference from an empty map. This is why some
     
     >
     
              tiles show up as blank for a short time: all tiles that did not
     
     >
     
              change are displayed blank (client already has cleared his map
     
     >
     
              view).
     
     I'm not exactly sure this is an issue *if* the client doesn't ignore the map_scroll.

>
     
      Therefore I still think that the clients currently behave correctly, but
     
     >
     
      the server is wrong by not clearing the map state. That is, we could
     
     >
     
      just change the server behavior without breaking the specification or
     
     >
     
      existing clients.
     
     On this I would agree, I think that having the server clear the map state would
be a good change to make, and I don't see how it would break existing clients.

    Alex Schultz


    
    


More information about the crossfire mailing list