Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: Development Strategies [Was Documentation,Usability an
Home

[Freeciv-Dev] Re: Development Strategies [Was Documentation,Usability an

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Development Strategies [Was Documentation,Usability and Development]
From: Reinier Post <rp@xxxxxxxxxx>
Date: Mon, 10 Dec 2001 18:26:08 +0100

On Sun, Dec 09, 2001 at 03:41:40PM -0800, Kevin Brown wrote:

> > > What I'm getting at is that it DOESN'T MATTER if people egregiously
> > > hack on the unit code, because they can't submit it remotely to the
> > > server anyway -- they have to actually be in control of the server,
> > > and if that's already the case then no amount of protection in the
> > > scripting language is going to help.
> > 
> > True, you need to trust the server owner.  I think we were discussing
> > scripts or ruleset changes set in the server, but specified at the
> > client end.
> 
> Yech.  Why would you even *contemplate* such a thing?  If players want
> to add units to the game they can do so by sending the appropriate
> code to the server maintainer and have *him* do the work.

I only play on public servers.  On public servers, the server operator
is usually absent.

> It's his
> server, after all.  If you implement such a capability, it should be
> subject to the trust rules that are in place for general control over
> the server anyway.  In short, to upload such a script, you should have
> administration rights on the server process.

'Administration rights' is not specific enough to my taste here.
There are two relevant aspects:

  - degree of trust ('cmdlevel')

    + 'ctrl': operations that affect the game, but are safe otherwise
    + 'hack': operations that can destroy the server or damage the
       environment in which it is running

  - range of effect ('class')

    + map generation (e.g. map size)
    + player generation/admission (e.g. aifill)
    + game initialization (e.g. initial unit set)
    + game rules fixed while game is running (e.g. rulesets)
    + game rules mutable while game is running (e.g. various probabilities)
    + runtime behaviour (e.g. timeouts)

A user at 'ctrl' level should be able to control all of these, and
any other user can review everything, but only set certain categories.
This is how it works for server options and commands, except that neither
kind of user can inspect or set rulesets yet.

> Then it becomes a matter
> of trust as usual and you don't have to worry about putting in all
> sorts of crazy limitations into the scripting language.

The issue is whether scripting capabilities are required at the 'ctrl'
level.  E.g. do we want the ability for a player to add a 'healer' unit
by specifying its behaviour iwith a script? This is a 'fixed game rule'
change, and therefore in the 'ctrl' range.

> If you have to make it possible for any client to upload server-side
> code, then such code should be reviewable by all players (this might
> be useful to have even if only "administrators" can upload such code).
> But in the end, I think that the ability of clients to upload code to
> the server is much more trouble than its worth except perhaps when
> given only to those who have administrator rights on the server.

In that case it will suffice to implement a language to display (and modify)
rulesets.

> -- 
> Kevin Brown                                         kevin@xxxxxxxxxxxxxx

-- 
Reinier


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