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: Mon, 24 Mar 2003 18:04:52 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, Mar 24, 2003 at 03:17:45PM -0800, Per I. Mathisen wrote:
> 
> On Sat, 22 Mar 2003, Mike Kaufman wrote:
> > The mechanics of joining a game, etc are pretty much unchanged. The real
> > differences are:
> > o you can connect to a server without joining a game.
> 
> Very useful. We can now implement global observer without the "dead" hack.

yes. exactly... but see below.

> > o you cannot join a game directly as an AI player. for this, you must
> > login and then execute the 'take' command. This is necessary since in the
> > authentication phase, you will not be able to use any old username.
> > this also means that you don't have to connect to a running game with a
> > particular username.
> 
> Nice. But I think "take" is a better name for the command than "takeover".
> Also "Take a player's place in the game" is better.

you've got readline. I always use 'take' as the command anyhow.
 
> Actually, I think "become" is better yet.

sure, I think we can do that.

>     List of players:
>     ----------------------------------------------
>     a (username Server AI, AI, difficulty level easy)
> 
> This doesn't look good. "AI, AI" should be avoided. How about not having a
> username for unconnected players? Or username "Unassigned"?

Hmm, well this provides maximum description. Say I start a game with 2
humans and 2 AI and I want people to join the game and take over for the
AI... When a someone logs on, they see "Server AI" being played by AI.
("Unassigned" will work here as well) If they become that player (actually
I'm going to disagree with you, I like 'take' better). then the username
switches to that connection's login name. If someone leaves the game for
whatever reason, the AI will take over, but the connection's username will
remain. If that player logs back on, and there is a player with his login
name, he will be automatically attached and join the game. So you want
"Unassigned?"
 
> Finally, the 'list' command should show all connected users, even if not
> related to any player.

try 'list connections'. remember that my original auth patch had all sorts
of bells and whistles like this. My current approach is a barebones auth
with snazziness coming later. I plan on switching the default so 'list'
shows connections rather than players.

> > o allowconnect doesn't really work anymore. kinda bad. how often is this
> > used on the public servers are what are the normal uses? This is going to
> > get changed anyhow when true multiconnect and observation gets
> > implemented (which will be right after the auth stuff goes in).
> 
> allowconnect is used for observing games. I'd rather not have it broken
> for a longer period of time.

this is where people and I are going to disagree I think. I am against
having observation where you get to see the whole map (the dead hack).
Observing should mean observing one player only at a time (and that player
will control 'obsconnect' (as well as 'multiconnect') for himself. This
means that a connection must _ask_ a player to allow him to observe or do
multiconnect. For now, a connection may simply 'take' a dead player. I
think that this should be restrictions on this however, settable by the guy
with cmdlevel ctrl (with the patch, there are no restrictions)

which brings me to my next point. There is a potential for abuse here.
somebody could fill up all the allowed connections for example. any other
deviousness (and solutions) people can come up with is appreciated.

-mike



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