[crossfire] map2 & animations

[Brendan Lally]

On 3/13/06, Mark Wedel <mwedel at sonic.net> 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.