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