Re: [Freeciv-Dev] cmdlevel: feature or bug?

[Reinier Post <rp@xxxxxxxxxx>]

> I've been playing with the cmdlevel server command and I noticed that
> this flag is reset when a player disconnects.  Is this a feature or bug?

This is a known bug.

> Ideally this should be sticky across reconnects.
> 
> Any thoughts?

I (who initiated the cmdlevel patch) have discussed with David (who finally
finished the patch when I couldn't meet his coding standards) in detail
how to add this functionality.  This is my latest write-up:


  Player-related entities in Freeciv

Freeciv is confused about the meaning of 'player'.  As a participant in
Freeciv games, you'll notice that the participants are called 'players'.
At the same time, players seem to be identified with civilizations.
On the other hand, civilizations seem to be identified by 'race':
every player chooses a race at the start of the game.

In the data structures, a 'player' identifies a civilization, not a user.
A 'user' data structure ought to be added, and the 'player' data structure
should only be used for data concerning participants in running games.
For instance, the 'name' attribute, which is currently a single attribute
that changes from user name to player name when the game is started, would
be an attribute to both.

  THE PLAN

There are four player-related entities:

+ player
  a civilization, with a capital, cities, units, an income, etc.

+ race
  a type of civilization (except that very little actually depends on
  race, and the oddity exists that each player must be of different race)

+ user
  identifies 'someone out there', usually a human user running a civclient
  (this is the plan; it is not yet implemented)

+ connection
  records a client connection

Where do these entities exist?

Races aren't actually used for annything that matters; for them,
so the question isn't very interesting.

Players (more aptly named, 'civilizations'), exist in games.  Except in
the context of a running game, the entity makes no sense.  Players and
their status are part of savefiles.  A game can be saved and restarted
on a different server; the players will be the same.  A new game will
have new players.  Players exist in common/ (even games do) but a
client only has one instantiated player.

The reason to introduce users is client-side server commands.  It must
be possible to assign different levels of access to commands to different
users.  Attaching it to players is not good enough: the information must
survive the addition and removal of other players, the start or restart
of a game, reconnections by the same user even from different computers,
or transferral of the game to a different server.  However, a user
may have different levels of access in different games.

While they last, connections are sufficient identification for users.
The user entity will allow users to be identified when they reconnect.

Ideally, users would be identified with unique global ids, handed out
by a 'registry service' similar to the metaserver, but this would be
too cumbersome in practice.  So the plan is to make users persist in
a server session (even whan a game is started, or restarted when that
option is added) and make them persist across games (when a saved
game is loaded in a different server session).

Users are created when they first connect to a server, remembered by
the running server and in savefiles.  Upon connecting, the client will
be sent a unique session id, generated when the server started, plus a
fresh user id; it will store them in a ~/.civcookie file, and send it
back when trying to reconnect.  This will allow the identity of users
to be protected.  Identified players will only allow the same user to
reconnect; unidentified ones allow anyone to connect; server commands
and probably client options will be available to control this.
(An identified player is a player whose user field is non-NULL.)

Player names will be assigned to users, not players.
(Access levels are already assigned to users, but user ids are not
yet saved or sent to clients, so the 'id protection' doesn't yet work.)

The server maintains a default access level, which is used for new
users and unidentified ones.


  THE PRESENT IMPLEMENTATION

Access levels are implemented, and are associated with connections;
there is no user struct yet because the mechanism to make them persist
across connections (the cookies) doesn't yet exist.

Players are still created before the game is started, and player names
still belong to players.  Users and access levels exist in client and
server, but only the server uses them.   User ids are not yet saved
to savefiles or sent to clients; server ids do not exist at all.

Commands to un/identify users do not yet exist;
they would serve no useful purpose.

Access levels can already be set for individual users, including AI
players; but they will not be remembered when the user disconnects.

-- 
Reinierw Post                                            rp@xxxxxxxxxx
a.k.a. <A HREF="http://www.win.tue.nl/~reinpost/";>me</A>
[LINK] [LINK] [LINK] [LINK] [LINK] [LINK] [LINK] [LINK] [LINK] [LINK] [LINK]