Following up on a thread started in December, I finally applied a patch to the GTK-V2 client to experiment with improving message routing in the client. This code begins to sort messages between message pane 0 (Messages) and pane 1 (so- called Critical Messages) based on MSG_TYPE classification. What drove the change was a desire to put player communication and other kinds of important messages) in a panel that was not spammed with "You miss/hit..." messages, etc. The idea being that the player does not want to have to scroll-back and hunt for talks/chats and messages like all your armor is melting away from that acid and your xp drained by that Nazgul or what have you - those messages need to stay visible for longer periods of time.
In that vein, after some play testing, I found that there was a weird split with character says appearing in pane 1 vs. NPC and Magic Mouth replies showing up in pane 0, so a later patch added MSG_TYPE_DIALOG to the pane 1 routing. As a side note, it may be noted that this change seems to drive certain of the Glade client layouts to the top of the list of preferred ones since it means that there is a lot of value to having pane 1 visible by default. In any event, for those who can play 2.x GTK-V2, please feel free to comment on changes. The change was simple, but with its advent, it becomes much more tantalizing to continue the improvement effort. mwedel has suggested a number of possible ideas in this regard, and I better see the potential now. Two of the items under consideration are to add a panel specifically to support player communication, and, to allow a player to select the message routing between the various message panels via in-client configuration settings. (Another idea is a lot more technically challenging, that therefore will not get first attention, considers giving the player even more fine control of the UI layout than is possible with the glade layout files that need a client restart.) Anyway, on to the topic of new work... and in particular, planning how to prepare for player configured message routing, a client quirk has popped up on the radar. Messages are only classified according to MSG_TYPEs if they originate on the server. The client uses a simple, color-based routing method... namely that all client-sourced messages are placed on pane 0, and any that are color are ALSO put on pane 1. The routing concept starts to make this behavior look kind of weird. "Why do those messages show up in all panels? They really aren't all that important!". Essentially, this behavior comes down to the fact that the clients all use a draw_info() function that have no awareness of message type. The GTK-V2 client was the first client to support processing messages by type. The solution is very simple and I have a patch made that instantiates a new MSG_TYPE_CLIENT. Subtypes for client messages haven't been focused on yet, but should be quite basic. GTK-V2's custom messages are few, and have already been changed (in my sandbox only) over to use MSG_TYPE_CLIENT, but this makes the client-messages sourced in the common code start to stick out like a sore thumb. To start converting these messages to be routable, it becomes necessary to add a draw_ext_info() function to all clients (X11/GTK-V1/GTK-V2). In X11 and GTK-V1, this is a stub function that discards type and sub-type by passing the text and color data to draw_info(). In GTK-V2, draw_ext_info() calls message_callback() which is the entry point for type-aware message handling. Basically this proves to me that now all client-sourced messages are easily converted to the type-based routing method, which seems to be the best when considering making the client-side routing configurable. So, if you followed all that... and have an interest (for or against) the message routing, feel free to comment on what you think about adding a new MSG_TYPE_CLIENT and one or more related sub-types. Pros: This expands upon the GTK-V2 theme support in that now all message types can be tweaked by a theme whereas in the present SVN client, the theme has no control over client-sourced messages. If additional message panes are implemented, this change assures us that client-side messages need not be sprayed over all of them - the routing can be more intelligent. Client messages can now follow a single code path instead of two (code comments in the client even ask the question of whether the draw_info() code makes sense when there is (an implied) better method). This seems to make is simpler to read the GTK-V2 code that relates to client messages. There are requests for client layouts 640x480 and smaller and smart message handling in such tiny client screens is critical to playability. This change seems to enhance the ability to effectively support smaller screen layouts. Cons: I cannot think of any, can you? I plan to continue this effort and eventually commit the changes, but I'll be glad to entertain additional input. I believe enough in the end-result that the balance is already strongly tipped in favor of the change, but figure it is only fair to open the topic up for discussion in case there is more to consider than has crossed my mind. One particular area that is a bit fuzzy is whether the new MSG_TYPE_CLIENT is that necessary. MSG_TYPE_ADMIN might be re-used instead of adding the new type. It has sub-types that could be construed to be a bit relevant, although I ended up going with the new type simply because most MSG_TYPE_ADMIN sub-types were obviously server-oriented, and it seemed a bit cleaner not to mix server and client messages at the type level when some sub-types would make no sense at all for client-sourced messages. Opinions on this point are particularly welcome. Kevin _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
