Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2000:
[Freeciv-Dev] Re: notify_player rewrite
Home

[Freeciv-Dev] Re: notify_player rewrite

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: notify_player rewrite
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Wed, 09 Aug 2000 09:44:15 -0400

At 2000/08/09 07:54 , Per I. Mathisen wrote:
>On Wed, 9 Aug 2000, Thue wrote:
>> I don't see the reason to include oldversion in the packet type; what
>> would be the need? To avoid converting all event messages at once just
>> leave the code the handle the old format in the client in the mean time.
>
>If I understand you correctly: I add a new packet type with the new
>format, and leave the old chat packet as it is. That way the obsolete
>format can be phased out without a protocol change later...

Yes, sounds good.  This way we don't have to change all the
notify_player*() calls at the same time -- we can migrate to the new scheme
one step at a time.

>In that case, I can try to use
>   int E_EVENT, x, y, var1, var2, var3, var4
>and see how far I get, unless you know that some of these variables
>must be sent to the client as strings.

I like this idea of sending only a minimum of data in the packet, and not
sending any (or only highly restricted) strings.  This will go a long way
towards allowing each client to run in its own locale!

However, as Thue points out:
>At least city names must be sent as strings; the client doesn't know all
>cities.
Restricted to city names, this maintains i18n, because city names are not
translated.  However, the packet does need to be extended with some string
values.

You may want to think about allowing your new packet to be of indefinite
length (send only as many ints/strings as needed).

One problem is that we can't just extend the number of event types from
40-odd to 300-some.  What are currently called event types are actually
classes of events.  They are used in the client to determine how to display
an incoming message (see Message Options in the Game menu).  40 is already
almost too many for a user to deal with...  So, we need to leave this set
as-is, and add an entirely new list of notification codes (one for each and
every distinct notification message).  Perhaps:

enum notification_code
{
  NOTE_????,
  ...
  NOTE_LAST  /* leave this last */
};

Also, David has recently re-written the notification stuff.  The
fundamental routines are now "connection" based (look for *notify_conn* in
server/plrhand.c).  These routines will need to be changed as well.  Or
perhaps their new versions will subsume the notify_player* versions.  After
all
  notify_player(pplayer, ...);
is just
  notify_conn(&pplayer->connections, ...);
and
  notify_player(NULL, ...);
is just
  notify_conn(&game.est_connections, ...);

Finally, the handling on the client side should be mostly in common client
code.  There should need to be only minor changes to each GUI.

jjm




[Prev in Thread] Current Thread [Next in Thread]