[Freeciv-Dev] Re: Patch: Use original city id at client (Fixes some bugs)

[Marko Lindqvist <caz@xxxxxxxxx>]

 Hmm, I think both of you got some of my intent.


On Thu, 21 Dec 2000, Thue wrote:

> On Thursday 21 December 2000 05:56, Jeff Mallatt wrote:
> > At 2000/12/20 21:34 , Marko Lindqvist wrote:
> > > orig_id:
> > >
> > >   First four have any meaning only if clients are modified to somehow to
> > > show if city is same as city previosly seen at this place. Of course
> > > server can send all the following information to clients when
> > > necessary, but figuring out when player has right to know
> > > would be rather complicated (and memory hungry). It's easier to just let
> > > player remember what he knows.
> >
> > I haven't read the patch at all, but I worry about the phrase "It's easier
> > to just let player remember what he knows.".  Does this mean that some
> > state winds up defined solely latently in the client?  This doesn't work:
> > what happens when the client disconnects the re-connects?  Any latent state
> > is lost.  All client state must be known by the server at all times,
> > otherwise restarting a client (or the server) does not result in the same
> > state.

 All data that is currently sent to the clients will be sent also after
this patch. We are already saving some information only to players brain.
Also, I'm not saying orig_id makes improvements in that respect more
difficult than private map approach, they are just not as critical.
(Players with poor memory (client-side AI after load game) would still
require them)
 I were referring to non-critical data such as city.steal. Ideally, server
should know how many stealings each player knows (have seen). Currently it
does not, and until it does, there's difference between orig_id and
private map approaches. With orig_id, client can be sure that number of
stealings always rises in a given city, never falls. With private map,
server might claim to clients that refounded city is same as it's
predecessor. In that case, number of stealings from given (as client sees
it) city might fall.

> > jjm
>
> The client and server info does not get out of sync. All that happens is that
> a city's id in the client remains static, in both the client and the server.
> This lack of a need to update is what caz refers to as "It's easier to just
> let player remember what he knows.", which just means that keeping the client
> up to date requires no work.
>
> -Thue
>

 Caz

--