Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2005:
[Freeciv-Dev] Re: (PR#11805) Store chat and notify messages for later re

[Freeciv-Dev] Re: (PR#11805) Store chat and notify messages for later re

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: edoverton@xxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#11805) Store chat and notify messages for later retrieval
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 6 Jan 2005 12:09:41 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: >

Ed Overton wrote:

>>There is no need for the client to request these events I 
>>think - it certainly shouldn't come via a chatline request
>>but should be a separate packet if it is done.
> I don't see that there is a need necessarily, but it would be nice
> (again, focusing on disconnected play).  Allowing server commands such
> as /messages all is the disconnected play equivalent to scrolling up in
> the message log during connected play.  There are times when it's useful
> to look back in the message log, and that's what I'm trying to support
> with the /messages chatline requests.

It would be better for the client to know all the messages, and allow 
scrollback (via arrow buttons perhaps) in the messages dialog.  Still no 
need for the user to enter some weird command - all they have to do is 
click a button to look at the data that the client already knows.

However having the server remember messages from previous turns is a 
problem.  We don't have journalled savegames so these messages would be 
duplicated in each savegame, increasing the amount of storage needed 
greatly (the same is a problem with tracking score data from each turn, 
which is also something we should do).  Limiting the array to a maximum 
size isn't a very nice solution, since then the user is unhappy because 
the saves are "incomplete" and also it's possible this size is exceeded 
on a single turn.  I'm not sure what the solution here should be 
however.  Having journalled savegames would be very nice but may not be 
feasible either.


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