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 _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire