Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Daniel Sjölie <deepone@xxxxxxxxxx>, Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Mon, 29 Oct 2001 00:35:33 +0100

On Sat, Oct 27, 2001 at 11:39:08PM +0200, Daniel Sjölie wrote:

[...]

> > 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.
> 
> I imagine this to be done as:
> 
> > show players
> 1: Napoleon
> 2: Hitler
> 3: Cleopatra
> > show players[2].name
> Hitler
> > set players[2].name = Churchill
> > show players[2].name
> Churchill
> > show players
> 1: Napoleon
> 2: Churchill
> 3: Cleopatra
> 
> I think this is sufficiently clearer that the bother of having to use a
> number instead of the more easily seen name is outweighed...

This would be an option, but I still think referring by name is convenient.
Do you really want to forbid

  /ai Napoleon

and allow only

  /ai players[5]

?
> Here I would like:
> 
> > show cities
> ....
> 23: Boston ...

That's unworkble.  In many games, I've been creating a city per turn.
Play on 100x100 and you'll end up with about a thousand cities.

With a 'where' clause, it would be better.

  show cities where name like B%
  show cities where name ~ B*

or whatever.

> ...
> # or
> > show players[2].cities
> ....
> 23: Boston ...
> ...
> > show cities[23].units[3]
> Settler...
> 
> Sure, it's a _lot_ more verbose but you still can do what you want...

Practically speaking, you can't.  Users refer to cities by name, they
can't afford to look them up.

> My point about "run time" versus "configuration time" was that
> identifiers are only intuitive in the second of these... I certainly
> have nothing against being able to edit "run time objects" - but they
> _are_ different...

Not really, if you display the names in the interface.  Then you can name
your goto unit "Harry", watch him, and correct him from the command line
if necessary.
 
> > 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.
> 
> This is what I object to... This magic connection... Honestly, I think
> it's horrible... It really _would_ give me nightmares...

Why?  There's nothing magic about it.  Cities already *have* names!

> > > 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.
> 
> I don't really get what this has to do what I wrote...

Not much, I was just trying to make the point that it doesn't take very
much effort to create a very powerful language, if you allow it to be
used at runtime.

> > > 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.
> 
> Well, what one considers class or object may vary... Here's my
> definition: Classes is what you use to create objects...

Are unit types used to define units?  In a sense, yes.  But there is
no reason for a command language to treatthem differently.

> Units in the running game are objects created from the classes that are
> defined before the game starts... I think there is a real difference
> between all the archers in the game and the definition of how these will
> be...

Editing of a unit type vs. editing of a unit.

> Well, I'll leave it at that for now... Do you feel that we understand
> each other?

Yes.  

> /Daniel

-- 
Reinier


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