Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2000:
[Freeciv-Dev] Re: Roadmap changes?
Home

[Freeciv-Dev] Re: Roadmap changes?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Roadmap changes?
From: rutger@xxxxxxxx
Date: Mon, 17 Jul 2000 21:31:28 +0200
Reply-to: Rutger Nijlunsing <rutger@xxxxxxxx>

[Cc: freeciv-dev]

On Mon, Jul 17, 2000 at 03:04:29PM -0400, Jeff Mallatt wrote:
> At 2000/07/17 13:49 , you wrote:
> >On Sun, Jul 16, 2000 at 05:53:17PM +0000, Martin Willemoes Hansen wrote:
> >> Hi Freecivers!
> >> 
> >> I think the roadmap can be changed a bit, I would be very delighted if
> >> some of you guys would give some feedback on it, take a look at:
> >> http://www.freeciv.org/roadmap.html
> >> 
> >> Now it is a long time since it last was changed I guess ;)
> >
> >Shouldn't 'server scripting' be 'client scripting'?
> 
> By 'server scripting', we mean civilization automation controlled by each
> player, using scripts that are stored and run on the server.  Much like
> worklists, it is proposed that scripts be edited on the clients, then
> shipped to the server for execution.

> This has a number of advantages over running the scripts on the client (I
> don't know if this is what you mean by 'client scripting', however).  All
> state naturally saved in same place.  Scripts keep running when client
> disconnected.  Easy implementation of "fair" execution (without extra work,
> a fast client on a fast connection could have a great advantage over slow
> clients when both use client-side scripts).  Much reduced network traffic.

Ah, I see... But then this would need some extra work on the server:
the client may not execute random pieces of code, and so must be
sandboxed. Probably done most easily by putting each script of a user
in a seperate thread: now taking all the CPU time is not possible, and 
the CPU is shared between all scripts.

Another option would be to limit the possibilities of the script:
fixed language to program it in, no looping allowed, etc, but this
would limit the script maker too much, IMHO.

Another possibility would then be to make client scripting, but allow
one script of the client to be local. This way the network is always
local (loopback).

And for this to work, we need two things:
* more than 1 person may connect to 1 race
* a way in which we can use other languages than C to control a
  player.

The first thing I saw someone preparing to do on the freeciv-devel
list.

Currently, I'm working on the second, by creating gui-cli: a
command-line freeciv client, independant on any graphical libraries,
and only using the stdin for input and stdout for output. I try to
make the output easily parseble (by e.g. using the RFC-style of the
console), and this way it is easy to attach a perl-script to a race.

Regards,
Rutger.

-- 
Rutger Nijlunsing, rutger @ null.net ----------------------------- Linux! --
Don't BiCapitalize without extremely good reason: it messes up the natural
human-eyeball search order -- Your Friendly Neighborhood Archive Maintainers
+31-40 ----------------------------------------------------------- ^X^S^X^Cs



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