[crossfire] Crossfire 2.0+ features/priorities

[Mark Wedel]

Miguel Ghobangieno wrote:
> One of the things we should do for 2.0 (note: we are
> not yet at 1.9) is try to decrease bandwith usage. For
> instance, some animations are cylical, and the server
> knows which ones these are currently IIRC. The server
> shouldn't have to send a update for every tile every
> time for cylical animations, the client should beable
> to work this feat IMHO.

  I'll probably throw out a 1.9 release in the next few weeks.

  I do plan to work on the map2 command in that not too distant future 
(really!).  Part of that is to let the client do animations.  That said, that 
isn't a huge bandwidth hog.

> 
> Also if we can make some commands that are 4 bytes
> long (north south etc) or other longish commands
> shorter that might be good too. (We should keep
> backwards compat here maybe thought, so if a client
> says it's not 2.0+ it gets to use the old, easier to
> parse, stuff).

  IMO, the client->server communications isn't an issue.  Even at say 10 
bytes/command, and doing 10 commands/second, that is 100 bytes per second.  A 
2400 baud modem can cover that.

  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).

  It _may_ be reasonable to compress the map data if that packet was big enough 
(there would need to be a new command, like:

S->C: cdata <len>

  And after the client gets the data, it then uncompresses it and then runs the 
commands from it.  But to do that, requires some reworking - ideally, you would 
want to queue all the data that the server is about to send to the client during 
the activity tick, and then after that, go and compress the data and send it 
along.  This actually wouldn't be that hard.  However, it does make a tradeoff 
of CPU consumption (on the server to compress it) vs bandwidth.