[crossfire] Crossfire 2.0+ features/priorities

[Alex Schultz]

Mark Wedel wrote:

>  This issue is really the server->client direction, and that already is binary, 
>so not a whole bunch of savings.
>
>  I have a feeling the big hog is the map data - things like stats is never 
>much.  The item stuff, especially for huge piles, can add up.  And I think 
>someone suggested that the detailed item information (what you get from describe 
>item) is also sent along - I think that may be a reasonable idea, but does 
>increase the bandwidth on that (that is also tricky in that certain things could 
>change the description of the item (it being identified will change its value 
>for example) - I'm not 100% the UPD_ flags cover that, but probably do (but 
>money will always be suspect - changing charisma can affect costs also).
>
What would also save alot of bandwidth, would be including in the new 
server protocol a method of sending rectangular blocks of tiles that 
should all be added of deleted. This could potentially cut the map 
bandwidth in half or less in some locations (lots of floor and walls 
compared to everything else). Making the client interperate the data for 
that would be very easy, the most difficult part would be the server 
logic of where it should define rectangles but I am sure that is not too 
bad.
I put up a couple ideas about the new map protocol here a while back:
http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol
(see also http://wiki.metalforge.net/doku.php/dev_todo and 
http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 on the wiki)

Alex Schultz