Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2003:
[Freeciv-Dev] Re: client/server authentication (PR#1767)
Home

[Freeciv-Dev] Re: client/server authentication (PR#1767)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Mar 2003 07:19:40 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, Mar 27, 2003 at 06:20:18AM -0800, Per I. Mathisen wrote:
> 
> I'm not arguing that auto_attach should be configurable, I'm arguing it
> should go away.

I know what you're arguing.

> We're making starting a game more complex. The correct solution to this
> issue is to make a GUI for creating players, setting up
> AIs/observers/multiconnects and choosing teams.

I don't understand the utter facination with a GUI for everything. we have 
a chatline. It acts kinda like IRC. People know this. People _should_ know
that in IRC you can send commands to get things done (they better know
this since they can't start a game otherwise). But the real point here is 
that (with auto_attach) unless you want to do special things, the _only_ 
command you need send is /start. (what is complicated about this?) And no,
I don't believe that a GUI for such things is the "correct" solution. And
even if one magically appears, it should be sending commands on msg
packets, so the point is moot.
 
> Your auto-attach solution is no good. You assume that the usual case is
> that there are X users and Y players where X == Y and all X want to play.
> That assumption is not warranted.

No that is not my assumption. My assumption is that the usual case is that
there are X users and all X want to play. The number of players has nothing
to do with it. Creating AI players or using aifill has no impact on this.

Is this not warranted? I want a testimonial. remember that this only
matters for pregame.
 
> Players should get accustomed to logging in, creating player, taking over
> player, starting game. This shortcut will only create confusion about how
> the system really works.

this is not how the system really works (in the current scheme of things).
You would have people /create and then /take/? (thus totally obliterating 
the use of the races dialog?) The problem is that at pregame 
game.nplayers = 0. game.players[] exists because it was initialized on game 
init. Now in the current scheme when someone logs on, he is automatically
attached to a player slot (pconn->player = &game.players[game.nplayers];
game.nplayers++). Attributes of those players are changes in the races
dialog after the game starts. Now you could alter the function of /create 
such that it would pop of the races dialog. so that a player could change 
attributes. But here instead of the 'usual' case where you only need to
/start, a user would have to /create X human, /take X, and then change
X's name, etc. then /start. Who's making the game more complex?

In the full scheme, we have A,B,C,D,E connections and only A,B,C want to
play. D,E want to observe A,B:

> attach A
> attach B
> attach C
> obs D A
> obs E B
> start

please note that we did not have to 'set autoattach 0' here. Only here: D,E
don't want to watch they just want to sit in the staging area and chat, or
they logged in and just sit there not communicating: A, who has cmdlevel
ctrl doesn't want rifraff playing in his game does:

> set autoattach 0
> attach A
> attach B
> attach C
> start

-mike



[Prev in Thread] Current Thread [Next in Thread]