I've been working on updating the server to use draw_ext_info() calls and remove all draw_info_calls() - I mentioned this in another e-mail.
One area that could use cleanup IMO is the output buffer handling in the server. For background, this is the code that combines messages so instead of getting: You hit orc You hit orc You hit orc You get 3 times You hit orc Now originally, that code was put in when the display logic was still part of the server, and the display options were not as good (specifically, lack of long scrollback buffers and only single pane displaying the messages). So I'd like to remove that code. The only real argument I can think against it is that by having it in the server, there is some bandwidth savings (server combines messages before being sent). However, I find it hard to believe that the savings are going to be very significant compared to the rest of the bandwidth consumed. If I don't hear any complaints, I'll remove that code. One question is whether it makes sense to put that code into the client. Given that both GTK clients have multiple panes for messages, and the only thing that really benefits from this combinining messages is the attack messages, the amount of benefit isn't as great. Plus, since the attack messages where changed to be more variable in terms of what they print, those often can not be combined. IT seems the main area of benefit is spells. Now one minor issue here is that within the server, there is the NDI_UNIQUE to say if it should be collapsed or not, and that isn't passed on to the client. However, with the draw_ext_info, type/subtype of the message is passed to the client, and with that, the client could make pretty intelligent choices on if it may be a message that it could try to buffer (basically, if it isn't an attack of spell message, probably not worth it). Thoughts? _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
