<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
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.
> 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. It fixed some silly bugs.
I have not formed an opinion as to the use or need for aconnection.player.
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.
> 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.
> 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 is an artifact that the connection dialog is separate (in the GTK2
client only). You are testing something only rarely used for GTK2.
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.
> 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
Freeciv-dev mailing list