[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)

[Reinier Post <rp@xxxxxxxxxx>]

This is a bit old, but anyway ...

On Tue, Oct 02, 2001 at 02:08:56PM +0200, Daniel Sjölie wrote:
> On 2001-10-02 13:27:50, Reinier Post wrote:
> > On Tue, Oct 02, 2001 at 10:00:24AM +0200, Daniel Sjölie wrote:
> > 
> > > I think there is great potential for confusion if you do something like
> > > the example presented with units.archers.name = "Bowmen" and
> > > units.archers suddenly cease to exist... Brrr... :)
> > 
> > But as soon as I add the /rename command to rename players (very useful
> > if you pick the wrong name initially) this will already happen in the
> > existing interface.  How do you propose to refer to players on the command
> > line other than by their name (or a unique prefix of it)?
> 
> Well, I think the nation name would be a good choise... I don't
> think that you should be able to rename a variable (that's what a player
> is here) runtime... I think it can be really confusing and I think
> that's a serious problem...

Renaming would really be handy, for example, if you end up playing
as Hitler by accident.  I've seen this happen.  I agree it can be
confusing.

> However, I was not thinking about runtime issues really...

But to me this is the main benefit of this exercise: to treat
'configuration time' with the same syntax and semantocs as runtime
settings.

> When you want
> to edit "objects" "live" these problems will come up (how would you
> refer to a individual unit by your model?

  unit.556
  unit[556]
  unit556

(without a strong preference) to select a unit globally, or

  "Boston".unit3
  30,18.unit5

to pick a unit relative to some object.

You could introduce a .name field for every object, that way a unit can
be called "Harry" and referred to by that name - the difference with an
identifier in the command language would be that the name would be part
of the game structure, saved in savegames, transmitted to the client.

> it doesn't have it's own
> individual name) and I don't think it's worth the effort to try to make
> it too smooth... I mean that even if it's not very pretty to edit a
> player live by refering to the player id I think it's ok...

Yes, individual command-line updates of objects aren't very useful,
but they are easy to support.  Technically you can play Freeciv from
the command line once you have them.

The language only starts to bubble with control structures or generic
variables a la SQL.  That would give you the ability to really
program things.

> The primary purpose as I see it is to edit variables/objects _before_
> a game is started... That is, editing classes/templates is more
> important than editing objects...

Yes, definitely, but classes are objects in Freeciv, so you get the
editing of objects practically for free.  All you need to do is ensure
that a player can not read or write information s/he is not entitled to.

Another possible application is to describe client/server communication
in this way.  client->server updates are requests; they can fail.
server->client updates always succeed.  It would have to be a binary
shorthand version.
 
> But maybe I missed the start of this discussion and what you really want
> is to be able to edit "live" objects?

Well, as far as I'm concerned this discussion arises from the need to
have the command line support things like player- specific configuration
variables.  Freeciv has the commands:

  /ai player
  /hard player

Their meaning is much better represented like this:

  /set player.ai 1
  /set player.level 7

Actually doing it that way would make the commands easier to find for
the user, it would make the C code easier to follow, and it would make
it possible to inspect the current values by doing

  /show player.ai
  /show player.level

Before I modified the /list command to display this info, it could
not be inspected at all.  The fact that /list can be used is not
obvious to novice players.

You want generic support for this so you can support rulesets, which
also have structure.  Once you have generic support it's relatively
easy to make it work on live objects - not very useful during the game,
but it allows you to write savegames in this language, for instance.

-- 
Reinier