[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability and Development]

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 3 Dec 2001, Raimar Falke wrote:
> ... > [snip lengthy discussion]
> > > 
> > > Yes we may run out, but this isn't and shouldn't be the problem.
> > 
> > Hinging a potential customizability on a limited resource is not good
> > design.  We don't want to run up against this just as custom rulesets get
> > popular.  We've already run into this with nations (which we allow far
> > more of, IIRC), and (I suspect) are losing potential developers beause
> > their work can't be included.  
> 
> There is a patch and it _will_ be included before the next version. If
> we run out of flags (currently 28) we will expand it to 64 or 128.

But do we want to go through this again?

> 
> Also note:
> 1.16         (freeciv  30-Jan-99):   F_CARAVAN=0,
> 1.16         (freeciv  30-Jan-99):   F_MISSILE,
> 1.16         (freeciv  30-Jan-99):   F_IGZOC,
> 1.16         (freeciv  30-Jan-99):   F_NONMIL,
> 1.16         (freeciv  30-Jan-99):   F_IGTER,
> 1.16         (freeciv  30-Jan-99):   F_CARRIER,
> 1.16         (freeciv  30-Jan-99):   F_ONEATTACK,
> 1.16         (freeciv  30-Jan-99):   F_PIKEMEN,
> 1.16         (freeciv  30-Jan-99):   F_HORSE,
> 1.16         (freeciv  30-Jan-99):   F_IGWALL,
> 1.16         (freeciv  30-Jan-99):   F_FIELDUNIT,
> 1.16         (freeciv  30-Jan-99):   F_AEGIS,
> 1.16         (freeciv  30-Jan-99):   F_FIGHTER,
> 1.16         (freeciv  30-Jan-99):   F_MARINES,
> 1.53         (dwp      06-May-00):   F_PARTIAL_INVIS,    /* Invisibile except 
> when adjacent (Submarine) */
> 1.42         (jjm      27-Dec-99):   F_SETTLERS,         /* Does not include 
> ability to found cities */
> 1.16         (freeciv  30-Jan-99):   F_DIPLOMAT,
> 1.16         (freeciv  30-Jan-99):   F_TRIREME,          /* Trireme sinking 
> effect */
> 1.16         (freeciv  30-Jan-99):   F_NUCLEAR,          /* Nuclear attack 
> effect */
> 1.16         (freeciv  30-Jan-99):   F_SPY,              /* Enhanced spy 
> abilities */
> 1.18         (freeciv  12-Feb-99):   F_TRANSFORM,        /* Can transform 
> terrain types (Engineers) */
> 1.34         (sebauer  12-Sep-99):   F_PARATROOPERS,
> 1.39         (sebauer  20-Sep-99):   F_AIRBASE,          /* Can build 
> Airbases */
> 1.42         (jjm      27-Dec-99):   F_CITIES,           /* Can build cities 
> */
> 1.44         (jjm      10-Mar-00):   F_IGTIRED,          /* Ignore tired 
> negative bonus when attacking */
> 1.53         (dwp      06-May-00):   F_MISSILE_CARRIER,  /* Like F_CARRIER, 
> but missiles only (Submarine) */
> 1.53         (dwp      06-May-00):   F_NO_LAND_ATTACK,   /* Cannot attack vs 
> land squares (Submarine) */
> 1.4          (rfalke   28-Aug-01):   F_ADD_TO_CITY,      /* unit can add to 
> city population */
> 1.5          (rfalke   08-Sep-01):   F_FANATIC,          /* Only 
> Fundamentalist government can build
> 
> So it looks like there are 3 flags added per year. I wonder why this
> should change suddenly.

So far, interesting (i.e. requiring flags or equivalent) units have only
been added when enslavedciv adds them.  If we can open up interesting
ruleset building to anyone whose interested, we should see a lot more.

> 
> > > > and then written code that looped through all units at the end of
> > > > each turn checking for the flag and doing the same logic -- except
> > > > that I'd have to constantly watch for bounds overflows, null
> > > > pointers, and general low-level bugs.  I tried briefly to write the
> > > > relevant C, but realized I would have to look up to many
> > > > header-files and gave up.
> > > 
> > > About lisp vs c: the lisp solution isn't this easy: when will it be
> > > called? 
> > 
> > There can be a small list of hooks, such as move, turnDone, attacking,
> > attacked...
> > 
> > > How do you prevent that somebody doesn't to an endless loop
> > > there? 
> > 
> > Well, with a good enough forall, a non-infinite-looping language might be
> > adequate here (it's very theoretically limited, but I don't think we need
> > that much power).  Alternatively, kill the script if it doesn't terminate
> > within some time limit.
> 
> Multi threading or will the interpreter provide this feature?

I was picturing multi-threading, or rather multi-processing, with the
interperator having its own PID, but anything is fine.

> 
> > >How do you prevent somebody from manipulation? Consider this
> > > under the situation where server variables and rulesets are unified
> > > and every player can enter extra code for certain units. And there is
> > > a "if(player_name=='foobar'){hp*=1000;}" well hidden in a 30 line code
> > > fragment.
> > 
> > Hmm, this is a difficult problem.  I don't think checking all modules
> > through a central maintainer is the right approach, though.  There should
> > be some sort of sandboxing.
> > 
> > Now we want to allow things like 
> > waterElemental.moveHook={if isRiver(getMyTile()) fp=2; else fp=1;}
> > but we don't want to allow your example.  The first thing to do is to
> > disallow access to player names.  There are ays around this, though, so
> > let's see:
> > 
> > Disallow all player info -- unit scripts can't access names, IPs,
> > cmdlevels, etc.
> > 
> > Make everything relative to the unit (i.e. set the map-grid to 0,0 at the
> > unit, players are simply 'self', 'allied', 'neutral', 'war', or 'no
> > contact'...)
> > 
> > Disallow access to easily alterable data (e.g city names)
> > 
> > This should cut out straightforwardly dishonest scripts.  Now it's still
> > possible to set up some unintuitive key to increase power, but this really
> > blurs into legitimately weird setups.  If we use a highly newbie-readable
> > language (I guess not lisp) and let any player read any script, we can
> > highly disourage dishonestly pathological scripts.
> 
> So we agree that there is no general technical solution. Think about
> 
> "if(path_gone==[n,n,s,s]){ give_super_power}" or 
> 
> "if(get_tile(nw).has_road() and 
>     get_tile(ne).has_road() and 
>     get_tile(s).has_road() and 
>     get_tile(n).has_a_city())
>   { give_super_power}"
> 

Right, this is the sort of pathological example that needs to be
permissible.  The answer, I think, is to make the code highly readable and
let everybody see it.  After all, you might *want* an indecision-demon
which gains power by walking back and forth.  I doubt there's an
un-obfuscatable language out there, but we could advise players to be wary
of unreadable code.

--Daniel Speyer
"May the /src be with you, always"


>       Raimar
> 
> -- 
>  email: rf13@xxxxxxxxxxxxxxxxx
>   "brand memory are for windows users that think their stability
>    problems come from the memory"
>     -- bomek in #freeciv
> 
>