bugFreeciv - Bugs: bug #18426, Allow server operators to restrict...

Show feedback again

bug #18426: Allow server operators to restrict settings

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Tue Jul 26 22:51:59 2011  
Category: generalSeverity: 1 - Wish
Priority: 5 - NormalStatus: None
Assigned to: NoneOpen/Closed: Open
Release: Operating System: Any
Planned Release: Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Thu Jan 2 14:50:37 2014, comment #2:

An idea I had for this: add a Lua function a server operator could edit which would be able to veto any setting proposed by players. It would be passed the name and proposed value (as a string) of any setting change, and return a boolean value whether it's allowed, and return or print a message why not.


  • Dead easy for us to implement and allows a wide range of policies to be implemented (compared to us having to have machinery in C to allow operator to specify min/max for numeric, allowed bits for bitmask settings, sets of allowed strings for string settings, ... and whatever criteria we provided would still probably fail to meet someone's needs)


  • Requires server operators to write code to use this; we can mitigate by providing examples of common uses (limit maxplayers, limit rulesetdir per patch #3438).
  • Passing string version of value places responsibility on script writer to validate input, with attendant possibility of mismatch with server's parsing of input allowing bypassing the validation. We could ameliorate this by exposing our option parsing functions to the script, and setting things up to encourage their use.

Might want to expose access level of caller to the script to allow server operator to implement their own caller access level policy on top of what we provide.
Probably settings made from the server console or hack-level access should bypass this, possibly with a warning.

(This ought to run in the same sort of unfettered Lua context as envisaged by bug #19729, but that's not necessary for initial implementation. However, the script file should live in the same place as database.lua does today.)

Jacob Nevins <jtn>
Project Administrator
Tue Aug 16 17:56:25 2011, comment #1:

This has come up before ...

It would be nice to have a general mechanism for this.

E.g. the server can be made to automatically create, for each numerical setting, say with name foo, two additional settings, named admin_max_foo and admin_min_foo, that control its range and can be set only by users with ALLOW_ADMIN.

A further refinement is to also do this for the other ALLOW_* levels (their names can be taken from common/connection.h).

This can be done in maybe 30 lines of C code.

Reinier Post <r_p>
Project Member
Tue Jul 26 22:51:59 2011, original submission:

Over in this forum topic we had a server operator who wanted to restrict the 'maxplayers' setting, because their server had limited resources and couldn't cope with 30 AIs; they wanted at most 10 players.

Currently, there's no way for server operators to impose this sort of restriction short of (a) adding a locked setting in their ruleset(s) (from 2.3.x onwards), or (b) recompiling.

We currently have infrastructure for locking settings in rulesets, and I think it would be fairly trivial to add a server command to do something similar. However, that would lock 'maxplayers' down to a single setting (10), whereas what we ideally want is to restrict the range of 'maxplayers' from 1-30 to 1-10. This would require some complicated syntax, and wouldn't generalise to enum or string settings.

(Or we could decide that the number of players / AIs is a special case, and provide some solution that allows operator control of the limit, say an 'admin'-level setting that restricted the max.)

Jacob Nevins <jtn>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by r_p (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup