<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 [email protected] https://mail.gna.org/listinfo/freeciv-dev
