[Freeciv-Dev] Re: notify_player rewrite

[Thue <thue@xxxxxxx>]

Den ons, 09 aug 2000 skrev Per I. Mathisen:
> On Wed, 9 Aug 2000, Thue wrote:
> > Rather
> >    int E_EVENT, x, y
> >    char var1, var2
> >    int n1, n2, n3, n4
> > 
> > (not too many strings; they take up a lot of space. They must have a max
> > lenght; what would they be used for besides city names?)
> > 
> > Then just "cast" the variables based on packet type.
> 
> I do not see why we should cast anything. You cannot send a string as an
> int and since you suggest four ints, there is no point in casting from
> the string to an int. There must be something I'm missing here...

I was thinking of having only one event packet type

struct packet_new_event {
  int  x, y
  int E_EVENT
  char var1[MAX_LEN_NAME], var2[MAN_LEN_NAME]
  int n1, n2, n3, n4
}

then when you send an event, say what is now
    notify_player_ex(0, pcity->x, pcity->y, E_WONDER_STOPPED,
                     _("Game: The %s have stopped building The %s in %s."),
                     get_nation_name_plural(pplayer->nation),
                     get_impr_name_ex(pcity, pcity->currently_building),
                     pcity->name);
it would be
   notify_player_new(0,
                              pcity->x, pcity->y,
                              E_WONDER_STOPPED,
                              pcity->name, NULL,
                              pplayer->player_no, pcity->currently_building, 0, 
0)

Note how the lines correspond to the packet fields. The second char field
and the two last int fields are unused.
The client would then recieve a packet_new_event, look at the event
type field (E_WONDER_STOPPED), and use the valid fields to create the
message.
That would mean that there would only be one new packet, packet_new_event.

For E_NOEVENT packets you would need to use one of the int variables for
type, and treat the packet accordingly. (what I called casting)

An alternative solution would be to add a packet type per event/nonevent,
but as you said that might be bloated.

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

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

At least city names must be sent as strings; the client doesn't know all
cities. I used MAX_LEN_NAME, which is the city name lenght, as string
lenght in the packet, but if there are other possibilities with higher
potential string lenghts it would use their max value.

>Yours,
>Per

-Thue