<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113 >

> [wsimpson - Mon Feb 25 22:15:57 2008]:
> 
> Madeline Book wrote:
> > So I supposed it should be set for clients connecting to
> > a server somewhere remotely (e.g. a to play a game online).
> >  
> 
> It should be set by the server and sent to the client after
> the client has been selected for a player slot.

So in establish_new_connection in server/connecthand.c ?

> > I thought you were intending to use client.playing to replace
> > it. The question is now why prefer client.playing over
> > aconnection.player? Maybe adding client.playing was not
> > necessary to begin with (as opposed to just improving
> > the use of aconnection.player)?
> > 
> Had you actually read and understood PR#39872, you would have
> noticed that client.playing was not *added*, it was a fairly
> straightforward replacement of the existing game.player_ptr,
> moved out of common/game.h into client/civclient.h, as the
> existing comments already specified it was client-only.

Oh dear, you are right, I completely missed that when I was
replying about the naming of client.playing in PR#39872!
How unsuprisingly stupid of me.

Could you also give me the PR# of the ticket where struct
civclient was introduced?
 
> Previous programmers added it in the full knowledge of the
> existing game.player_ptr.  I'm assuming it has some special
> purpose.  I've told you the PR#s, please study them and form
> your own conclusions.

If only I knew of some way to find the relevant PR#s (besides
PR#39872)! How do you suggest I go about doing that? I am not
very good yet with RT's search capabilities.

Maybe you could just tell me the ones you are looking at as
the basis for your claims? Or I have to grep through
svn logs or search through posts to freeciv-commits? :(

> > What about when connecting to a remote server? Newly
> > connected clients should have a player. ...
> > 
> No, they should not.  AFAICT, they only have a player
> after selecting a player, and before selecting a nation.

So they are detached when they connect, is that how you
see it? It doesn't look that way in establish_new_connection
in server/connecthand.c.

> > Maybe it would be a good idea to include a multiplayer
> > connection scenario when testing changes to the server's
> > multiplayer data structures (as opposed to only testing
> > with AIs and the fork'd server).
> > 
> Why?  There's no such thing as multi-player data
> structures, the entire game is multiplayer from the ground up.

It would be good then to once in while test out remote server
connection, e.g. starting a server process, then starting
a separate client and connecting to it, rather than only
running via "Start New Game". I know this is impossible for
you because of your setup (reverse DNS lookup and all that),
so I leave this as a reminder to those who able to accomplish
such things.

> It is an artifact that the connection dialog is separate
> (in the GTK2 client only).  You are testing something only
> rarely used for GTK2.

I don't quite understand. Are you saying that using the
"Connect to Network Game" button (and resulting pages)
to connect to a remote (or in fact local) server, or
equivalently using the -a and -s options in the civclient,
are rarely used?

> You are the person that can check out previous revisions and tell us
> which check-in caused the problem.  Isolate the problem, don't guess.

Oh sorry, I thought you would immediately know how to
fix the problem (thanks to your work on the relevant
code when you updated to client.playing). But I see
we are both in the dark on this one. ;)
 
> > It would seem to make more sense to change aconnection
> > .player to client.playing in the above (or the converse
> > ;)). It looks like some incomplete conversion when both
> > occur in the code like this.
> >   
> And yet Per chose to split the functionality.
>
> > I agree this is a curious change. What is the intended
> > difference in use of aconnection.player and game.player_ptr?
> 
> Until he tells us, we don't know his "intended difference".
> But it was obviously deliberate.
>

Hi Per, can you help us to understand? (I know you are
reading this :)))).
 


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to