On 3/13/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > > I've started work on the map2 command - preliminary documentation on that > has > been in the Protocol file for a while, but I have made a few minor changes. > > My personal thought is this: > Add new flag(s) which says how to handle animations. My personal thought is > leaving case #3 as a server side is probably the easiest (server side being > that > we don't send animation to clients, just send face for the space like we do > now). This doesn't get us as much of a bandwidth savings as possible, but > does > keep things simpler - at some level, its a balance of how much complication do > we add to save some bandwidth. > > Thoughts/comments?
One thing you haven't mentioned, so I'll do so now, is merging in map_scroll and newmap packets. Having these as two seperate packets would be fairly ugly if clients are handling animations. If static items are not sending map packets every tick, then a far greater proportion of map packets will be for scrolling or new maps. This would therefore suggest that a better approach would be to have 1 byte at the start of the map2 packet to act as a control byte, something like CDDDNSEW where C corresponds to the newmap packet, and tells the client to clear the fog of war data. D is the distance to scroll in any direction, (from 0 to 7 squares) NSEW are north, south, east, west, the bit being 1 if the map is scrolling in that direction. so, on entering a new map, 0x80 would be sent. on scrolling one square to the north west, 0x19 would be sent, etc. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire