[freeciv-data] from rulesets to scripting (was: Ruleset limitations)

[Reinier Post <rp@xxxxxxxxxx>]

On Mon, Jan 01, 2001 at 06:07:15PM +0200, Marko Lindqvist wrote:

>  We really should document ruleset limitations somewhere. I have seen
> several modified rulesets, which do not work as author meant simply
> because freeciv code base does not handle it right (as one would expect
> after reading README.rulesets and comments inside rulesets). I bet it's
> quite frustrating to spent hours to balance your rules only to find out
> that game does not handle them right.
>  At very least, README.rulesets should mention that such limitations
> exists.
>
>  Well, instead of just whining I probably should at least list those
> limitations I'm aware of:
> 
> 
>  - currently unused entries
> 
>      - units.ruleset
>          - uk_gold
> 
>      - buildings.ruleset
>           - bldg_req
>           - terr_gate

[etc.]

There are other problems related to rulesets, some for users (for instance,
they only get loaded at /start and any failure causes civserver to abort,
and their content cannot be examined before that), some for developers
(adding rulesets and ruleset entries is more difficult than it could be).

One thing that would really help, I think, is an integration between
rulesets and server settings.  The mechanism to handle server settings
is very elegant now (thanks to mainly dwp's work) and using the same
mechanism for rulesets would solve some of their problems them.  When
ruleset entries are special server settings they can be examined and
even set from the command line.  The existing server settings would
become part of the game ruleset.  The only problem, think, is the fact
that server settings cannot be structured, while rulesets have a
one-level (section) structure.  I am designing a patch to implement
this.  Once it is ready you will be able to say things like

  set nations.egyptian.wonder "Great Library"
  show nations.egyptian

Once server settings can be structured their mechanism can also be used
to interface with other Freeciv objects.  I don't intend to implement
this, but it would be extremely powerful.   For example: at the moment
we have command line interaction like this:

  # is Genghis ai?  I don't know
  list
  # 'list' output happens to include this information, but
  # all I wanted to know is whether Genghis is ai or not!
  ai Genghis
  # just to make sure

Imagine being able to say this:

  set players.genghis.ai 1
  show players.genghis

  set players.*.ai 1

This still leaves the problem of having to code the interfacing between
Freeciv internal object fields and associated configuration settings.
For example, if I want to introduce a new global setting 'avgtemp' to
simulate the effect of changing conditions in climate, I have to

  + decide whether to use a ruleset entry or a server setting
  + decide whether to use a new field to the 'game' struct
  + manually implement the correspondence (if it's a ruleset entry,
   I have to implement copying its value to the game struct field,
   if it's a server setting, I have to set a pointer to &game.avgtemp
   in the settings structure

<dream subject="Freeciv object browser">

All of this would disappear if ruleset entries, server settings and the
actual struct fields used by the game engine were identical.  We can
introduce a server/stdinhand.c:settings[] struct value, or something
equivalent, for any Freeciv struct whose contents are worth making
available to users.  Once we have that, there can be generic code to
implement 'set', 'show', and 'explain' commands (which is already in
place), and generic 'read as ruleset entry' / 'write as ruleset entry'
routines (which could be extracted from the existing code).  Ruleset
and savefile reading/writing becomes a special case.  At this point the
ruleset syntax, which doesn't really support nested structures, becomes
too limited, but I wasn't going to mention XML.

Once this is in place you can say things like

  set players.genghis.cities.*.building Settlers
  set players.genghis.units.25.x 16

At this point, the 'set' is superfluous:

  fogofwar 1
  players.genghis.cities.*.building Settlers
  players.genghis.units.25.x 16

With the addition of methods, we can have

  players.genghis.units.25.step bottomleft
  players.genghis.units.25.goto 16 12
  players.genghis.units.25.disband

Impose the rule that all structs have a 'name' field, and the rule
that names (where specified) must be unique across the game for each
client.  This would allow us to say

  players.genghis.units.25.name Harry
  Harry.goto 16 12
  Harry.build Khotan
  Khotan.building Horsemen

Add method definitions, if, for, while, and you have a scripting language.

I'm not sure if any of this solves more problems than it creates.
A fresh start in a different language may be a better idea.

</dream>

Another thing that needs work, independently, is the client-side GUI
interface to server settings.   At the moment it can only display
their values, but not the help text, and it cannot not modify settings.
The existing two popup windows can be turned into property sheets
with editable fields.  

<dream subject="Freeciv 2.0">

If this interface is available for arbitrary objects, it will be more
efficient to just make it operate on client-side copies and have a
generic mechanism to send any changes made to those objects to the
server.  For example, every city would have an associated property sheet
that can be used to display and modify the city struct values.  The map
would have a property sheet, displaying an index to the property sheets
of every tile.  Every unit type, but also every unit would have a
property sheet.  Many of these would never be used, but since the property
sheet mechanism is generic, they don't cost any extra effort to implement.
Widgets in the existing interface can be thought of special-purpose interfaces
to these objects.  I'll stop now and take my pills.

</dream>

>  Caz
 
-- 
Reinier Post