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

[Petrus Viljoen <viljoenp@xxxxxxxxxxx>]

Daniel L Speyer wrote:

>
> > > > > 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?
> > >

The Same way currently prevent infinite loops in the Server & Client.
Scripts should be checked , tested , reviewed.
If you play with non verified scripts ....... IT'S AT YOUR OWN RISK.

>
> > > 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?
>

Don't think the current scripting engines support time-outs etc..
You will most likely end up with depleted memory or a thrashing garbage 
collector.

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

This will be difficult!  Multi-processing needs some shared mem protocol with 
locks, semaphores etc....
then you can just as well consider using a network protocol (CORBA/RMI)
Not all Scripting Engines are reentrant ether, so Multi-threading wont 
necessarily be easier ether.

>
> >
> > > >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.
> >

There will always be another way to hack it.


>
> > 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}"
> >
>

I agree!.

>
> 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.
>

Why do you want to make the rulesets & units extensible via scripts.
1. You are asking for someone to hack/cheat
2. If you have a script to configure a unit you can just as well have C code in 
the server to configure the unit
(This will be safer and better controlled)
3. I for one am not going to check all the Scripts before I start a Game.

Data driven configuration is
1. Safer
2. Easier to manage.


IMHO the only place scripts make sense is personalized customization of clients 
 (agents, unit, city
behavior/management).